Up until today, the order that bindings execute has been “undefined”. For most bindings this is perfectly acceptable as the order is irrelevant. For bindings that have a blocking or suppressed routing mode however, this is an important factor and has now been properly defined and implemented.

Routing Modes

First, a quick refresher on binding Routing Modes. The routing mode of a binding defines what happens when an incoming MIDI event matches a binding. You set the routing mode by right clicking on the binding slot and three modes are supported:

  • Continue — the default routing mode and causes the event to continue to be routed to other targets
  • Suppress — any further processing of the event is suppressed
  • Blocking — any further processing is suppress and all following MIDI events are blocked and queued until the target of the binding has finished executing.

So when would you use each of these routing modes?

  • Continue — for most value bindings. eg: binding a slider to a gain control
  • Suppress — for when you’re overriding the purpose of a button. eg: binding a note to an action and you don’t want the note event to continue on to a synth.
  • Blocking — for binding to slow operations like song and state switches where you need to send follow up configuration data once the load has finished. eg: an external device sending events to load a song and then configure it in a certain way — you want the song to finish loading before accepting the configuration events.

Order of Bindings

As mentioned, up until today the order of bindings has been “undefined”. That is to say that there was no guarantee on the order in which bindings were processed. For Continue routing mode bindings this is fine — all the bound targets will be invoked.

For suppress and blocking mode bindings however the only thing that was guaranteed was that bindings would be processed before regular MIDI routing. This was enough to suppress a note event from reaching a synth but didn’t provide any control over the order of multiple bindings.

This order has now been defined as follows:

  1. Song bindings
  2. Bindings in racks loaded into the active song, in the order the racks are in the song
  3. All other rack’s bindings (except the background rack) but in an undefined order
  4. The Background rack’s bindings

Also, the bindings within a single song or rack are now guaranteed to be processed in order, from top to bottom.

The most important part of all this is that the Song bindings take precedence over the Background rack bindings.

Let’s say you have a button on an external controller that for all your songs you want it to perform some function. You could create a binding for that action in the background rack.

Now let’s say for that for one particular song you want to change that button to perform some other action. If you create that binding in the song and set its routing mode to suppress — the song’s binding will take precedence over the background rack bindings and effectively override it.

Available Now

All this is available now in build 3194 which is still marked as experimental but now getting close to stable.