Designing New Virtual Rack- best way?

[sgarman]

@torsten suggested a few months ago that using a “virtualized” rack was a good way to work with racks. I play in a church band and my current method has been to create different racks (Piano, El Piano, etc), and place them all in one song, then use an Arturia Beatstep to enable plugs and control volume. Although this does work I want to now create more songs with fewer plugs/song to try to get CPU usage down. So if I create more smaller racks is there a way to standardize the design so that once a rack is created it is easy to add to a new song.

So my question to you is:
How do you accomplish this?
What MIDI input channels do you create for exclusive tasks (like enabling a plug) and what data do you combine?

I know there are many ways of setting this up and I am trying to find a way to create a template rack that can be used as the starting point for each new rack.
I have searched the forum and not really found a comprehensive answer to this question.

So give it your best shot!!

[Corky]

@sgarman

I want to now create more songs with fewer plugs/song to try to get CPU usage down.

This is why I don’t put all my eggs in one basket. Many people try to recreate a workstation or rompler in racks. The problem is dealing with CPU load. My racks are mostly simple…A Simple Example: I use the Hammond B3-X plug in a rack, and create states within the rack which changes presets. When I have a song I think needs the B3-X, I simply drop the rack into song, attach to routing, select preset state. My approach is to select any of my pre-made racks into a new song. If it doesn’t quite fit, I change racks.

Sometimes, I will need to create a new rack for something I haven’t previously used. It then becomes available for any future song where it might fit. I don’t really use a template, because songs are mostly different, and I may want to change routing, or use different bindings. There are many examples in this forum, so you will need to do a search for setups, and prepare to be amazed at some exorbitant uses.

Terry Britton’s Webinars on YouTube are extremely resourceful and educational on what can be done with Cantabile. I participated in a few and watched them all several times just to get a different viewpoint.

@sgarman

What MIDI input channels do you create for exclusive tasks (like enabling a plug) and what data do you combine?

I use omni. That way I don’t have to assign midi channels within the plug. I normally use 2 key controllers…the upper for Organ, Synths, and special things, and my lower for Piano, Strings and such. My controller buttons serve to disable plugin routing, as enable/disable plug could spike your CPU. My controller is on midi channel 1, so most any buttons,knobs will be looking at midi 1.

Don’t know if this helps you, but everyone here does it differently…some have massive bindings and racks, others keep it simple, like me.

It really boils down to what works best for you. There is really no right or wrong…C3 is THAT flexible.

Cheers

Corky

[Torsten]

@sgarman

using a “virtualized” rack was a good way to work with racks.

Hey Steve,

just to clarify: my “virtualization” approach is more about abstracting input devices from their physical ports and properties, not about using instruments. I’ll come to that later.

Now about using racks in songs: my approach, developed over a couple of years now, is to wrap individual instruments in racks and then combine them in songs as needed. This way, only the actual devices I really need in a song consume CPU cycles.

A typical instrument rack contains just the VST instrument plus an EQ (I use EQs in most of my racks as a way to shape presets), plus bindings to initialize the instrument for any song opened. Here is a typical instrument rack:

I usually just send the notes to the instrument and assign the controllers explicitly in bindings - avoids nasty side effects when unwanted controllers are sent to the instrument. Here is the bindings page with the “control” section open:

You’ll see that some controllers are just routed through, others are converted through the bindings.

Also, there is usually an “Init” bindings section to make sure the rack is a defined state when a new song is loaded, so whatever on-the-fly control changes you made in a previous song, you always get what you expect:

My racks then have a number of rack states, kind of like patches for a physical synth. Then I bring them into a song, select the rack “preset” I want for the song (or create a new one if I need one) and build my song out of these individual “lego bricks”

Now a typical song for me looks like this - actually, this is one I use as a template when setting up a new song, since a lot of elements are in place:

This is one of my typical “rehearsal” songs (when we spontaneously try a new song that I haven’t prepared a dedicated setup for): it contains a piano with additional organ and string layers that can be faded in (via controllers) when I need them, plus three solo instruments (Hammond B3-X, a SWAM sax, plus Surge for a synth sound). I play the piano and its layers on my lower 88 key keyboard and the solo instruments on the 61 key upper board. I switch between the solo instruments via drum pads on my upper keyboard that select one of the four song states. This switching is done by activating / de-activating pre-configured routes from the upper keyboard to the instruments.

The “Main Piano Rack”, “StringLayerRack” and “HammondRack” are all routed to the “_MainVolume” rack (with some parallel routes to the “MainReverb” rack which in turn routes to _MainVolume as well). This way, I can control the overall volume of the main layered sound with a fader on my controller.

The “Organ Solo IK”, “Alto Sax” and “Surge Solo” racks all route to _SoloVolume, same as for the main layer.

Both volume control racks then feed into the “master rack”, which contains a master limiter, plus gives an additional master volume control, which is also not song-controlled, so I can adjust my master level statically on-stage.

Now to the input side of things: I don’t use the input ports directly - I have my “abstracted” input racks at the top for that. In these racks, I convert and split the input from Cantabile’s input ports to separate outputs, so it can be routed easily. Here’s the routing from the main keyboard:

You see that I have separate outputs for notes only, plus for pitch bend, modulation and aftertouch, so I can control exactly which instrument receives only notes, which one gets pitch or mod commands, etc.

Here’s the upper keyboard assignment:

You see the active routes to the organ, plus the de-activated ones to the sax and the synth. Plus, you see that the organ doesn’t get aftertouch (doesn’t need it) but the other two instruments get it.

Then I have a separate rack just for the pedals:

Even though my pedals are physically hooked up to the lower keyboard, I assign them freely to where they make most sense: e.g. the expression pedal controls the organ that I play on my upper keyboard, the sustenuto pedal switches the leslie speed.

All very transparent and easy to “wire” - and easy to debug if something doesn’t quite like as I intended it to.

Last, I have a “drumpads” rack. Even though the drumpads are a physical part of the upper keyboard, I separate them out to their own rack to make things more structured. In this song, the drumpads rack isn’t connected to an instrument, only to some bindings that I use for state switching:

That’s it!

When building a new setup, I usually load one of my template songs like the one above and start removing or switching out instruments (“Use different rack…”) where I need to for the specific song. E.g. I’ll replace the Alto Sax rack with an Xpand rack for some “rompler” sounds or bring in Hive for some alternative synth flavors.

Once I have all the instruments in place that I’ll need for the song, I build my song states - mostly that is changing the routing to play different instruments, and setting different levels for the racks to customize the mix of the instruments.

Hope this helps!

Cheers,

Torsten

BTW: there is even one more layer of abstraction / virtualization in my setup between Cantabile’s input ports and my “virtualization racks”, but I’ve outlined that in a different thread - and it’s really not necessary to get into that to understand the fundamentals of my song setup, so we’ll ignore it for today…

[Corky]

@Corky

some have massive bindings and racks

@Torsten

I actually figured this would trigger you to respond with your examples!

[Torsten]

@Corky

I actually figured this would trigger you to respond with your examples!

Actually, my racks aren’t so massive; they’re mostly pretty lean (some exceptions like my IK organ solo rack…) - it’s the songs that are pretty multi-layered, plus my obsession with abstracting input devices that makes my setup a bit complex

[Corky]

@Torsten

plus my obsession with abstracting input devices that makes my setup a bit complex

I’ve also “started” abstracting input devices recently, but you are light years ahead of me.

[sgarman]

See this is exactly why this board is so very valuable. @Torsten and @Corky thank you for your responses. Corky I had forgotten about @terrybritton’s webinars so spent about 5 hours listening to them which lead to @dave_dore and his utility racks. And Torsten’s example above just kind of brings all that together. I was trying to go the fewer racks/ more in a rack route and I see that it would be more flexible to go the more racks/fewer plugs in rack route. And then put those leaner racks in songs; makes perfect sense!

Again, thanks to you all for your input.

[sgarman]

@torsten, I have been setting things up as you described. so far so good for the most part.
But when it comes to MIDI filtering you can filter on the input ports or the routes. Which is best or what are the tradeoffs? If I filter at the input port that would affect all routes correct? And if I filter a route then only that route is affected?
when a MIDI seq hits a port on a rack, what is the sequence of events that follow?

[dbrendon]

I’ve followed many of @Torsten ideas regarding abstracting my keyboards and pedals in separate racks. I’m about to embark on a trial of switching my ‘UPPER’ keyboard from a Mojo 61 to an Axiom 61. I’m having trouble designing the best way to map the controllers from the Axiom so they mimic the Mojo61. I would like to handle all the mapping in C3, and leave the Axiom61 at factory defaults, if possible. For example, I need to have the Axiom sliders send the same CC messages as the Mojo61 drawbars, to my B3 rack. In the C3 Options, I have configured ‘Upper IN’ with the keyboard USB midi input. I have a rack, called _Upper, that abstracts the Notes, Expression, Sustain, and Leslie Speed from that Midi In (previously Mojo61). My B3 rack has been configured with Midi In ports for Mojo61Controls, Notes, Expression, Leslie Speed.
Can someone suggest the simplest way to accomplish this? Is there a way that my _Upper rack can automatically recognize whether the keyboard is Axiom or Mojo and perform the appropriate mapping?
My goal is to not have to edit all my existing songs. Ideally, I would also like to be able to use either the Axiom or Mojo keyboard and still have my songs work properly. I appreciate any thoughts on this.
Thank you - David

[Corky]

@dbrendon

rack can automatically recognize whether the keyboard is Axiom or Mojo

Your drivers should determine which is which, and make sure you label them as such.

As far as abstractions, you will have to do each separately. Terry Britton showed just how to do abstractions in his webinar series:

Cantabile Webinar 4 - Abstracting Controllers

I could show you how to achieve what you want to do, but it would take FOREVER to type everything here. I would also have to be familiar with the Mojo and Axiom, and I don’t own either. Terry’s video will really explain what you are needing. I suggest you abstract your controllers into 2 separate racks…A Mojo, and an Axiom. Then send signal from either one to your B3 rack. Once you setup your 2 keyboards, they can readily be able to use the same controls, then just send signal to B3 rack. Anyway, that’s how I do it. I am sure there are other ways, just haven’t explored them.

Regards

Corky

[dbrendon]

Thanks for the ideas Corky!
Yes, I was starting to set up two different racks, one for each keyboard, but then I realized I would need to edit each of my songs so that the output from those racks went to each VST rack. I’m wondering if I can modify my _Upper rack and embed an Axiom and Mojo rack inside of it, with each of them sending the same Midi Outs as the previous _Upper rack. That way all my existing ‘Songs’ should still work since they would be using the existing outputs of the _Upper rack. Thoughts?

[Corky]

Hey David

You would be best to keep two separate racks for the keyboards. Here is how I handle it, as convoluted as it is:
I have a 49 Key upper, and a 61 Key lower…normally. But, sometimes I use an 88 Key lower. This is how I use the switching:
In my “background” rack, I have states setup for each keyboard. When I go to a gig, I set the states in the BG rack to the controllers I am using. That way, I can make sure that bindings are set for whatever controller is being used. They are set for the rest of the gig. Understand, I did this long before abstracting controllers, and purchasing controllers with more controls, so I have some work to do to get the new ones in, if possible with BG Rack limitations. Of course the controllers are aliased to Main Key, or Key 1, that way only one input is used.

@dbrendon

I’m wondering if I can modify my _Upper rack and embed an Axiom and Mojo rack inside of it, with each of them sending the same Midi Outs as the previous _Upper rack.

I guess you could put two racks in one rack, and switch with states, but you would have to change it in every song it seems. You could also create an output rack at the end of every vst. I really believe there are many ways to do this, and you should set it up the way it works best for you. As I’ve added vsts and controllers, I have spent many hours to align everything, and after many failures, I usually find one that works. I have roughly 750 songs for 5 bands I was in pre-covid. The songs are still there, but the bands aren’t, so I expect more work in front of me as gigs pile up.

[dbrendon]

Good idea about the background rack - I forgot about it! I could also use that for another issue I recently encountered. In a couple of bands I play left hand bass, but in another there is a bass player. I had configured my _Lower abstract rack with states for Splits and for entire keyboard, but I always need to remember to switch for each song. If I move that to the background rack, then I only need to set it once for the entire rehearsal/gig.
As you have said, in C3 there are often many ways to configure functionality!
Cheers!

[Torsten]

@dbrendon

I’m having trouble designing the best way to map the controllers from the Axiom so they mimic the Mojo61.

I use separate conversion racks inside my background rack for that. I have an abstract MIDI port called “BG rack” that handles all my sliders, knobs, faders etc. No physical device is connected to this MIDI port directly; it is fed by the conversion racks inside my background rack.

Now the first thing I did was to create “standardized” controllers that feed into my songs from the BG rack, e.g. keys master volume, guitar master volume, main level volume, solo volume, main reverb level, solo reverb level, etc. Same with “standard buttons” like next state, previous state, next song, …

Now I have one rack per physical controller inside my background rack that has the job of converting the input from whatever a controller throws at it to these “standard” controls, so if on one keyboard a button I want to use for “next state” sends a Note command, I need a binding that converts that Note command to CC 1 on channel 1 and sends it to “Loopback - BG Rack”, so that my songs see the right command coming in.

These conversion racks in my background rack then take input from a specific port that my hardware is actually connected to, e.g. “Kurzweil 88” or “Studio Keyboard” and process its data, sending it back to the BG Rack input via Loopback.

Now when I buy a new controller, I just create a new conversion rack to take its input and “standardize” it to my expected commands - now all my songs and my racks can deal with these commands (since they’ve all been programmed to expect these standard commands).

BTW: my conversion racks do even more than just controller conversion - they also handle the routing of notes, pedals, drum pads etc to other “virtual input ports”, but that’s going too far for today…

Since I connect my keyboards via classic MIDI cables, there is no way for Cantabile to know which keyboard is connected, but it takes me just a couple of seconds to open my background rack, activate the correct conversion rack and switch off the others - this way only the correct conversion rack sends commands to the BG Rack port.

All a bit convoluted, but extremely powerful - and once it’s set up, it’s actually very simple to integrate new machinery.

Since you might not want to go all the way with controller standardization, you could try a reduced version of this to simply make your Axiom keyboard imitate your Mojo:

• create a new MIDI port to connect your Axiom to, keep the MIDI port for your Mojo - now you have two separate ports for your upper keyboard: “Axiom” and “Mojo”
• create a conversion rack in your background rack that takes its input from the Axiom midi port, converts the controllers via bindings and sends them out to the “Loopback - Mojo” port
• this will make them appear to your songs as if they had been sent from the Mojo - so no need to change anything in your songs. The songs don’t use the “Axiom” port at all - it is just needed to feed the conversion rack.

In this approach, your Mojo controller setup becomes the de-facto standard; any new hardware will need its controls to be converted via its own conversion rack to your “Mojo standard”…

The Loopback feature is pretty powerful once you figure it out.

Cheers,

Torsten

[Corky]

@Torsten always has the best answers, especially for routings. I had to be short cause I have a gig tonight, and it starts in about 3 minutes. Hope you get going David.

[dbrendon]

Wow Torsten - wonderful - thank youl!!
I have previously followed some of your suggestions and broken out Notes, pedals, pitch bend, etc. in abstract controller racks, but I didn’t create them in the background rack. I do have buttons for ‘First Song’, ‘Next State’, etc. in my background rack though.
I’m a little hesitant to use Loopback - won’t it introduce some latency into the midi chain?
I’m going to try some of these ideas out tomorrow.
Cheers!

[Torsten]

@dbrendon

I’m a little hesitant to use Loopback - won’t it introduce some latency into the midi chain?

Hi David,

I use Loopback extensively - haven’t noticed any additional latency. Maybe @brad can clarify?

Cheers,

Torsten

[Torsten]

@dbrendon

I’m going to try some of these ideas out tomorrow.

So if you really want to dive into that end of the pool, here are some more pointers on how I’ve organized my setup for maximum flexibility and portability. In previous incarnations, I tried to get all my various controller keyboards to behave similarly, i.e. get them to use the same CCs, but that became impractical with some hardware, so I thought I’d weed these dependencies out completely. Here’s an overview of what things look like in my setup:

In my setup, I have two kinds of MIDI ports in Cantabile: “abstract” ones that aren’t connected to any hardware and “hardware-related” ports that get their input from hardware. In between those, there are conversion racks in my background rack that take their input from the hardware and convert and forward it to my abstract ports.

You see that some Windows ports are assigned to more than one Cantabile input port - that’s because I use a 2-port MIDI interface (mio2) to connect my main and upper keyboard, so when I use my “MagicKeys”, these are connected to the second port, alternatively, I can use my Motif XF as an upper keyboard, connected to the same physical MIDI input (but using a different conversion rack in the background rack).

The “abstract” MIDI ports then get used inside my input racks - these essentially take the input and split it up to various outputs so routing gets easier. Some other racks, e.g. volume faders or effect racks use standard controls from the “BG rack” input directly to control levels. Since these racks are dedicated to one single purpose, and I have a special command in BG rack dedicated to that purpose, it’s easier for these racks to listen directly to that port than to have to create routes from the “Faders” rack explicitly, like I used to in previous versions of my setup. Nowadays, I just drop a “Main Volume” rack into my song, and it automatically reacts to the correct fader on my controller.

Some instrument racks, e.g. my String Layer rack or my Solo Organ also use the BG rack (string level, string filter) or the Drawbars port directly, since the assignment is permanent and clear, and no song-specific config is necessary. Again, less routing necessary at song level; just drop in the rack and route notes, controllers, pedals as needed.

Hope this clarifies things and gives you some inspiration for your setup!

Cheers,

Torsten

[Torsten]

And here some insights into the “routing rack” side of things: here a view of my Background Rack:

You see that e.g. the Kurzweil “hardware MIDI port” is routed to the “Routing Kurzweil” rack etc. You can also see that my “Routing Motif” rack is currently turned off, because I have the “Magic Keys” active in my current setup. If I plugged my Motif into that port, I’d simply have to de-activate the Magic Keys routing rack and activate the Motif one - done!

You can also see the “Routing Kurzweil” rack sending its output to three “abstract” MIDI ports via Loopback.

Here’s the inside of the Kurzweil rack: routing-wise pretty simple; it just routes notes and selected CCs through to the respective ports:

The bindings page of the routing rack contains the conversion from the Kurzweil’s slider and button mapping to my standard controls:

Lastly, here is a section of my Background Rack bindings page:

This is where some of the standard commands from the BG rack port get actioned, e.g. to step to the next state or to send commands to LivePrompter to control scrolling, etc.

That’s mostly it!

Cheers,

Torsten

[Corky]

Really nice!! Me likey!

Will take a couple of months to wrap my mind around all this.