More flexibility on MIDI ports

Tags: #<Tag:0x00007f9777841230>

HI @Brad,

I have various controllers in more than one location, and more than one set of drum pads (dotted around my “studio”, rehearsal room and “ready to go” for gigs. I like to keep the complexity in Cantabile, so I rarely configure any controller - I just do it in the input port filters.

The problem is that the complexity is becoming difficult to manage e.g. I have a generic “Top Pads” input that does various note, velocity and channel mappings to always get the same behaviour no matter what pad I use, and there are now situations where I can’t do mappings without breaking another one, and the problem is worse when controllers have pads built in.

I guess I could create my own “input” racks, but that would mean changing many songs.

Would it be possible to change the alias behaviour to allow multiple inputs with the same alias? That would solve the problem I guess, but anyone else got any suggestions?


Hi @johncarter,

Thanks for posting this. I’m not sure Aliases is the way to fix this.

Aliases are intended for when you rename a port and don’t want to have to update all the song file references manually. When a port name saved in a song can’t be found the alias names are searched and if a match is found the song file is modified to use the new name. That’s probably not what you want here.

Would either of these ideas help: (no promises, just thinking out loud)

  1. Ability to have different MIDI filters for different MIDI devices enabled for a port.
  2. Ability to create “virtual ports” - ie: a port thats the combination of one or more other ports.


Hi Brad,

I understand where you’re coming from, and I guess I was thinking aloud that from an implementation perspective tweaking aliases might have been easier.

Both of your suggestions make sense, although I suspect the first would make edits quite fiddly beyond the complexity we have now - the “what did I do wrong?” question would have an extra dimension (and I guess it would be harder to develop and maintain).

I do like the second suggestion - it keeps that complexity separate for those that need it, and I guess it would be easier to develop.



Just a suggestion, but it sounds like you could easily do what you want by creating Cantabile configurations for each of your various controller setups (i know that’s how many on this forum use the configurations feature).

– Jimbo

Thanks Jimbo, that’s an interesting idea. Practically I don’t think it would work for me as I’d have to have multiple configs for the same physical location, also keeping those in sync would be a pain.

I know that some of us has input racks that we add to all our songs - would it be possible to have a generic input rack, just like a second background rack? But there might be all kind of complexities, e.g. order of priority for recieving incoming CCs etc, can midi be handled differently than using loopback ports (to avoid having the extra audio cycle for midi that happens for loopback).

The idea would be to have a layer of input ports for each device, thus making it possible to add filters and mappings for that particular device, and then “mix” the input in the input rack and map everything to generic ports.

Here’s another thought - how about scripting support, Lua or somesuch. Then we can do anything we want (in principle). I’m sure this is very fiddly.

Yeah I’ve often thought of replacing the Background Rack with a Global Input Rack and a Global Output Rack. The idea would be that any ports configured on those racks would be available in your songs as environment level ports. I’ve logged it (possibly again) for now because I think it’s beyond this batch of updates.

I’ve thought of this too, but usually you can use other scriptable plugins to achieve the same (eg: reajs).


1 Like

A global output rack in particular would be great! A good place for us to put those VU meter plugins, compressors/enhancers or other special output treatment stuff. I currently have the same “Output rack” at the bottom of every song setup, but it would be much nicer to just use a global one.

Yessssss! Does that mean we wouldn’t need to use loopback ports to route stuff from the Input Rack to our songs? And no additional latency?

That would be the idea, yes.

No promises, but if this is something that would be useful I can put it on the list to look into (but probably not for this next batch of changes).

oh yes, pleeeease!


+1 :slightly_smiling_face:

1 Like

I would love output racks, for standard FX in particular.


Me too I have a use for an output rack. BUT … I would need access to midi inputs in that output rack.

I currently have a linked rack that I include as “output rack” in every song. But I not only need to manually add it; I also need to add a path from midi inputs (actually from a background rack but heck) in the song to that output rack.

Hi John
Just an idea you can use as a temporary workaround…
If Brad’s second suggestion makes sense for you, maybe you could use LoopMidi and create the virtual ports you need, and then do all the routing and mapping in the the background rack. That way you can always use the same virtual input port on your songs.


Hi Tommy, just had a bit of a think on this one. In terms of complexity I’d guess this is slightly more complex than just having “input” racks - in particular as I would be relying on the behaviour of a third-party tool (although never had problems with rtpMIDI).

I am going to look at input racks again to see if it’s as painful as a I thought :slight_smile:

1 Like