Opinions for most wanted improvements...

[pinkcanaru]

Humphrey - the only difference between the current MRT and my proposal is that you would have a method to organize, copy - paste - color - mute etc.

As anything is possible within the MRT you simply need a 'strategy' to approach the issues. Your setup is almost identical to mine: Two keyboards, one of which has 2 pedals and each of which has a footswitch.

The number of midi routings is now unimportant. What IS important is that you can SEE clearly a dedicated folder of routings for a given song without trawling through, potentially, 100's of routings in that list. What is important is that the entire folder could be copied and modified slightly for the next song.
You can set up some general routings that live at the top level of the MRT, not in folder. In this way, you can simply manage the MRT environment - and if you can achieve all your routing desires in the current MRT, you will continue to achieve those exact results when folders are introduced. The only difference? Clarity and speed of operation.

So, once again, even if there are 1000 MRTs in your setup, you can clearly handle the operation by eliminating from view all the unnecessary components. You never have to worry that altering some shared resource will screw up another sub-session.

Does that answer your question?

[humphrey]

O.k. it begins to down on me.

Cantabile is organising the MRT issue bottom up, means you only create those routings you need for a session. This is what I call the more "danamic" structure of cantabile.

Forte f.e. does it the top down way: every possible routing is available and you disable everything you don't need. This is the more "static" structure.

Your way: you realise a scetch of what is possible and is suspicious to be needed somewhere in the future. This setup is created once for a session. The trick is to put all those routings "under the hood" and influence them by "global functions" (so you don't have to parametrise hundreds of routings by hand for a new subsession). I agree: If this is done by intelligent organisation, instructions,... the handling of some hundred MRTs is not a problem any more.

But there is one condition to my mind: the way cantabile handles MRTs must not lead to dramatic CPU use / heavy delays created by a high number of MRTs. The same is necessary for change times from one Subsession to another. Also it has to be clear that probably more than thousand MRTs have to be handled (and this was one the barriers for me: I could not even believe hundreds of MRTs could be possible at the same time).

If so I agree: this would be a way to handle this. But then: where is the need to do limitations to this scenario? Why not implementing any possible routing from the beginning and disabling what is not needed with similar mighty instructions? Even old projects could be interpreted and rebuild this way (in the end every routing is not more than an entry in a giant 2-dimensional matrix).

Thanks for clearification and good luck for your idea, humphrey

[pinkcanaru]

But there is one condition to my mind: the way cantabile handles MRTs must not lead to dramatic CPU use / heavy delays created by a high number of MRTs. The same is necessary for change times from one Subsession to another. Also it has to be clear that probably more than thousand MRTs have to be handled (and this was one the barriers for me: I could not even believe hundreds of MRTs could be possible at the same time).

Humphrey - MIDI Routings are probably the least CPU intensive of Cantabile's functions. Just text instructing MIDI how to route. Your plugins consume WAY more. What's more, you are easily muting out anything you don't require. The folders make it easy to get the 'driftwood' out of the way. I believe you would never even register the hit that 1000 MRTs would have on a modern laptop powerful enough to be running Cantabile.

But then: where is the need to do limitations to this scenario? Why not implementing any possible routing from the beginning and disabling what is not needed with similar mighty instructions? Even old projects could be interpreted and rebuild this way (in the end every routing is not more than an entry in a giant 2-dimensional matrix).

You are correct. I came to realise very quickly that the MRT is THE place to get the most versatile routings. Once setup, a routing can be adapted for any destination - whereas pegging a routing to a specific plugin takes more effort to move. Having said that, there are certainly situations where you need to attack the issue at the plugin or rack. The beauty of Cantabile is that it allows you several places to address these issues. That same versatility can lead to confusion too... So tools which help us organise are vital.

[TiUser]

Whoops...

I think I have suggested something similar having called that "controller virtualization".

I think the are two points.

First is controller assignments are made to destinations. But to not lose overview it needs a source view, in other words a list of destinations operated by a controller...

Second virtual to physical controller definitions would help change to different HW controllers.

Midi processing usually isn't a cpu hog but dynamic change of routings which carry states can be delicate.

[pinkcanaru]

Multi-out VSTi
Just wanted to get it on record that TiUser and I have established that this does not work. The part of the method that is broken is that Cantabile insists on routing the 'Send To' column to the destination rack. This divorces the source plugin from its main output and the end result is that the whole plugin ends up at one destination - not split out as required.

The virtual lines referred to below should be the only thing required to get the outputs from a source plugin's multi outs to the destination rack's virtual inputs.

Even the current concept of having to inject the virtual lines into a plugin at the destination seems to be a step too far. Why inject to a plugin? Why not into the rack itself? If the current audio input button of a rack could have its function extended to include access to virtual line inputs, that would do it.
Even given the current hobbled state of the multi out handling, one has to employ a 'benign' plug in to get the audio into the destination rack.

So - if the basic scheme is to remain as it is - what needs to happen to make it work is:

1. Route the required multi-out to the preferred virtual lines via the tool box.
2. At the destination rack's enhanced input drop-down, set the virtual lines as inputs - with pan position available at some convenient point in the chain to accommodate stereo inputs.
3. The 'Send To' column has nothing at all to do with the routing via virtual lines.

Currently, we can only route additional outputs from a VSTi to a new physical output on hardware - with no provision for processing with other plugins before the signal leaves the software. And it's certainly no use if one only uses a stereo interface.

Maybe I misunderstand but I think that's not quite true.

First you need to configure the "Master Bus". You can activate "virtual" lines here - not related to the audio interface channels.

Second you need to change the outputs of such a workstation plugin (Tools -> Audio Channels) and route its outs to the virtual master bus lines.

Third you need to choose those virtual lines as inputs (Tools -> Audio Channels) for another plugin or rack you want to do processing on those.

Finally you need to route the "virtual" output back to the audio interface related audio lines.

I admit this is an intransparent - i.e. non visual - process and if you are using more than one of such a plugin you can run out of audio lines as these are kind of global.

But finally I agree that such processes should be simplified for set up - also I have no golden idea yet how to master this within the current program mechanics. One thing could be some gui tweaks. I myself always need to lookup the manual to remember the plugin routing and the controls...

[TiUser]

Multi-out VSTi <snip>... that Cantabile insists on routing the 'Send To' column to the destination rack.

Confirmed - this seems to be true.