Order of actions

One thing I was wondering about the new jump prevention feature - at what point during state setup do bindings become operational? I’m wondering about the scenario where controller data is coming in, and there’s a trigger to set the initial parameter value. I guess what we need is some assurance that the trigger occurs before the bindings function, so that jump prevention is working off a well-defined parameter value.

It’s a similar question to what would happen if I have a held note playing sound in a rack, and change state, where the new state sets rack gain to zero, but inside the rack the new state sets the volume really high. Or the other way round. Is there a chance I could get a momentary loud glitch before the zero gain kicks in?

This is a real scenario. Suppose I have two song states, and I expect to be holding chords across the transition. Song state 1 requires the level to be controllable via expression pedal, going quite loud, and song state 2 requires a fixed, specific, fairly quiet volume level. In state 1, the rack internally has a fader driven by a binding for the expression pedal, going from -inf to 0dB, whilst the rack gain is set high to allow the expression pedal to bring the volume up high. For song state 2 I would need a trigger to set that fader to 0dB, while the rack gain would drive the overall volume. As I change state, is there a chance that the internal fader would be set to 0dB whilst the rack fader is still high, before the rack fader gets set quiet? Or the opposite scenario, where I’m going from a low to high rack gain, while setting the internal fader from high to low.

These questions got me thinking that it would be really useful if there were some documentation on the order of when things happen, to help us deal with some of these awkward parameter changes.


Hi Neil,

You’re right - some detailed documentation on this is problem in order. In the meantime, in general, bindings are activated before load triggers are fired and deactivated after unload triggers are fired.

The problem is when you have slow loading plugins - and in particular plugins like Kontakt which spin a message loop while loading and this allows for re-entrancy.

While using bindings and triggers does work for getting a song and racks into an initial state - I think moving forward a better approach is going to be the ability to reset a song/rack to a particular state. ie: the things we discussed in another thread where Cantabile will automatically re-apply parameters when loading a state that’s already loaded.

I’m still thinking about the best way to do this.

Do you agree - will this kind of functionality help in this area?


1 Like

I think it will help, as long as the state reload can be fast, so that in the case I mention, the time between a fader within a rack being set to the target level, and the rack gain being set, is negligible. I guess in general, you shouldn’t need state load triggers to set internal parameters, as states should be able to cover everything robustly.

Thank-you for the clarification on the order of activation of bindings and triggers - useful to know!