Sub-group for plugins or racks

I’ve just created by “control” racks:

_MainVolume is for the plugins assigned to the main master keyboard:

_MainVolume

_SubVolume is for the plugins assigned to the second master keyboard:

_SubVolume

_MasterRack is for the full control of the session and contains a master Eq and master Multiband Compresso for overall control:

_MasterRack

@Torsten any other suggestions? :slight_smile:

Thank you!

2 Likes

Sure:

  • I have some faders on my master controllers assigned to string volume and string EQ (essentially a mix of tilt EQ and lowpass, allowing me to fade the string layer between a warm pad and a very bright and silky string sound). These faders are mapped by my background rack to “standard controllers” and consumed directly by my string layer rack. So I just pop my string layer rack into any song, and these faders are functioning without any further work

  • modwheel is typically mapped to volume of the Hammond organ layer in my songs, since the actual modwheel function doesn’t to much for piano sounds. So I can fade in a nice Hammond layer on top of my piano using the MW. When I use Rhodes or Wurly sounds on my lower KB, the tremolo intensity is controlled by another “standard controller” fader, not the modwheel

  • pitchbend is often routed to a rack that converts pitch bend to CC1 messages and sends them to a Hammond rack. This way, I use my pitch wheel (which again isn’t really useful for piano sounds) as a half-moon switch - push the pitch wheel to switch Leslie to fast; pull it to switch to slow.

In case it’s useful to you, here’s my “standard controls” overview. My background rack converts fader and button input from my MIDI controllers (which have very varied controls and CC assignments) to these normalized controllers and messages. Then the Background Rack sends these to the “virtual port” called BGRack via loopback.

Now all the racks and songs I build can access these standard controls and buttons (if they are useful to them) without me having to explicitly create routes to these racks. So my “String Layer” rack simply has a binding from the BGRack port CC6 for output volume and CC7 for the variable EQ inside the rack. Same with my reverb racks: they listen for CC 8 or CC 10 and adjust either the rack volume (for send-type reverbs) or the reverb mix (for insert-type reverb racks) according to the CC value. Just insert the right reverb in my song and the fader control is taken care of…

Cheers,

Torsten

2 Likes

Another suggestion: to make your song files easier to manage, move the “volume” racks directly underneath the instrument racks you feed into them. So if e.g. your Hammond is assigned to your first keyboard and the other instruments are driven by the second one, I’d sort the racks like this:

  • Hammond
  • _Main Volume
  • Choir
  • Polysynth
  • PAD
  • _SubVolume
  • _MasterRack

Then add a bit of useful coloring, and your songs are far easier to manage and debug if something doesn’t quite work as it should.

Cheers,

Torsten

2 Likes

Thanks again so much @Torsten for such useful and lovely suggestions, and for sharing your “standard controls” overview, so precious!

Cheers,
M

1 Like

Sorry @Torsten I didn’t understand this part of your setup…

yes, that one is a bit complex…

The general idea is to de-couple my song setups from the actual configuration of my hardware controllers. When I buy a new masterkeyboard, I don’t want to have to re-design all my songs and racks, just because that one has different faders and buttons assigned to different MIDI CCs.

So I created a couple of abstraction layers that “translate” between the actual hardware and the way I use it in my songs.

There are a number of very informative discussion threads on this - too much to repeat here, but useful links are:

This here is the high-level logic:

within my background rack, there are “conversion racks” that use the input from my hardware controllers and convert it to “standardized” controllers that I then can use in my songs. The output of these conversion racks is then sent via the loopback function to some Cantabile MIDI ports. I call these “abstract MIDI ports”, because they aren’t connected to any hardware input, but act as an abstract MIDI device like “Pedals”, “Drumpads” or “Drawbars”. Another one is the abstract device “BG Rack”, which collects all my standard controllers that aren’t pedals, drumpads or drawbars. Stuff like “main volume”, “solo volume”, “reverb level” etc, but also “commands” like “start scrolling LivePrompter”.

These abstract MIDI ports are then used by my racks in my songs.

This way, whenever I add or change a hardware controller, I simply build a new conversion rack in my background rack (or modify an existing one) to direct its signals to my abstract MIDI ports in a useful way. All my racks and songs stay unchanged.

I used to have abstract MIDI ports for my keyboards as well, but due to the fact that using loopback incurs additional latency, I created a shortcut for the time-critical events (notes, pitch-bend, aftertouch, modwheel). See the upper part of the graph (Main Keyboard and Second Keyboard). These specific events are used directly from the hardware MIDI port and just encapsulated in a standard input rack that I use within my songs. The input rack uses MIDI filters so it only gets the time critical events and supplies them to the song.

You can see my input racks in my screenshots in the first posts: they are at the top: “_MainKeyboard” and “_SecondKeyboard”.

I admit, this is super-complex - but it has helped me a lot in keeping my setup consistent, and it has helped me add new stuff to the setup easily without messing up everything else…

Cheers,

Torsten

1 Like

@Torsten thanks a lot for sharing such matrix madness :slight_smile:

Yes, pretty complex indeed. I try to use as less as hardware devices I can (basically, two master keyboards, keytar, and a couple of USB pedalboards, including a CME wireless MIDI system).

I prefer to don’t use too much stuff on stage, so I like to keep Cantabile sessions easy as well. However, your approach is great and I’ll dive into it bit more, trying to understand how you manage and organize your full setup. Some part of your setup is for sure useful to “copy/paste” into mine :wink:

Thanks again, much appreciated!

TBH, that’s more than my typical setup: I run two masterkeyboards (piano-type and synth-type) plus a Korg nanoPad for drum pads - that’s it. But the configuration of the on-board faders, buttons, pads and pedals has become so much easier with my abstraction system.

If, for example, I replaced my current upper keyboard with one that has drum pads (currently using the nanoPad for that, since my existing upper keyboard has none), I’d simply build the conversion rack for that new upper keyboard so that it routes the input from these drum pads to the abstracted “Drumpads” port with the correct MIDI notes. All my songs and racks would now work as before using the drumpads on the new keyboard.

Such is the power of abstraction :nerd_face:

Got it now :slight_smile: Excellent indeed, I’ll try to study your conversion rack concept, and check how it could be useful in my case as well… I’ll try to catch “the power of abstraction” :sunglasses:

Thanks again!

1 Like

Update: I needed to “link” two or more racks to be controlled by a single volume, but it looks it’s not possible to embedd racks into a rack. I know I can use same controller for multiple racks, etc. But, is there a way to collect more racks into a single “master rack”? This will also allow a cleaner interface and management of sound groups. Any workaround? Thank you.

Hi Mistheria,

You can only have embedded racks inside of linked racks. If you just wanted to group some new bindings to link the volumes of other linked racks you are referencing you could add that feature to your master rack. I think that those are the things you could do. If your linked racks are fairly settled you could try loading them as embedded files but you would need to check all your routes since you would have changed the rack’s location in the scheme of things. Also this puts all the eggs in the one basket so if the master rack went down the other embedded racks would be captive so I wouldn’t recommend it. If you need an example of the bindings I spoke of let me know.

Dave

1 Like

@dave_dore thanks a lot! Sure, please if you can give me an example of the bindings :slight_smile:

What version are you running please? Also, the bindings would be linked but not in a ratio so when you turn master rack slider to 2 db for example all the linked rack sliders would go to 2 db. This might not be what you meant or wanted so if you could clarify it would help.

I run the latest version 4. No, indeed, I need to keep ratio between racks.

As I see, the easiest and quickest way to achieve this is to just assign a controller (song’s binding) to the racks’ gain, and I can set min/max value in the binding for each rack, as I do now… Thanks anyway.

Well, if you are setting ranges on your sub racks then I assume the ranges change from song to song so yes your current method is the way to go. If the volume ranges of the sub racks were global throughout your set list then you could set the bindings I spoke of up to do what you describe I think. In this example the binding from the CC11 expression pedal is mapped to a linked instrument rack’s outer gain slider and the range is set in the binding so all songs with that rack would react to the CC11 pedal the same way song to song.

If your ranges are the same through the set list for your various racks you would only need to place these type of bindings in the Master linked rack and save doing it for each song.

1 Like

Yes @dave_dore that’s clear. According to the way I use racks, the method to assign same pedal to several racks and adjust the min/max range is fine.

My only issue, now, is that when I change song in the setlist, the expression pedal and racks’ sliders are not linked immediately therefore, before to start the song, I need to move the pedal full down (0) and back to max so that the sliders react to the pedal. Is there a way that on loading the song this process is done automatically so when I move the pedal the sliders react immediately?

Thank you.

That sounds like the pedal binding setting “Prevent Jumps” is set to Yes so the binding won’t grab until the pedal passes the point that the slider was at before you applied the pedal. When set to ‘No’ as soon as the pedal is moved , no matter where it was all the bindings would jump to that current value.

How are those CC11 bindings you have configured with regards to that Prevent jumps setting?

If you wanted to initialize all your rack slider volumes on song load to the lowest level they would have and then have the pedal grab when you took it to zero it would be a different set of settings and require a few bindings tricks. Let me know which approach is best for you.
:slight_smile:

1 Like

Indeed, “Prevent Jumps” is set to “Yes”. I’ll change it to No so I’ll easily solve it :slight_smile:

Thank you!

1 Like

That is an outstanding discussion. Thanks guys!

1 Like