Concurrent Rack-specific Tempos?

I have a puzzle for the ever-wise Cantabile binding gurus. :slight_smile:

Background: My band plays overlapping songs in each set – as the last chord in the previous song rings out and fades, we start playing the next song overtop it. To do this, I have a Cantabile rack for each song, and a Cantabile song state for each song in the set. Switching song states activates the MIDI route for the next rack, allowing the previous rack to continue playing its final notes until I release them while the new rack plays fresh incoming notes.

Question: This all works wonderfully except for one nagging problem that I’ve never been able to solve: tempo-locked sounds. Many patches and effects are tempo-locked (e.g., echo delays, bpm oscillators, arpeggiators, pulses, etc.). When I switch song states, these patches go wonky because the global tempo changes for all racks, including the previous rack whose sounds are supposed to continue playing at the old tempo but are now suddenly jumped to the new tempo. Sometimes the impact is very glaring.

Does anyone else face this problem? If so, how do you solve it?

Thanks,
–Kevin

Essentially, if you need certain effects to be robust vis-a-vis tempo changes in the song, the only real way is to make the actual patches independent of host tempo. Essentially, you’ll need to create song-specific effect or synth patches that don’t “sync to host” but have their own tempo settings internally (not all plugins give you that option, but a lot of them do).

I do this frequently when using delay plugins that create this wild “slowing tape” effect when the host tempo changes. So I’ll have multiple delay racks in such a song, each with its own “hard” tempo embedded, so that the “old” delay may ring out and the new one can start fresh. I’ll simply route my instrument (or guitar amp) to the respective delay rack, with the routing driven by state change.

It may be helpful to have the plugin tempo parameter exported to the song in the “state behavior” tab, so that you don’t need too many plugin or rack presets for differing tempos (depending how many songs you use that rack in).

Cheers,

Torsten

1 Like

With that approach, how do you control when each oscillator “starts”, so that it syncs with other plugins and the click?

For example, Omnisphere LFOs have three choices: Song Position, Legato, and Free. Song Position goes wonky when the tempo changes. Legato doesn’t work when notes are played off-downbeat. Free would work except that I don’t think there’s any way to start/stop the LFO at any particular time, so I can’t seem to find any way to sync it with the rest of the band or with other plugins. Is there a way?

TBH, I mostly use this for delays, where there isn’t a need to synchronize - it is simply driven by the input timing. So no syncing issues.

Ugh, I haven’t come across that yet - I typically just use arpeggiators at best, and I play them as I would on a hardware synth. So sync is driven by my playing - I typically use legato mode with my arpeggiators so the pulse stays constant and gets started on my first note-on.

Just spitballing here - would using a separate arpeggiator like Kirnu Cream or Stochas or some sequencer plugin as kind of a “master” arp help synchronize your patterns across plugins (instead of having the tempo inside each plugin)? Would probably work for arpeggiator patterns, but not for tempo LFOs, I guess.

Too sophisticated for me, I’m afraid…

I use BlueARP for arps, but I can’t think of any way to make an arp engine drive a synth LFO. I could set the synth LFO to Legato and have the arp engine stream notes to it, but that would make the synth play extra notes instead of pulsing my held notes to a beat.

But your suggestion raises another interesting idea: I just came across Unify plugin’s transport settings manual page, which seems to say that Unify can have its own per-instance transport, which would maybe allow one to load plugins like Omnisphere into Unify, and then run them at a fixed tempo there. I guess that would require pushing all my plugins into Unify instances and then threading all their automation parameters out through Unify to Cantabile, which sounds cumbersome.

I don’t own Unify, but I wonder whether anyone who does has ever tried anything like this?