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.
- holds all the plugins and racks for a whole set
- holds all master rack FX and processing
- uses the parameters sent by the song “On Load” bindings in the Song files to configure the BG rack plugins and racks
- parameters sent need to mute and unmute audio routes
- a medley flag to prevent unwanted muting or disabling of plugins and racks
- holds media players which are fully loaded with all tracks for the show
- holds dummy embedded racks that mirror some of the main BG plugin slots controls via bindings
- holds any Song “On Load” configuration bindings for the BG rack instruments and Media Players
- holds any specific racks that are unaffected by being in the song instead of the BG rack
- holds show notes
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 …
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.