Yup, you could to that - but you need to ensure that your rack states for the _MainKeyboard rack aren’t changed by the surrounding song. Easy to do:
Open the rack in edit mode
Select File->Rack Options…
Un-tick the box at “Let the parent song control this rack’s selected state and gain”
Now you select a rack state after you load your set list, it should stay there until you close Cantabile or load a different set list. Mind you, this will only work for pre-loaded set lists, so I’d go either with configurations or with some background rack routing tricks…
Next question. On your “Notes only” passthrough route on the _MainKeyboard rack, you’re filtering on the route using the “funnel” icon, not filter dialog popped up by clicking “Omni”. What is the reason for choosing one over the other?
Simple habit - I’ve just always used filters to suppress or allow individual event classes. Wasn’t even consciously aware of the “Notes Only” checkbox
Thanx for pointing that out - may come in useful at some point. For now, it doesn’t make much of a difference, since I don’t need state awareness of the NotesOnly filter…
An Update. I’ve abstracted my keyboards into racks and have Notes coming out from that rack into the VSTs.
Next, I want to look at faders, buttons, footswitches and pedals.
I think Torsten has his set up with abstraction based around physical hardware. eg. one or more intermediate racks and then the VSTs are connected or bound to that intermediate rack. The lines represent bindings and/or routes. Like this
I wonder whether there is any benefit in abstracting based around Functions as an alternative. For example building intermediate racks for a Piano, Organ, Audio Routing, Lighting Desk etc.
All of these racks would then be added to the song.
So the “Virtual Piano 1” rack would bring Notes from physical keyboard 1, Pedals from “physical keyboard 1”, String Resonance or dynamics slider from “Nano Key fader” The combined output of this rack would then go to the instrument rack containing the Piano VSTs.
The problems I am thinking about are easy ways to answer:-
What have I mapped to this hardware button/fader?
What have I mapped to this software function eg. “Next Song State”?
How can I quickly repurpose this “NanoKey” which currently has faders mapped to functions across lots of different VSTs and C3 itself?
For the 3rd question, I might temporarily want to assign all the faders to be lighting controllers, It would be nice to just disable a rack with the existing config, and drop in a new “Lighting desk rack”.
I suspect this is all over complication, but it is going to take some effort to redo my songs and I’d rather get all the thinking out of the way before I do!
I’ll be reading more on this interesting topic as I get my new rig setup. I am curious to know with all of these abstractions and racks if it leads to any noticeable latency? I would hope not on a modern PC, but thought I would ask the question!
This abstraction thing looks interesting… and confusing at the same time. Are you doing all of the routings withing a single embedded rack, or creating purpose specific racks. I am guessing you are using this rack or racks within every song.
Hey folk, how do you deal with a fader that would normally come in on a “faders” rack, but will always control a specific parameter in another rack. AND needs feedback.
For example, I have 1 physical endless encoder that comes into a faders rack as CC3 on channel 11. It has an LED ring so I need to get feedback to it.
I need to get it to an instrument plugin in another rack to directly control a parameter that needs a value between 0 and 1. I also want feedback from that parameter to go back to the LED ring.
As another example I have a “mute” button "button on my midi controller that needs to enable and disable a route in the “Global Out” rack that is added to every song. It also has an LED within the button so needs feedback to it.
Without abstraction, I’d simply add a binding in the instrument rack directly from the physical encoder to the plugin parameter. I’d add a 2nd binding from that VST parameter back to the LED ring for the feedback.
Similaly for the route enable/disable I’d add a binding in each direction within the Global Out rack.
With abstraction and all the faders coming into one rack, It does not seem to be possible to add 2 way routing between 2 racks. The Return route will not give the source rack as an option in the dropdown, presumably to stop loops?
How is everyone doing this in a scalable way for 16 faders, 16 buttons, and some pedal switches?
I am - with a Behringer BCF2000 motorized slider box. I have eight faders working, though, not sixteen, but I could do banks.
Here is the post where I described my bindings:
As you can see in that post, I’ve relegated these duties to the “Background Rack” as I used them for every song, so in that sense they are abstracted I suppose. I know you’ve see that post already, but perhaps that contains some germs of info we can use for this application of yours.
Thanks Terry, yes I re-read your post last week to see if I could make it work for me.
In my case, I am not just controlling gain, and I don’t want to rely on position of the the racks within a song.
Hi @brad What is the reason that I can’t create 2 way routes between 2 racks within a song? Is it to prevent us from inadvertently creating loops? Does it complicate the binding execution order? Could it possibly be an enabled option?
I’m just jumping in a sec as something entered my mind - had you turned on the loopback capabilities in the Options/Miscellaneous section? I turned mine off as I managed to produce a SERIOUS MIDI feedback loop the one time I tried it and chickened out! But it may hold the key to making this work.
Hi Torsten,
[ I’m referring to an old post about abstracting the Pedals ]:
I like your idea of abstracting the keyboards, pedals and faders! I’m attempting to implement a similar solution, but I have question about the sustain pedals. I have a sustain pedal for each of my upper and lower keyboards. I created a rack (_Pedals) that has both of the pedals defined. However, both keyboards are transmitting on channel 1 and both use CC 64. Therefore when I connect the Sustain (Upper) to a plugin, the plugin will also sustain for the Lower pedal.
I know I could handle this by either mapping to a different channel number or the CC number, or creating separate pedal racks for Upper and Lower, but I’m hoping there is an alternate, more elegant solution. Any ideas?
My suggestion is to have separate output ports for your _Pedals rack: Sustain1 and Sustain2. Create the routing inside the pedals rack so that CC64 received from the lower keyboard gets routed to Sustain1 and CC64 received from the upper keyboard to Sustain2.
Now you can create dedicated routes from these two output ports, e.g. send Sustain1 to your piano plugin and use Sustain2 for a Rhodes on the upper keyboard. Or you can use Sustain2 for a state switching binding when you need your hands free.
You could also map the upper sustain pedal to a different controller (cc 65) and use filtering and mapping on the routes, but I find the approach with separate MIDI outputs from the rack far mor convenient and easy to understand when building my songs.
Thank you!
I again have learned something new. I didn’t realize that I could create Midi Input Ports for the racks. All my racks just had the default “Rack: MIDI In”. This should provide a much more elegant solution. Thank you!
Actually, I was talking about OUTPUT ports - but you can definitely create BOTH…
My encapsulation racks don’t have any input ports - they use the (virtual) hardware ports directly. Inside the rack, there are routes from the hardware ports to the rack output ports. That way it is easy to create my songs - simply put in the input racks I need and create routes from them.
But to be able to route hardware inputs from inside racks, you’ll have to enable “Show Environment Audio and MIDI Ports in Racks”.
- but you can definitely create BOTH…