Hi everyone, (new-user, first-time posting. Using b3187)
I’ve created a rack with ~10 states. I’ve manually switched each state, and they all behave as expected.
I next created 2 bindings for buttons on my midi controller (using the ‘learn’ to capture the midi controller info). I tried targeting these bindings to (Rack State) ‘Previous State’ and ‘Next State’ behaviors.
I see the midi-indicators on the rack light-up when I press my controller buttons, however, I do not see any rack state changes.
I suspect my bindings are correct, because if I switch the target to (Rack State) ‘change state program number’ (with different program numbers per button), the rack state does change.
Is this a bug?
Thanks in advance for any help,
This is definitely a bug in the beta code. (it does it on 3188 too) If you want rename your topic to reflect that you found a bug, @brad will see to it when he comes around next. Good find!
Thanks for the confirmation, Dave!
I just updated the title.
I’d like to be able to preserve audio tails, when I switch rack states.
Eg. If I have ‘Diva’ with a String patch, and the sustain pedal is held down - and I change rack state, where the new state has Ivory as the enabled vsti:
I’d like to hear the Diva-String sustain (and decay when I release the sustain pedal) after the rack-state changes to Ivory being enabled. Currently, I notice all voices muted on Diva as soon as the state changes to Ivory.
Is there a way to configure rack state changes with tails preserved?
The general idea is that when you change rack (or song) state, if you want to preserve audio tails (or in fact keep sounding held/sustained notes after the change), you need to keep the original VST active and routed to the audio output in the next state. Then, any notes you’re still holding, or any remaining envelope or reverb tails will continue after the state transition.
So instead of enabling/disabling VSTs, or switching audio routes, switch sounds by enabling/disabling (or switching the targets of) MIDI routes into the VSTs. If you do that, the state transitions will be perfectly seamless, with nothing muted.
The standard setup I have is a whole bunch of active VSTs, with all their audio outputs routed to my output device, and as I step through songs (or rack states), it’s my MIDI routes that are changing, selecting which VSTs will receive my note data. Cantabile has been very cleverly engineered to ensure that after state changes, when MIDI routes change, the note off or sustain up messages go to the original VST, not the new one, and so you shouldn’t get hung notes. Using this approach, I’ve had more than one person come up after gigs asking me how on earth I get such instant, smooth, glitch-free sound changes every time - Cantabile does the hard work for me
There will be times when for example, state 1 has a Diva sound, state 2 has a different Diva sound, and you want to maintain held notes or audio tails from state 1 into state 2. The solution to this is to use two Diva plugins.
Hope this helps!
Can you post a screen shot of your rack opened up in each rack state? It will help me see. Thx
Neil - perfect, I get this now. I’ll re-examine my state defs, but I understand the concept of how to make that happen.
Dave - no need to post screenshot. I can take it from here. Thanks for hearing me out.
Thanks everyone! Your pearls are getting me up to speed pretty fast.
@looney and/or @dave_dore
Could you please post screen shots of the bindings that aren’t working as expected - I’m not aware of any issues in this area.
If the bindings controlling rack state are in the rack itself, is the problem that the bindings aren’t enabled in all states?
Just one thought - are you using rack states for something the song states could do better?
I set up a test using the custom buttons of control panel to test so button one is controller 41 and button two is controller 42. Next I created multiple states in an empty rack for testing, this would be “route midi” target. The buttons will not advance and reverse the rack states for “rack midi” but will accept indexed targets.
Hope this helps …
Got it! Thanks. Will be fixed in next build.
Thanks @brad for the fix!