I have a couple of questions regarding song state changes. I’m hoping I know the answers already, but I’d like to double-check, as they influence how I’m setting up my keyboard rig with v3.
If the processing mode for racks changes as I change states, I temporarily get an hourglass mouse cursor, suggesting it’s taking a little time to carry out this change (whereas that is not the case when processing mode does not change). Is there any risk of this extra work affecting MIDI routing, or the speed at which routing for the new state is established?
If I change “Setup” on my Kurzweil PC3x master keyboard, it will send a program change to Cantabile to change state, and immediately after it’ll send various MIDI controller messages (mainly CC7) to set up the levels for the destination sound plugins. Can I be confident that these MIDI controller messages will be queued and routed based on the new state, no matter how soon they come after the state change message?
My first gigs with Cantabile 3 coming up in under 2 weeks now, and still a lot of programming to do!! Enjoying the new flexibility though, and learning lots!
Hrm. These are tough questions. The biggest problem here is that most binding invoked actions are invoked on the UI thread - not the real-time thread. So if they all coming through at the same time, the binding events will be dispatched to the UI thread and the real-time events will be immediately dispatched through the audio engine.
This is probably less than ideal, but kind of the way it needs to be without killing realtime latency/performance.
I guess the big question is whether the CC7 messages are going through bindings, or directly routed to the plugin?
Let me research this a little - I might be able to improve it by flagging certain bound actions as “blocking” so that when they’re invoked by a MIDI controller it starts queuing until the target action has completed. This blocking would probably need to be on a per-port basis though. eg: a state change event binding on one port could block cc events arriving on the same port, but other ports would continue to route as per normal.
Eeek I’m a bit scared now…If I can’t rely on those CC7 messages getting to the right destination via the new state routing, I may have to do a lot more v2-v3 migration than I had initially planned (I have a lot of carefully tweaked volume setting information stored in my master keyboard setups). Or not use song states. I currently have these CC7 and other control data going direct to the plugins, rather than via bindings (from what you say I’m guessing if they went via bindings you might be able rely on the ordering remaining the same).
But it sounds to me like you’d want this to be deterministic anyway, otherwise nobody really has any way of knowing how long it’s safe to wait after a state change before you can target plugins in that state. Consequently I think your “blocking” idea for bindings on specific ports sounds like a really good one.