Alternatively, you could forget the GATE and guarantee that all poly channels have some relevant note on it, either by duplicating notes or by adding more octaves.
This is pretty much how the AH chord generators work right now.
Anyway - thanks for the advice. I’ll see how to best move forward and it’s clear on the best way for the modules receiving poly cables.
It looks like the audio threads (now plural) still run at default priority?
Yes. I have not yet designed criteria/goals for testing thread priority.
Major Thanks
I’ve not done any scientific testing but I’ve been using your Thread Priority module whilst using Rack in tandem with Ableton mainly because Ableton boosts it’s thread priorty status behind the scenes (much like many other DAW’s) and I’ve found things to run very smoothly.
Please keep this utility updated if there’s nothing within the Rack core that offers the same user choices. 
After playing with this for a while I think you are right. The shift-click initialization is not that different and acceptable for a live workflow.
Will be changed to double-click anyway. Just needs a modification to the event engine.
Added double-click to event engine with onDoubleClick(const event::DoubleClick &e), and changed param reset to double-click. This gesture mapping is virtually perfect because resetting doesn’t require the keyboard, right-click does what right-click should do (opens a context menu), and existing users will learn of the new gesture when they see the “Initialize” item in the context menu.
Might be cool down the line to have extra control where a mouse has more than 2 buttons. Have mine mapped to shortcuts at the minute though (X-Mouse Button Control), middle click initializes.
Plugins can take advantage of extra buttons using the int event::Button::button field, but at the moment there are no ParamWidget actions that need to be assigned extra mouse buttons.
Cool must look into that. Nudge a param to next value perhaps!
Added "frameRateLimit" and "frameRateSync" to settings.json. To save power, you can set the limit to ~25. I’m going to leave this out of the GUI, but you can change it in settings.json with a text editor.
Setting the frameRateLimit to 25 means it caps the framerate at 25 fps ? what does the frameRateSync setting do?
It determines whether vsync is enabled.
Sorry if out of bounds Andrew, but will some form of nudge/push/shove… feature be implemented in 1.0? Basically, moving a whole row of modules to the right or left. It would be immensely useful during patching, and I know it’s been talked about before but I lost track. Thanks!
It’s on the list. I usually keep my list private though, to avoid unnecessary debates that waste development time.
Big YAY!
Yes, afaik all DAWS run elevated. I would prefer not to have to make a multi-threaded version of Thread Booster, but I will if VCV doesn’t do it.
You might not find this valid, but when I was making Thread Booster I make a plugin called “CPU Hog” that spun up a bunch of thread at normal priority. Seemed like a reasonable bad case to me - like if you had a bunch of tabs open in a browser and they were all doing thing. Or if windows spun up some background process.
Of course using this “load test” raising the thread priority made an enormous difference.
Ardour will fail to run if it doesn’t have permission to get real-time thread priority. I don’t know of any other DAW that does (presumably REAPER and FL either were allowed by default on Windows, or they handle denial more gracefully.)
[Ignorance ahead] Doesn’t the elevation have more to do with the code directly dealing with the interface? Code I’ve seen so far wants RT to shuttle audio to the device, but otherwise doesn’t care how it gets generated.