Coming soonish: Global Pre/Post-Racks
As always, open to feedback, thoughts, suggestions etc…
Hi Brad,
I like the direction it’s taking. I use a master output rack in every song. Can I specify that rack as my global output rack? For those of use who use this architecture will we have to rework all our songs that do use a master output rack or will there be the possibility that it can be done by the update? Great work BTW, it makes good sense to me. 
Dave
3 Likes
Hi Dave,
I hadn’t planned to provide an automatic migration from existing master rack to pre/post rack - primarily because I suspect it’ll be a bit different for each user. So unless I can come up with something simple, then yes you’ll need to rework your songs to use this approach.
Basically for a master output rack you’d need to move everything from the master rack to the Global Post-Rack and then for each song:
- Remove the master rack
- Change any routes to the old master rack to “External Ports → PostRack: [portname]”
One way to help with this would be some sort of alias system that allows remapping a particular rack to the post rack. Let me think about it.
Brad
1 Like
I don’t (currently) have a need for this, but it looks a great improvement for those who do
Hi Brad,
Thanks for the explanation. I have thought on it some more and am sure it will require that I go the route you offered up. I use a Reverb rack as well that is global to all songs and would want to rework the output rack to include a discreet input port for it in addition to the dry port. If it could use an alias for it’s routes that would also help. In general the aliasing idea would save a lot of individual routing edits in each song so if it can be done I’m for it.
Dave
2 Likes
Right… so you’ll probably want to consolidate the functionality of both of your current racks into the one Post Rack. You can create additional input ports on the post rack for different output targets/routing if you need them.
I’m still thinking about the alias idea. For this to work seamlessly you’d also need the ability to automatically remove your old post processing racks from each song. I don’t really want to build UI for this and have to support it forever - maybe a batch update script might be easier.
eg: something like this that updates all songs in the current folder.
cantabile-batch-update --update-route-target "MyOutputRack|Audio In" "OutputPorts|PostRack: Audio In"
cantabile-batch-update --remove-rack "MyOutputRack.cantabilerack"
2 Likes
Yea, I like that approach just fine and it leaves those who had no Master style linked racks from the extra work. I do have a few additional questions though regarding other default ports. Is any object that is routed to ‘Main Speakers Out’ going to be automatically re-routed to the new Output rack and to a thru type route to the ‘Main Speakers Out’ or will they be left as is? If it wasn’t done automatically at update and I wanted to do it that way I guess I could add that to the batch file. Thanks for the feedback, it appears a way will work it self up to get it done.
Left as is. The only real change the new system makes is to repurpose your old Background Rack as the new PreRack - that way all your existing background bindings will carry over. As for routing, nothing is changed, so these new racks don’t have any effect until you start using them.
Yes.
Brad
1 Like
Sounds fantastic, and it will help me clean up my songs massively!
Just checking: the processing of pre- and post-rack will all be part of the same audio-cycle - correct?
My typical workflow would be to do quite a bit of pre-processing of my hardware MIDI inputs into “logical” ports, then use the output of these logical ports in my songs. Currently, I’m doing this processing and mapping in my background rack, feeding the result into the loopback for my logical MIDI ports. But this incurs a penalty of one audio cycle, which is why I still need some abstraction racks inside my songs for notes etc. and only use the loopback route for less time-critical tasks.
If the Pre-rack gets processed in the same cycle as the song, I can now do ALL my filtering and mapping in the pre-rack, including notes, PB etc. That would be very nice indeed - I can then also embed the different velocity maps I have for my different keyboard options directly in the Pre-rack instead of having to use presets in my “main keyboard” rack inside the song file.
@brad: would be nice if you could confirm that everything is one audio cycle: Pre-rack → Song —> Post-Rack
Cheers,
Torsten
1 Like
Yep pre-rack, song, and post-rack are all processed in the same audio cycle.
5 Likes
Excellent! Looking forward to the new version - definitely a game-changer for me!
1 Like
I just thought I’d add my 2 pennies worth here in terms of how I use the current Background Rack (which I’m sure will be frowned upon by some but serves my needs). This may be slightly off-topic but is my use-case so figured this might be applicable. Sorry its a bit wordy…
I, like Torsten and others, have created some Audio Ports (Inputs - with no assignment to any hardware), enabling Loopback, in order to pass audio from song level (via racks) to the Background Rack which I use as a MasterRack (for static live use e.g. just protection i.e. Multiband compression and limiter) which maintain some global controls e.g. all media players route through either Bus1 (Drums), or Bus2 (remaining backing tracks) and Bu3 (for all vst synths) with each Bus on separate hardware faders which persist through songs and route to my hardware ports (e.g. all my buses are balanced across songs but perhaps for venue A I need to drop this level throughout the set (not per song)). I’ll elaborate further below but the reason being is its the only way I’ve found to get “true” gapless transitions to keep tails from Instruments without the audio dropout AND retaining control via hardware faders (previously I have had to create a self-contained rack for vst instrument tails to fall-off naturally, routed directly to my hardware outputs to avoid the audio dropouts however this obviously means I lose the fader control as it bypasses my buses).
So my routing goes something like this (NOTE: My Background Rack Loopback ports are “ToBGRack1/2/3/4” with 4 being the click track to avoid desyncing from the rest due to the loopback latency/audio cycle, NOTE(2) The Utility rack actually has 2 audio ports IN/OUT to split the Drums(Bus1)/Backing(Bus2) so there are two instances of Pro-Q and Pro-C used when needed but routing always there);
Media Player1 -> Utility Rack [Pro-Q->Pro-C] -> Loopback - ToBGRack1 -> [Pro-MB1->Pro-L2-1->HOFA 4U Fader(assigned to MIDI Hardware fader1)] -> Bus1 HW Output
Media Player2 -> Utility Rack [Pro-Q->Pro-C] -> Loopback - ToBGRack2 -> [Pro-MB2->Pro-L2-2->HOFA 4U Fader(assigned to MIDI Hardware fader2)] -> Bus2 HW Output
*Synth1 Rack [e.g. Diva [3 instances with a Input state switch MIDI Channel per song] -> Embedded Rack [Pro-Q->Pro-C to tweak patch eq/compression if needed] -> Rack: Stereo Out -> Loopback - ToBGRack3 -> [Pro-MB3->Pro-L2-3->HOFA 4U Fader(assigned to MIDI Hardware fader3)] -> Bus3 HW Output
Click -> Loopback - ToBGRack4 -> Click HW Output (mono)
*This is all purely so I get no audio dropouts when switching songs (i.e. synth rack tails and fx carry on AND I retain Hardware Fader control on that Bus. This is somewhat simplified to try and explain BUT…
This means once there are Global Pre and Post Racks, the majority of this needs to be in the post rack (as the Global Pre will not have inputs) so if by default the Background Rack become Global Pre I’m not sure how much reconfig I would need to do. While I LOVE the idea of not having the additional audio cycle to improve the latency, I’m hesitant about how I would go about migrating this.
I understand this is likely not an optimal setup but I need to have the Fader control for each Bus AND need the VST synth tails to continue uninterupted and this is what I ended up with which works (albeit with the additional audio cycle/latency which I can cope with… just!)