Organise routes and bindings for pedals, switches, control surfaces?

None noticeable here. It is pretty instantaneous the translation in Cantabile.

Terry

1 Like

Thanks, Terry.

My next batch of Cantabile programming will probably virtualise things a bit more as explained in this interesting thread.

Cheers
Derek

1 Like

So…

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.

Any additional info would be appreciated!

Thanks

RR

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?

Bump - Anyone doing MIDI feedback between a rack of faders/buttons and an instrument rack?

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.

Terry

2 Likes

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?

Thanks.

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.

Terry

1 Like

Yes I have that enabled, and yes I created a loop on purpose to see what would happen! :slight_smile:

1 Like

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?

Thank you - David

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.

Cheers,

Torsten

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 :wink: - 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”.

Cheers,

Torsten

Hi Torsten,
Again you’ve shown me something new! I didn’t know about showing the hardware MIDI ports in the racks! Now I’m re-working my racks again. However, I discovered that I do like being able to created different, named input ports to the racks, rather than just having a “Rack: MIDI In”. I think I will continue to use this in some places. But, thanks to your suggestion, I’ve eliminated my inputs and use the hardware MIDI ports directly in the ‘abstracted’ racks.

Related question: Is the background rack useful with ‘abstracted’ racks? If so, how do you use the background rack?

Cheers - David

The background rack is a bit unique, since racks in songs can’t use background rack ports, so routing is a bit fiddly - but it can be done. The trick is to use the “loopback” feature of Cantabile, which allows you to allow MIDI input ports as output ports to allow Cantabile to feed MIDI data back into its input ports.

So I use the background rack to filter and translate data from my physical devices (e.g. Kurzweil PC3K, AKAI MPK249, my custom “Magic Keys”) to standardized abstract “upper keys”, “lower keys”, “pedals”, “drum pads” and some internal magic ports to feed my songs. These abstract MIDI input ports aren’t connected to any physical MIDI interface - they only get fed by the background rack.

So the background rack translates the input from my device input ports and feeds it into the “Loopback - Main Keys”, “Loopback - Second Keys”, “Loopback - Drumpads” etc. My input racks then receive data from these ports (“Main Keys”, “Second Keys” etc.). I could also use these abstract input ports directly in my songs, but I’ve gotten used to using my abstract input racks, so I’ll continue to use them for better visibility, even though most of the translation work is done by the background rack these days.

If you want to dive deep into this rabbit hole, here is a post that gives more detail:

Cheers,

Torsten

I know this is an old thread, but I’m hoping someone will still be watching this. I’ve completed the hardware abstraction set-up and it works like a charm as long as I use only VST plug-ins. However, when attempting to use a combination of VSTs and internal sounds from one of the boards I can’t seem to get the internal sounds.

Bottom board is a Studiologic SL88 Studio and top board is an MODX7. I have a rack created for each.
Top board performance a six part performance. Channels 1, 2 are sent out to a VST when actually playing on the top board and work fine. The remaining 4 parts I want to control from the bottom keyboard. I’ve routed the Notes output port of the bottom keyboard rack to the Input port of the top board, making sure the channel mapping from the bottom board (Channel 1) is filtered to Channels 3, 4, 5 and 6 of the top board. MIDI monitor shows the note on/off messages are being received by the Top Keyboard rack, but no sound is produced. In attempting to troubleshoot this issue, I created a new song using the regular method of Input/Output routing without utilizing the rack port abstraction and it works fine, which would lead me to believe the issue isn’t a hardware configuration issue with the top board.

Anybody have any ideas/suggestions of what I might be missing in the rack set-up?

Cheers!

Can you put a MIDI monitor on the actual output to the top keyboard to see if the notes are actually being sent out by the rack? Looks like there’s an issue with output routing to the top keyboard

Maybe you can share the song and rack files - happy to take a look at them…

Cheers,

Torsten

Here are the rack files and the song file. I think the main problem is I’m not quite certain of how to direct the Notes output of the TopKB since the sounds are internal to the keyboard itself.

Thanks for the assistance!!!

DontDreamItsOverSL.cantabileSong (42.9 KB) BottomKB.cantabileRack (12.9 KB) TopKB.cantabileRack (15.9 KB)

Essentially, your TopKB rack is missing a route from its MIDI input to the physical output connected to the MODX7.

I would actually suggest a separate rack for that job - have one input abstraction rack (your current “TopKB” rack) and another separate one - maybe call it “MODX7 Output” that, instead of routing MIDI input from your keyboard to Cantabile, routes MIDI from the rack MIDI input to the correct MIDI output port.

You can then also use rack states on this output rack to send different program changes to your MODX7 to configure it for different sounds.

That way, you have a clean workflow from input racks via (configurable) routes to output racks. Just because your MODX acts as an input device doesn’t mean you need to put all its functionalities into one rack - separate it into its two personas as input device and as a tone generator…

Hope this helps!

Cheers,

Torsten

3 Likes

Worked like a charm!!! Thanks again for your assistance!!