The new “Order of bindings” stuff looks great. I think this should help some of my song setups that have previously been a bit unreliable. I think I had been assuming bindings were executed in that order anyway, which might account for some mysterious problems I’ve seen here and there. The ability to override rack and background rack bindings at the song level is particularly nice; it made me wonder whether a song binding set to “suppress” can have no target, to act purely to block the event from reaching rack or background rack bindings.
One thing I’m not sure about though - in the blog post it says:
This order has now been defined as follows:
Song bindings
Bindings in racks loaded into the active song, in the order the racks are in the song
All other rack’s bindings (except the background rack) but in an undefined order
The Background rack’s bindings
Does (3) mean racks not in the active song still have their bindings executed? Or does it mean for example bindings in embedded racks inside racks in the active song are executed?
Good point about suppressing a no target binding. Currently a binding with no target will be marked invalid and not configured into the MIDI processing chain so it won’t suppress it. Let me think about how to support this.
As for 3) it means bindings in “embedded racks inside racks in the active song”. Inactive racks loaded by pre-loaded set lists bindings don’t execute.
@brad
I got a question on this:
Seems like blocking binding only blocks (and queues) it’s source port. Would it be possible to have another type which would block all ports (aka - stop and queue MIDI processing completely until the action is finished)?
I often trigger song load from one port but some sound settings (MIDI CCs) then come from another port. Would be great to have a way to guarantee these are delivered to new song without using several seconds delay.
Thx
How could you be sure the other ports are blocked at the right time? I think it would be hard to know what data on the other ports would go to the old song and which would go to the new one (think separated note ons/offs)
This is a deliberate limitation because it was much easier to implement that way and I didn’t think there would be much of a use case for blocking all ports.
I’d be interested to hear if anyone else has this need.
I can live with blocking at the time of the event. I’m copying note offs to all channels anyway (physis master keyboard is a bit dumb on this) - which solves state load (I’m using it only to disable/enable ‘note on’ routes). And before song load, I’d make sure I’m not holding any notes or anything that should go to previous song.
The problem is I’m initiating song load from keyboard, but some song settings (channel volumes, keyboard zone on/off, hammond drive,…) are sent by triggers (still using old build) from cantabile on different port.
I could probably solve it somehow by mangling with loopback ports or setting high enough delay, but definitely could use ability to just ‘stop and queue everything’ until the song load is finished.