Hey people,
I thought that this worked before:
I have two empty songs. In both songs I load a linked piano-rack and save them. If I now switch from one song to the other while holding some notes, the notes will be cutted off… even with preload-setlist activated.
Is that meant to be like this? I thought, that seamless wouldn’t be a problem. I know that this workes for states… but not for songs, at least in my case.
Best,
Chris
The problem is that when switching songs, the MIDI route from your controller to your rack is broken, and re-established in the new song, and Cantabile (quite rightly) cuts any held notes to avoid leaving them hanging (it doesn’t necessarily know it’ll receive note-offs once you let go of the keys after the new song is loaded).
The only way I’ve found is to set up your rack such that instead of using Rack MIDI In, and a song-level route, instead you connect directly to the input from your MIDI controller within the rack. That means since the rack is not unloaded/reloaded, the route is maintained across song changes, and so your notes won’t be cut. Note that you may have those MIDI inputs hidden, which I think is the default, so you may need to set them to be visible first, in settings.
It works, but you kind of have to do it on a song-by-song basis, setting up a rack specifically to handle an intentional held sound across two specific sounds. You could even have specific rack states that use this special route, and use normal Rack MIDI In for other states. You wouldn’t want to have to stop using song-level routing because it’s so useful. So although it’s not a general solution for holding notes across all songs, whenever you specifically need it to link two songs, this should work for you.
Neil
Alright! Thank you very much for that hint! I’ll try that later! 
Hm, I was not able to get this running. But I need to investigate that further more.
But again @brad: If your time allows, could you explain, why seamless switching is not possible? I thought that all songs are loaded when preload is active… so to me there is no obvious reason, why that shouldn’t be possible.
Thank you very much!
Hi @FantomXR
The problem here is that when the song is closed to switch to the next one Cantabile shuts down all routes connected to other racks and to prevent stuck notes also releases any held notes.
ie: if you have held notes at the time the song is switched, Cantabile will forcefully release those notes.
The reason for this is that if the next song doesn’t have exactly the same routing from the keyboard to the rack - including all MIDI filters, transpose, keyrange splits etc… then when the note is eventually released it might not get to the rack - or it might with a different transpose setting and you end up with a stuck note.
The exception here is if the notes aren’t routed via the song - ie, directly from an environment MIDI-in port within the rack. For those cases, the routes are left active across the song transition and notes shouldn’t be cut off.
I do have some ideas for ways this could be made to work, but nothing that fits easily into what’s already there. ie: it’s not a trivial fix.
Brad
This is the method I alluded to in my post above, and it definitely works seamlessly - I use it in a couple of places with my band where songs need to smoothly lead into the next song.
Neil
I need to push this thread once more.
As I worked already a lot with it I know that it’s possible to switch seamless between songs, when creating the MIDI route within the rack. But anyway: I down-mix all of my racks in a “Songvolume” rack. If you do so, you will get dropouts although you create the MIDI route in the linked racks. Well, this is indeed correct, because C3 cuts all MIDI / Audio connections on song change. So if you want no dropouts, you need to send the signal direct to the output or to a songvolume-rack in the backgroundrack. But I wanted to point out, that this way of working is kind of “weird” and complicated. Don’t know if there is an easier way. As Brad already stated: Not a trivial fix 
It’s not a trivial fix, but I think it’s something I should take a closer look at. I’ve logged it for the moment, but will try to keep it near the top of my todo list (although it’s competing with OS X port atm).
This could be, next to the mixer panel, be the next big feature.
Maybe it can be fixed in a way that c3 keeps the current plugins in a temp modus so that they can load a new song when sustaining the current?
Hi @So_Godly,
This is actually a really tricky problem to solve because audio and MIDI routes need to be handled differently.
Suppose you have two songs that have the same racks. Say Rack 1 and instrument and Rack 2 an effects rack with rack 1 connected to rack 2.
My immediate thought I has was to keep both songs running at the same time, but then you’d have both songs creating an audio connection between the two racks - so the volume would be doubled.
So basically there needs to be some smarts (or some controls) that say to keep the MIDI connections running until released, but to cross fade the audio routes somehow… and then my brain shutdown. Need to think about this really carefully, but I’d love to find a solution for this.
Brad
Let the hive of the community think along with you 
Haha, if we can give some suggestions to help you.
I was thinking about an A/B stream to switch between. Will the volume be doubled if the new sound is different and adding to the previous?
Yes, I think it’s a wanted feature, many hardware synths have it these days also, or advertise it as a big feature, I see that Nord Stage 3 also brags about it.
Not sure what you mean… it would depend how you set it up.
I mean keeping the current song playing and connecting a second to it…
As in the states, this is a solution, but you can’t on song level because of the keys connection.
Maybe that flow should be redesign?
Or maybe we should have the choise at startup of a setlist? So that the setlist is at song level. Does that make any sense?
Apparenlty somebody found a way, but this is done in the states most certainly
The only way I can see it working is if Cantabile had a new “song group” or medley object, containing multiple songs intended to be played seamlessly together. The song group would load all the racks/plugins for all its songs, and would be “aware” of the configuration of the next song, and would regard all the song states of each song as one long song group state list. Cantabile would need to be able to support multiple instances of racks. It opens up lots of really difficult technical questions, like what happens if you modify one instance of a rack, when there’s another in the same song group. It’s a bit of a minefield.
Perhaps a compromise would be that Cantabile could support it for songs that don’t contain any linked racks. That might solve some of the technical problems, albeit with the compromise that songs would use more RAM and take longer to load…
Neil
I’m taking a lower-tech approach and am going to hum into the mic between songs.
I’m sure the media player shuts off when song-switching, right? Otherwise that would be another way of presenting inter-song humming.
Terry
[EDIT - clearly, Cantabile Songs might not have been designed with Album-Prog-Rock in mind… we’re on the prowl for “seamless” transitions here!]
That’s the correct way to think I guess
Take it all up a level, with the right compromises of course.
Setlist become => Songs
Songs => State
State => Substates?
The correct way is to discable the midi binding to that plugin, correct.
So make it that the songs work with the same level of bindings and disconnect when switching?
I’m sure it isn’t as easy as I imagine … hahahhaha
Has any progress or workaround been figured out to help with this?
Hi All,
I’ve not tested but have some theories that might work but they might seem odd so I share them fully aware I may be missing something obvious.
In the use model the requirements for a medley are that I can load any new song with it’s tones and instruments in a medley fashion while maintaining the tails and patch tones from the previous song. This requires a lot of memory and fast disk streaming because operating this way can get heavy because you can get a lot of plugins loaded at the same time when transitioning from song to song. Ideally the old real world model comes to mind that is if I had all my old stacks of hardware gear this would be easier to do because I can just hold the damper down to hold some keyboard tail and make my patch switches on my other boards while that is going on and switch to playing a newly loaded synth or synth sound over the decaying tail from the previous song and carry on from there.
The conventional approach is that Cantabile Songs hold the plugins and the linked and embedded racks and the bindings specific to that Song. In the approach I outline here the Background rack holds all the racks and plugins and the Songs hold the bindings for changing the configuration of the background rack and any other Song specific racks that are not adversely affected by the muting that occurs on a Song change for Audio. Since the reason for the muting revolves around loading and unloading of the plugins and audio producing racks you can’t escape certain resource demands when you want to perform medley style because you would need to use states in the same song or rack to pull it off but you already need to do that when you use Song states to put together medleys now so the resource issue is a given consideration either way.
That’s the workaround I’ve seen discussed and used which is to combine Songs into a medley song as Song States. So that is why I thought the Background rack implementation may be another avenue to do medleys but in a random select way. The list of requirements for the BG Rack and the Song are listed here.
BG Rack
Song
So as you see the focus shifts a lot of the load to the BG rack because it’s always ON even on song changes. By using the split screen for the BG rack and song level bindings you can set up the song patches fairly quickly so that isn’t a drawback. This is the rough outline of my theories on the subject and without some testing it’s viability. Here is a block diagram of the concept.
So the discussion of this concept / method is opened, please chime in with any thoughts …
Dave
I set this method up and it worked pretty well once it was all built. The key was making a template song file that held mirrored controls of the BG rack plugins. I thought there might be memory problems with that many VSTs loaded and running but with no MIDI input they use relatively little resources till you feed notes into them. From a purely VR point of view this model is more conventional in that all instruments are on all the time and ready for notes no matter what song if they load provided the input route is enabled for that instrument. Now that I know it can be set up this way the other questions left to explore are about how one could delay PG changes till a pedal or the held keys were released from the previous song. All in all it appears to me it could be done this way.
In the spirit of discovery I continued work on this environment test and ported the transpose & song transpose to the BG rack but found that the only way to do ranges was to set up the ranges & splits in the BG rack and save them as a BG rack state.
I played it a lot and the following observations were worth noting.
If the instrument, gain and patch are the same for both songs it is seamless transition from song to song with held notes or CC64 held notes.
If you have a patch change sent with your song change while holding the keys down or with CC64 On it will switch to that sound and keep sounding till you release the pedal or notes.
I found a means of delaying the patch change send until a key release or CC64 pedal release for cases when you want to hold a note down with a given patch and have it hold over into the next song selected but need a patch change upon release. I found it worked best with fast attacking & decaying style patches, the long decay ones sound weird when cut off this way so on songs where there are used to end a song the next song should have the same patch so the decay tails don’t get snipped.
Very nice having the chord still sustain out while having the Show Notes brought up for the next Song before releasing the keys
it’s quick on song changes, I assume because of less rack and plugin loading and off loading
it appears to be stable, I haven’t crashed anything yet with it
To fully explain would require a video I think …
Dave
In playing at church, it’s usually really important to have seamless switching to avoid dead air between songs. And pads typically fill that dead air nicely, only they get cut off harshly between songs. I’m glad this is something people are trying to figure out. Just brainstorming some ideas, not being a programmer…
Have the option, per song, to keep trailing audio for 5 seconds (or whatever measure you choose) after the song has been switched, then cut it off, avoiding any stuck notes. This would be time-based, not controller-based. By then I’m able to start the next song, click, etc. Of course, how to do this is the difficulty, looks like. What about keeping all of the VSTs from the old song active for that time period longer, sustaining all notes (pedal) for a few seconds? I already have all VSTs preloaded for the set, so memory is not likely an issue.
As @brad explained earlier if you’re using linked racks and they’re the same between songs but you have a transpose, etc. that could cause a problem. But I’m thinking of a couple of things here:
Another option, and this is probably not feasible (but brainstorming is not about what’s feasible), is that if seamless switching is on for Song A there’s a 1-bar (configurable) audio recording “cache” that’s happening through the whole song. When the song is switched it loops that 1-bar WAV file for however many times you have configured it to. Lots of problems with this, but maybe it’s measured in seconds, not a metronome count, being that you don’t always switch at the end or start of a bar. Most of my transitions would work with a simple audio loop of the pad sound carrying on for 3-6 seconds.
