there is still a bit of funnyness around triggers in 3106:
I encapsulated my VoiceLive (external device) into a Cantabile Rack, with the rack’s MIDI input being routed to the VoiceLive’s external MIDI port and with triggers that send program changes to the VoiceLive per rack state. This way, I can just treat the VoiceLive like any other rack in my songs and select the setting I want via rack states - makes things easy to see and control at song level:
The problem occurs when I try to use Cantabile’s transport controls to synchronize the VoiceLive’s delay time to the current song’s tempo: for this, I use two triggers, three seconds apart to start and then stop transport, thus giving the VoiceLive enough time to synchronize to Cantabile’s tempo. These triggers are only active for a certain rack state “LeadVoxDelay TempoSet”, inactive for all others.
When I attach these triggers to “Rack State Load”, they fire reliably on any state change, but they don’t fire when I initially load the song and “LeadVoxDelay TempoSet” is the first state. Since the other trigger (that sends the program change to the VoiceLive) is attached to “Rack State Load” as well and still fires reliably on loading the song, there must be something special about the transport control triggers that prevents them from firing at song load time…
For the moment, I have attached the trigger to “Song Start” instead of “Rack State Load”, since I only use this tempo setting at the beginning of a song anyway, so things are kind of working out for me. Still, it’s probably something you might want to look into.
when I switch to the song with this “Delay TempoSet” state as first state, still nothing happens
but when I switch to another song afterwards that DOES NOT have this “Delay TempoSet” state in it, suddenly transport starts (at some crazy position like bar 950)
So it seems the transport start command is cached somewhere and then released on the next song switch - funneeeeee…
I’ve looked at this and the problem stems from firing triggers during the song transition. So I’ve made some fixes:
When switching songs it now waits for any pending (delayed) triggers to complete before starting the switch. It’ll wait up to 1 second and after that, all pending triggers are cancelled.
Triggers are blocked from firing during the song transition, queued and fired once the new song is fully up and running.
The mechanism by which triggers are broadcast across songs and racks has been improved to prevent song stop events being invoked on the newly loaded song. (previously when switching between two songs with a delayed song stop event, the stop event was actually invoked on the new song rather than the old song).
Anyway - let me know if this is better in the next build (later today probably).
in the newest build (3109), suddenly my SongStart triggers within the rack don’t fire anymore when switching songs
changed the triggers to rack state load - great, they fire on song switching; no more spill-over effects
but one strange anomaly: when switching between two songs, both with the same state (TempoSet), but different tempo, there are strange effects: switching from song 3 to song 42, the state load trigger fires (even though it is the same state in both songs); switching back from song 42 to song 3, the trigger does not fire again
when switching between songs with different states for the VoiceLive rack, triggers fire reliably when entering the “TempoSet” state
So I have a bit of an issue now with two consecutive songs both needing to initialize the tempo - can’t be sure that the trigger will reliably fire. And my solution using “song load” triggers (that would now be my preferred solution due to the “same state” issue) does not work anymore.
Guess we’re getting there with the “rack state load” triggers, but lost the “song load” triggers on the way…
I’ll see if I can knock together a reduced test case that shows the same behavior. Will probably take a few days - will be pretty busy the next few days in my day job…
