Opinions for most wanted improvements...

[humphrey]

...indeed, and here one from my side:

I also use Win Vista 64 since some years. Tweeking it was a pitty but since I deactivated the main "microsoft breaks" it works very stable and performant for me too and than you I even use Vista on Stage and never had any issues. The main problems mainly occour when loading sample content (specially kontakt)...

kind regards, humphrey

[TiUser]

... The main problems mainly occour when loading sample content (specially kontakt)...

Ok, I totally agree to this.

A long time ago I suggested to have an option to "freeze" certain plugins. As far as I know there is already a cache that keeps plugins for reuse in the next session. I think it would be a logical step forward to keep dedicated plugins in the cache and extending this by taking care for the reload problem.

Additionally I personally also experienced that sample based instruments are more critical. I'm using sfz+ and it needs much more memory than one might think just looking at the sample lib files. There is an option for direct from disk streaming but that needs a second hd and dedicated configuration (no internet, no background virus scanner,...). As I usually do not work on an optimized machine when develloping this is a point I struggle with too.

Finally my opinion is that loading samples into memory is not the future. We need solutions where we can instantly access sample sounds like HW without loading times. Looking at LinuxSampler or the discontinued GigaSampler this technolgy looks like an old hat... I really wonder why available samplers seem still to struggle with that...

[gaap]

How about side-chain function ?

[TiUser]

Apprechiated.

However I would prefer to see a better to set up master bus configuration first. I hope this is already in Brad's pipeline...

[nikilugli]

Hi,

I'd like to have something like "live view" instead of the current status bar and I'd like to have different levels of subsession (mainstage style).

[TiUser]

Can you please descibe your imagination of "live view" more in detail? I have difficulties to understand this idea.

I'm also not familiar with mainstage - how shall "levels of subsessions" work? Currently subsessions are just a state within a session - you can not separate a subsession from it's session context. However there could be any type of view on these states. Today there are just 2 direct linear views, one sorted and one unsorted. Another oprion of "view" on subsessions is creating a setlist - but as said - subsessions do not exist there without a session context.

[nikilugli]

Can you please descibe your imagination of "live view" more in detail? I have difficulties to understand this idea.

I'm also not familiar with mainstage - how shall "levels of subsessions" work? Currently subsessions are just a state within a session - you can not separate a subsession from it's session context. However there could be any type of view on these states. Today there are just 2 direct linear views, one sorted and one unsorted. Another oprion of "view" on subsessions is creating a setlist - but as said - subsessions do not exist there without a session context.

For me a 'live view' could be a simple 'status' page - that already exist - but at full screen with high contrast between background and main text.
Probably 'Level of subsession' wasn't the correct translation of my ideas. I'd like to have a quick way of arrange a setlist. I'll explain: it could be useful to 'import subsession in the current setlist' feature and - depending to this - a subsession browser with tag features. In that way it could be very simple and fast arrange a setlist, importing favorites layered sound, split, and so on...
Sorry for my bad english...

[TiUser]

I see...

However, the current setlist in the Solo and Performer versions already contains a function to insert all subsessions of a session... "Insert" -> "All subsessions from current sessions"

Ok, there could be more stucturing options and probably a bit more comfort here - but the basics are already present.

[pinkcanaru]

Hi TiUser,

- comfortable audio routing for multitimbral vstis => automatically generating a set of controls (volume, pan, eff-sends) for every additional stereo-out of a vsti

regards, humphrey

This is a real biggy for me.
The most powerful workstation like VSTi all feature multiple outputs. 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.

To have the additional outputs appear within the same rack is not going to allow discrete processing. Each additional set of outs would need to reside in the equivalent of a new rack. Perhaps, in this case, something along the lines of 'parent/child' racks might provide a solution that acknowledges the relationship between these multiple outs while leaving the instantiation and bypass etc to the parent alone.

Thanks!

[TiUser]

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...

[pinkcanaru]

Hi TiUser and thanks for the heads up on that approach.
I remember battling with this area before and getting no joy - so I have gone back in to see what I can find.
Quite honestly, even if the method is convoluted, I'll take that over having no solution at all.

So far - it's a bunch of white noise but that's probably some vital thing I'm missing.
Firstly, can we define 'virtual channels'?
At the moment, I'm using the built in audio of the laptop with ASIO4All -.

When one goes to configure the Master Bus outputs one sees a maximum of 32 channels. I'm assuming all of these are virtual until one assigns to physical outputs. In my present scenario, that's limited to the so called HD outs of the laptop which are available in Assign Audio Channels.

So now the task is to get, say, the B outputs of Omnisphere to appear at another rack.

The outputs are enabled in Omnisphere using the Tools.
I enable Auxilary 19 and 20 arbitrarily and assign Omnisphere B outs to those.
Now to get the audio into a new rack.
Presumably, one has to employ a plugin that accepts audio input because, as far as I can tell, an empty rack has no provision for audio input.

I used a compressor to see what I could get going. Enabled input on the rack. Nothing. Enabled the master input - white noise.

I've not found a FAQ on this issue - so I'm stumped.

Hope you can shed some light.

[pinkcanaru]

Hi,

I think the only workaround is to load all of the sounds only once (which of course is only possible when you have enough RAM available and use a 64Bit OS - probably with jBridge for isolation issues). Sub-Sessions could probably do the trick but here we have the problem that they don't have all the necessary MIDI-featured available.
humphrey

I believe Sub-Sessions do allow for all eventualities as long as all required Sub-Sessions reside within one Session. I am circumnavigating the sampler load issues by nominating one instance of my streaming sampler to NOT load the entire bank. It contains the sounds that take way too long to load live - so load once and forget about it.
Have another instantiation of the sampler which does load banks - so that programs which are less intense can be loaded on the fly.

Midi Routing Table , which contains all the routing possibilities one could need, coupled with the quick transposition / range /split function available on each rack (and Sub-Session recallable) makes this approach pretty near flawless.
I'm currently running 4 gigs of ram and and with a massive piano and string bank loaded full time in Hal4, an additional 'floating' Hal 4 which does load banks - 2 x Omnisphere, a VB3 - Mister Ray 73 and 4 x Synth1, a clutch of compressors and eqs, reverberation devices and a DDLs, the system has 1.5 -2 gig spare and the CPU is running at no more than 40% peak with a buffer of 248 (5.6 ms.) The OS is Win7 64 and jbridge is used.

I have roadtested this and the Sub-Session recall is tremendously fast.

By placing only the Sub-Sessions required into the SetList, the clutter of having a massive amount of Sub-Sessions is hidden away from sight.

The issue for me now, because of this massive amount of Sub-Sessions in one Session, is managing the MIDI Routing Table which is now enormous and very unwieldy.
Isn't the most powerful filtering location the MIDI Routing Table? Isn't it there that we need to see some 'housekeeping' tools?
I can imagine that being able to use folders in the MRT would allow each Sub-Session to have its unique routings stored clearly, compartmentalized from other Sub-Sessions. Entire folders of MIDI Filters could be colored, copied, pasted, muted and enabled there! I would hope that this would also be reasonably simple to employ as no fundamental architecture needs to change.
Clarity would be enhanced and, of course, the MRT is recalled with each Sub-Session.
Thanks!

[humphrey]

Hi pinkcanaru,

I think we agree about the principle way subsessions could be used to fix the sample-load-time problem. Of course it is useful to disable "entire banks" only for samplers (and if you like only those with heavy memory-load). I use Halion 4 and Omnisphere like you and agree: for many samples it's o.k. to load content at the moment you call up the subsession.

It's also rudimentary to enable "entire banks" for all algorithmic vstis of course (in my case DIVA, OP-X II Pro, VB3, Sylenth1, FM8 and Minimoog V).

I also use Kontakt 4 (mainly cause I like the Scarbee E-Pianos). Here it is essential to disable "entire banks": it is not only necessary from the load-time point of view - Kontakt tends to crash from time to time when changing content (not only in cantabile - same problem in forte). In this case advanced MRTs are not that useful: a tool for sending MIDI program changes would be useful as Kontakt has the possibility to combine samples in bank with up to 128 sounds in it. The sound then have to be called up by pc-instructions. A modified Triggerevent would be able to manage this.

So far so good. What you pointed out further down the text sounded very interesting. Till now I saw a possible solution in storing the parameters of MRTs together with the corresponding subsession (just as it is now for a session). For me it would also be a plus to make MIDI-filters storable.

But what you describe seems to go a little bit further? I can imagine some aspects but did not really understand it in detail. So: it would be really great if you could point out a little more in detail what you are thinking of.

Thanks and regards, humphrey

[pinkcanaru]

Hi there Humphrey,

What I am suggesting is that the MRT operate exactly as it does now - but allow the entries to be contained in nameable, collapsible, folders/directories - whatever you want to call them.
Once you group Midi Routings into folders other possibilities surface:
You can mute an entire folder - you can solo a folder - cut/copy/paste. Color.
And, most important - you cut down on all that clutter!

From a software point of view, it uses the identical system that is currently in place.
Old sessions will load seamlessly and MRTs can simply be placed in the new 'Folder' facility in the MRT window.

On my other question - regarding routing of additional outputs from a multi-out VST back into another rack - I cannot get that happening at all. I have been able to enable the additional outs from, say, Omnisphere, but there is no configuration I have found which allows those outputs to be plugged into another rack. Have you been successful with this?

[humphrey]

Hi,

last first: the audio output routing is real pain in the ass to my mind. I was able to route a rack to another output (in my case this was necessary for a seperate clicktrack for the drummer). I don't remember ever having managed routing outs of an instrument to different outs of cantablie). I definitely never even tried to route more than 2 outs of a rack to another rack. So sorry: there is not much experience on my side and I'm sure this would have to be improved in a coming update.

Back to your concept of using folders or the like to fix the problem of non storable MRTs. I agree folders could be a great advantage for collecting a bunch of MRTs and "hide" them in a folder and activating mute or the like for the whole folder also is a good idea. The concept is also intelligent as this can garantee compatibility with older projects.

What I don't really understand is how this could solve the problems I see (and maybe it's me not to see the wood for the trees). To give you an example:

I use 2 MIDI-Keyboards with one Sustain-Pedal and one Volume-Pedal on one of them. Then I have lets say 5 sample-driven plugs for whom I'd disable "entre banks". Let's further say that each sampler has 8 sounds in it routed to separate MIDI-channels.

I want to be able to control each of the 5 plugs by any of the 2 keyboards plus each of both controllers has to be routable to any of the vstis (this to keep it simple - in a real scenario I also use other controllers I'd like to route to any of the vstis).

In this case I'd need 8 MRTs per vsti and each of the 4 controllers (keyb.1, 2 , Vol. Sustain). This makes 160 (!) MRTs in my calculation.

Is it possible to reduce the amount of MRTs without storing the MRT-data in a Subsession? Is your scenario able to do the trick.

regards, humphrey