I’m watching this discussion.
2 Likes
I guess these input/output background racks would be very similar to the existing background rack, so maybe you could use the existing background rack for this purpose. However, to do this, and allow songs to drive plugins in the background rack, I guess you’d need loopbacks and so on, which might start to get messy.
I think the background rack is really intended for very global keyboard-rig wide configuration such as bindings, that once you have them set up, you rarely need to fiddle with or think about. In contrast, I think input/output racks would perhaps have a more prominent role, possibly being rendered in the routing view and so on. But in practical terms, yes, they’d kind of work like the existing background rack.
Of course, as always, Cantabile is super flexible, so actual use cases is often limited by one’s own imagination!
Wouldn’t “Save Song as Rack” and “Save Setlist as Song” features achieve this (without requiring any deep changes to Cantabile’s infrastructure)? To get an extra background rack, save your songs as racks, put the racks all together in one song, and let song-states control which get loaded/unloaded when. Any racks you want as background get set to “loaded” on all states. “Save Setlist as Song” does it automatically for you, so you can get such a song with a click of a button.
That solution seems like it gives superior power (unlimited number of background-like racks, full control over what loads/unloads when, state-controlled settings changes during transitions if desired, etc.). And it gives newer users an easy migration path to this advanced feature.
Well, currently, I am using a set of input and output racks across all of my songs - a couple of racks to abstract the keyboard and guitar inputs, one “master rack” to manage output EQ, limiting, metering and routing. This absolutely works, but it means that all my songs need to contain these racks - makes songs unnecessarily complex.
It would be far easier if I had all my input stuff in one “hidden” input rack, providing just a number of audio and MIDI input ports to my song files, then all my output processing in the output rack, where I can just send my song output to “master - keys” and “master - guitar” outputs - done! Far simpler to construct new songs that way. Currently, I use template songs to have all my pre-populated in- and output racks to start out with when creating something new. Also, songs would be optically cleaner.
In addition, with a permanently loaded “Output rack”, we could have reverb tails ringing out across song changes, or media players continuing to run, as well as held notes continuing across song changes - not possible with the current model of racks inside songs, since audio routing and processing stops while changing songs.
For me, since I don’t need seamless song transitions, this would just be a bit of a convenience and time-saver, nothing super-critical. But I’d assume for those who want some kind of continuity across song changes, this could be pretty cool.
uuuugh - just imagining this makes me itch 
Putting all my complex setups for one set together in one setlist-master-song would be just a major mess-up waiting to happen, complexity-wise. Just out of hand I can see a number of real-life issues I’d find problematic or show-stopping in this approach:
-
shared linked racks: these would be linked in multiple “song racks”, but frequently in different rack states. Currently, there is no way to use linked racks within racks - and that’s for a good reason. I see all kinds of possible conflicts and issues popping up. Alternatively, they could be converted to embedded racks - but that would mean having these plugins loaded multiple times in a setlist - that would definitely be a show-stopper for most non-trivial linked racks
-
routing to output racks: having “songs” contained in individual linked racks would mean that they can only send their output to rack outputs or environment audio ports. Using output racks for master audio processing would mean that I’d have to route each song rack manually to the master rack every time I construct a new setlist - no thanx… Or use loopback ports to avoid manual routing, but that means incurring one additional buffer of latency.
-
song state changes: using song state changes would mean using rack states to step through song sections within song racks. Having multiple song racks loaded, Cantabile can’t know which ones are currently relevant, so you can’t use a global binding to “go to next state in current song rack”. This means that you’d need the “next song state” (now next rack state) bindings (to switch song state via a button or pedal) within every song rack, instead of conveniently sitting in the global rack. Plus, this would mean that these state change bindings affect all currently active racks - difficult when you have two songs active to manage the overlap…
-
global bindings: similarly, any controller parameter changes would affect all active song racks, potentially creating unintended side effects (rotary control affecting filter cutoff in one song, string volume in another) when having multiple songs active at the same time.
IMHO this approach would create more issues than it is attempting to fix.
Just my 0.02 EUR, though…
I think extra-background-racks are songs-as-racks. They’re the same solution by different names (but with less flexibility).
-
shared linked racks: Setlists currently load and unload linked racks and their plugins as the setlist progresses. Songs-as-racks can achieve exactly the same operations using states/bindings that load/unload embedded versions. If there’s any kind of loading/unloading that a setlist can do but that a song can’t, then that would be a good feature to request for Cantabile.
-
routing to output racks: “Save setlist as song” could do it automatically, basically creating your “template song”. (Like you, I currently use template songs for this. I use “replace rack” to avoid needing to rewire stuff.)
-
song state changes: “Save setlist as song” would convert song-state bindings to equivalent rack-state bindings automatically, and would enable those bindings only for the relevant song-state. Again, this is already what setlists essentially do, you just can’t edit it.
-
global bindings: Analogous solution. This is already what setlists do, but you can’t edit it.
If all this seems complicated, I think it’s only because these complications are currently concealed from users when using the song and setlist abstractions. It’s all there, but you can’t see it or change it even if you want to.
If songs and setlists were just another kind of rack, it would open options to customize it, automate it, hide/unhide stuff, mix-and-match them as desired, etc. Instead of asking Brad to create each individual SST/background-rack feature, we could implement any fathomable customization ourselves, and if something becomes a common use case then we could ask Brad to consider automating it and making nice visualizations for it. Or users could share scripts and racks that implement whatever SST and persistent-rack ideas the community finds appealing.
In a nutshell: Songs-are-racks is what I see as the critical first step toward achieving everything requested in this thread. It doesn’t solve everything, but it provides the infrastructure for solving it.
Thanks @Neil_Durant and @Torsten for entertaining my dumb Q with your insights.
I would also love to see an equivalent of “smooth sound transition” or “smooth sound switching” as I have in my Korg Kronos and Montage M. I even had it in my old rack rig and my upper tier keyboard - a Novation Remote 61, which not only had release velocity (my first ever board with that) but it also kept MIDI notes held down latched when you changed Novation Remote 61patches until you released them, so with care in terms of Rack Unit patch changes (e.g. across the FS1r, Motif Rack ES, Norg G2 Engine, A4000 and PC running NI B4II) you could hold sounds whilst switching to a new one. When I retired all of that for my Korg Kronos X61 it became much simpler of course as an intrinsic feature, and I used it all the time within songs in the Floyd set where songs had a lot of scene changes within songs! For example in "Shine on you Crazy Diamond
- Scene 1 Intro pad and synth lead on top keyboard, organ/effects on lower
- Scene 2 (holding the scene 1 pad when swiching) and Organ manuals on upper and lower keyboards
- Scene 3 (holding scene 2 organ upper manual on lower keyboard - yes that way around!) swithcing to lower manual (different sound) and lead on upper manual for second keyboard sole
- Scene 4- back to scene 2
- Scene 5 pad outro where I switch to it in last bar whilst holding the last organ chord.
All that is a piece of cake in the Kronos, being able to replicate that inside the box with Cantabile/VSTs would be amazing
My thoughts on the background rack: I started using it for storing things like my FC300 rack that maps FC300 patch changes to Cantabile song changes in set lists, but I then realised “what happens with me having different bands and different set lists”? So I ditched using the background rack, and had a different linked rack common across songs for each set.
So I think it would be cool to be able to have specific input and output racks common across a set for common set processing. Also a rack for common send effects, that could continue processing sound across song changes within the set.
That’s not how linked racks work in pre-loaded setlists - they stay loaded, just not routed and processed. If you need loading and unloading of “song racks” within a “master setlist” song by activating or de-activating racks, you’re talking a completely new mechanism - this would be a significant re-engineering of Cantabile
This would mean that current songs (including output racks) would need to be “pulled apart” by “saving setlist to song”.
But my “next state” bindings are global, not song level - this would mean having to duplicate a shedload of stuff to song-level…
Honestly, I think you are assuming quite a bit to happen implicitly with the “songs to racks” option; and it is creating too much complexity for my taste.
There is a significant difference between Cantabile’s current Setlist approach, which is essentially just “loading and unloading songs in sequence one at a time”, which keeps all the actual audio routing and switching between a single song and Cantabile, and OTOH your approach that says “just put everything in one big complex master-setup at the same time and make Cantabile juggle between it”
I guess we’ll just have to agree to disagree…
Hey @Derek,
all this (and more) is already possible in Cantabile in its current form. Switching scenes (i.e. song states) whilst holding certain sounds and moving sounds to different areas on my keyboard setup is a common thing in my setups - best solved by creating a number of different routes in parallel and activating / de-activating them based on song states.
Cantabile is very smart about avoiding stuck notes when switching routes on or off. It keeps track of what notes are held within one route and “waits for” the corresponding note-offs even after that route is disconnected.
But the discussion we are having here (as I understand it) is how to keep sounds active across SONG changes, not just state changes…
1 Like
I want to share more about how I use Cantabile, to see what capabilities I would need to sacrifice if I reconfigured all my songs to use one of the work-arounds above.
- I have a set-list of 24 songs for a gig. I preload the entire set list (800 plugins), which on average gives me 3-4 second song-transitions but sometimes 8 seconds. It’s all 90s dance cover songs, so close-to-zero “dead air” is a goal.
- Every song has a custom MIDI tempo track which acts as the “Master Sync” for that song. It’s tempo-mapped to the original artist’s song exactly using per-measure tempo-changes. This allows me to use elements from the original song, in our live performance - in perfect time.
- I have multiple “sync slave” media players that have pre-recorded backing tracks for drums, bass, keys, “other”. I toggle these on-off depending on which musicians are performing a gig.
- I have media-players that contain MIDI files with temp-sync’d arpeggiated parts.
- I use States to automate patch changes in plugins for the band’s MIDI keytar and live MIDI e-drummer, so that they don’t have to worry about manually changing sound-patches mid-song (verse/chorus etc).
- The tempo-track shows all the notes I play, and acts as a visual aid to remind me what’s coming next in a song’s arrangement.
- I use a number of linked-racks shared across all my songs, for things like my reverb chain, delay chain etc.. sadly, sound from all of these is cut-off when I change songs.
- A song typically ends with either pre-recorded sound from a WAV file in a media player (e.g. a crash cymbal) or my final played note - usually with a long delay FX tail.
So right now, I wait until all those tail elements are pretty much inaudible, with my finger hovering over the “NEXT SONG” button on my MIDI controller. Then I wait 3-7 seconds for the next song to load, and then hit the PLAY button. Then I wait again for the count-in (4 or 8 beats) to finish before I start playing.
In summary, I heavily utilise song level capabilities:
- master MIDI tempo file.
- song timeline visualisation
- sync’d - MIDI notes from media player
- sync’d patch-changes
I’m happy to agree to disagree, but really my only motive is to be helpful in this discussion. I don’t need any of the proposed feature additions because I already have them. I already use racks as songs, so I already get SST, pre-loading, persistent input+output background racks. All the requested features are available to me because I created my songs as racks from the start. But if I hadn’t done that, I’d need a way to convert them in order to get all these features. That’s why I suggested it.
I already do it. I just let song-state behavior control activation/unload status of my plugins and racks. No re-engineering required. I can pre-load whatever I want under any conditions I like (a testament to Brad’s wizardry!).
I don’t see how extra-background-rack avoids this. You must still move your song-level output rack to a newly added extra background rack if that feature were added, correct? Same conversion steps would apply to saving a song as a rack.
By “global” do you mean they’re background rack bindings? A save-as-rack feature must indeed auto-convert song-state binding sources/targets to equivalent rack-state binding sources/targets and put them in the saved rack. Whether to include bindings from the background rack could be a save-option.
I guess I don’t understand why my suggestion is hard. Quoting the “Racks vs. Songs” part of the guide: “Racks and songs are very similar and working with a rack is almost identical to editing a song.” This indicates to me that Cantabile probably already internally stores songs very similarly to how it stores racks. Saving one as another is probably not a huge leap. But if it’s as “deceptively complex” (Brad’s description of SST) as the alternatives, then maybe it’s not the answer.
Thanks for writing this @Torsten, I was going to write exactly the same but you beat me to it! 
I too have many many situations where I hold notes/chords over transitions. In fact in some cases, I hold a chord, switch to the next song state, and then even manually fade the sound out using an expression pedal, while I can be playing new notes on the new sound, in the same keyboard zone. Cantabile is amazing for this - you just have to work at the MIDI route switching level.
But yes, this thread is really about smooth transitions when switching between songs, rather than song states/scenes.
2 Likes
Thanks @Neil_Durant and @Torsten
It’s useful info as I have never had to do that in Cantabile as my Kronos is handling it in my old Floyd set list, and my current improvised electronic show, the songs are a little more static in configuration, so good to know it can be done.
I agree I have pulled this OT a little by diving into songs, but invaluable information none the less from the masters. Cantabile remains amazingly flexible.
I will focus any future comment in this thread on smooth transition between songs, which I think would be a fantastic feature.
2 Likes
I’ll add my vote for Background Input and Output racks. Like many others stated I also have “Master” racks for Output processing that are inserted in each song, for global processing across all songs and setlists.
I don’t think I would use the Input rack much other than an initial setup… quite often my song states mute or change routes in the song’s inputs, and that’s song-specific, but I can still see the value of a background input rack, as long as we keep the Song Inputs.
I apparently need to dive deeper into Neil’s point about holding notes through song state transitions, which I sometimes have problems with. Many times my Audio Engine has a brief off/on cycle when changing states. And these aren’t always samples. I wonder what’s causing that?
It’s usually not an issue since it’s so brief and i’ve learned to play around the transition. OTOH I do occasionally have a media player that runs fine across state changes, and lately I’ve been using a fader rack during state transitions and I can get it to be seamless. I do use parallel routes toggling for the most part. Hmmm, I have to look into that.
Tom