I have bindings at the song level that move me onto the next song state.
Where there is a “stop” in the song - for example at about the 30 second mark in “C’mon Everybody” linked below, then I manually advance to the next state as we hit the stop. This new state changes the lighting.
I then have a binding that comes active during that “stop” so that when I play the 1st note of the next bar, then it automatically moves me on to the next state again to which starts the next lighting sequence.
My problem is that I hit the manual advance a beat before the stop so that the lighting change finishes on the beat. (and also sometimes I’m not accurate enough!)
That means that I’m still playing when the song state advance binding becomes active so it advances again!
Any ideas on how to “disable” the binding for a few hundred milliseconds? Or some other way to do it?
In most songs the key is different after the stop, so I can bind to a specific note, but in some, like this one, the key is the same, and I’m unlikely to remember the specific note that I’m using to advance the state.
I can’t think of a way to do this. Bindings aren’t binding targets so you can’t really control it that easy. The only way you might get this to work is to have it disabled in a particular state - but that’s getting a bit recursive.
This sounds like something that would be more properly solved by a combination of these two suggestions:
Actually this should be quite doable in a rack. Create a rack with three states: Disabled, Delay and Enabled. Put your “Advance to Next State” binding in the rack, but only enable it for the Enabled state. Also in the rack bind Rack State Loaded to Next Rack State with a 500 ms delay and only enable it in the Delay state. Then, when you change to Delay state the rack will wait a half second and then auto switch to the Enabled state, enabling your Song State binding.
If you always want the rack to go to Delay whenever the song goes to the Stop state, put an On Load Song State binding in the song that switches the rack to that state. Then only enable that binding in the appropriate song state.
Ok that works. Thank you. Now I have the next problem.
The 1st song has the “Advance to Next State” with a source binding of note E5.
Now I have a 2nd song that needs this delay. However this song needs to advance to next state on say F5.
I tried having a 2nd binding that was bound to F5, but I need each bindings to be independently active on only a specified rack state for a specified song in a specified song state. I tried ticking both checkboxes for “enabled” under state behavior but that didn’t allow this level of granularity.
It sounds like you are using linked racks for this. If you use embedded racks you can set them up uniquely for each song. Just right click the rack in question and select “convert to embedded” I think. I’m not in front of my rig at the moment.
Actually, I was thinking about how to make this more reusable. If you route Rack MIDI In directly to Rack MIDI Out and then only enable the route in the Enabled state you have a great multi purpose timer rack. Then you can bind the state changes at the individual song level to the output of the rack, to whatever key/button/pedal press you want to.
Is this the only way to do it? If we can get rid of this binding at song level then we don’t need any song state enabled bindings it can all be done with rack states - song state advance can be enabled for the whole song.
You’ll have to play around with it. One of the things I love about the way Brad designed the software topology is the inherent flexibility. This is the way that makes sense to me. There may be a better way to do it.
I’m not able to make the route enabling and disabling reliable, even without the delay. During testing if I play fast repeated notes, then sometimes some of them “get through” in between the song and rack states changing and the route being disabled.
I’m assuming the order of events is
Binding in the delay rack triggers song “next state”
Song switches to new state
Song state behaviour on the new song is processed which will switch the Delay rack to a new state where the route is disabled
Rack state behaviour is then processed on the new Delay rack state which disable routing.
I think that while 3 and 4 are happening, any received MIDI continues to get through the enabled route which then triggers the next song change.
Solved it by having a single “Auto Advance” rack that does the song state advance AND the delay all in the same rack, with no interactions with the song to worry about, or intermediate rack states to keep track of.
I have 1 state and enabled binding for each note that I want to auto advance from, and set that state from the song.
Then when the song state loads, the rack disables the route within the rack and waits a second before enabling it and listening for the note for auto advance.