suppress reload of a vsti

[humphrey]

Hi,

maybe I have overseen something, but I have a serious need for a special scenario and don't know if this is possible in cantabile:

I use Omnisphere as plugin (3 or 4 instances). Omni is a sample player with a very voluminous library. This means: long load times when changing the sounds. Principally this can be handled by preloading (up to eight) sounds and call them by using different MIDI-channels or even Program Changes (Live Mode). In this case it is only necessary to load sounds once and suppress a new load when changing sessions.

I think sub sessions do the trick. But here I have the problem, that I'm not able to storte MIDI-routings, keyshifts and the like to a sub-session which makes them useless for me.

I also have brainspawn forte. Here the situation is more comfortable as I have the possibility to chose between "only load once" and "always load new settings". This means: I load all instances I need for a show into the rack and preload all sounds. The result are not noticable change times (as short as in workstations). I know the concepts of both hosts are slightly different and I think this could be the reason for this missing feature in cantabile (?).

So my question: is there a possibility to realise what I'm looking for ?

Thanks and regards, humphrey

[TiUser]

I think this is an unsolved scenario in Cantabile...

I've suggested a time ago to add another method of patch selection via bank/program and a corresponding basic patch names list. But that does currently not exist in Cantabile. The workaround would be using triggers to send bank/program numbers which is very cumbersome imho.

A far as I remember midi routings - i.e. midi filters - in sub session context is an open pending experimental feature and I am not sure if there is anything in the current version.

Subsession based transpose and zones / splits should work. Just use the rack options below "split/transpose" and activate in "subsession behavior" of this rack "keyboard split/range".

There is a similar feature for the input midi channel of each rack.

I haven't proved both this instant but it should work - otherwise it's a bug.

[humphrey]

Hi TiUser,

as usual: very useful information from your side - thanks for supporting here (specially during brad is absent)!

I really wasn't aware of the fact that sub-sessions have these possibilities available. Many of the items I'd address are available. Unfortunately there are some issues left as far as I see:

1) I don't see a possibility to store a mapping of the midi channel (which would be most comfortable in my case). Here I could probably send triggers as you described (which is not really comfortable).

2) I'm able to seperate MIDI-CCs for volume- and sustain pedals. Problem: I don't see a possibility to store the routing for these data (f.e. routing sustain to a piano rack but not for the layered strings...).

3) Minor problem: no possibility to use MIDI-Loop-Back channels as sort of virtualisation.


regards, humphrey

[TiUser]

Hi, glad to help!

As I said many times there are a lot of things in Cantabie under the hood and some are hard to use because not all is "intuitive" on the gui side. But that's no real criticism either - I know well that this is not easy to do and things need time and feedback to grow.

->1)
Channel mapping is a midi filter and unfortunately here we face the "experimental" status concerning subsession context I already referred to.

Triggers may not directly solve the routing problem - except the plugin does the rest when receiving a program change or other appropriate controller.

Only workaround could be using midi routings as you can put midi filters in there. However it's a bit cumbersome to manage and I am also not sure if transitions work glitch free. In general I think the midi routing table needs some careful adjustments and cleanup.

My personal opinion concerning the racks is we need better support for multi timbral plugins which includes midi and audio. I guess this is for sure some work not just on the gui side.


->2)
Probably the only workaround is the same as before, putting the CC manipulations midi filters in the routing. Again it's cumbersome imho.