V-Racks, Aux Tracks, Pre-Gen, Clippings, VEP vs Local

[terrybritton]

Here are my notes concerning the headline topics and how they work together:

V-Racks (or even a single v-rack) are convenient for sampled instruments where there is no need to change much, as you can assign a bunch of sequence chunks to them and they will not reload the samples every time you switch chunks/sequences.

Plugins residing inside of an AUX track CANNOT take advantage of PreGen. Aux-track plugins are active (RealTime) all the time. Use Audio Tracks instead.

As V-Racks cannot receive track automation themselves (they can receive MIDI CC's - see comment below), automation can be applied to an AUX track receiving the output. Better yet, have an Audio track receive the automation rather than using an aux track so you can have plugins involved that are easy to turn off and on, and which go into Pre-Gen mode when no longer recording or monitoring the input to that audio track.

V-Racks can contain single instruments or entire collections of instruments and AUXes, with the AUXes best serving as routing tools ONLY since Aux tracks do not work to take advantage of "PreGen".

With Audio Tracks hosting your FX plugins, when the monitor or record enable are turned on then the plugin works in RealTime; when those are switched off, the plugin then takes advantage of Pre-Gen, saving CPU resources. (Again, do not insert plugins inside regular AUX tracks or inside AUX tracks in V-Racks, as those will always be running in Realtime. Send the output of an AUX track to an Audio track utilized for hosting the plugins instead.)

Clippings can store V-racks of any size for easier retrieval into other projects than is loading V-Racks from another project.


Normal Tracks AND V-Racks: Local Instrument Plugins -

Instruments remain in RT or RealTime IF A MIDI TRACK TARGETING THAT INSTRUMENT HAS RECORDING ENABLED. When recording to the MIDI track is turned off, its target instrument then renders in Pre-Gen mode. In some cases, you need to close the plugin window for it to take effect. (You can tell in the FX Performance window what its status is, pre-gen or real time.)

Normal Tracks AND V-Racks: Vienna Ensemble Pro (or VEP ) Hosted Instrument Plugins -

VEP instruments and FX hosted by the VEP plugins are always in RealTime mode. The best route to take to free up resources is to either freeze the tracks, bounce them, or record into an audio track while performing so you can power-down the VEP instance to free up the resources.

VEP instruments remain in the FX Performance list if you don't have them in a V-rack, even if you power them down. Mind you, when powered down, they use no resources, but they still clutter up the list. If placed into a V-rack, then you can power the VEP plugin down and it (or a V-rack full of them) will be removed from the RT list.

I hope this is a clear list. I'll incorporate any suggestions and corrections into this post that you may have to offer.

Terry

[nk_e]

V-Racks (or even a single v-rack) are convenient for sampled instruments where there is no need to change much, as you can assign a bunch of sequence chunks to them and they will not reload the samples every time you switch chunks/sequences.

As V-Racks cannot receive automation themselves, automation can be applied to an AUX track receiving the output.

Terry,

Forgive me if this is an obvious question, but when you say VRacks cannot receive automation data, does that include MIDI cc data? So an instance of Kontakt in a VRack could not respond to cc 11 automation for example?

Thank you.

George

[terrybritton]

Terry,

Forgive me if this is an obvious question, but when you say VRacks cannot receive automation data, does that include MIDI cc data? So an instance of Kontakt in a VRack could not respond to cc 11 automation for example?

Thank you.

George

It's definitely not very obvious! No, to clarify, MIDI data is received just fine. It is DP's automation recording that is turned on in the mixer and its curves track that does not work with V-racks. So, if you rely on that (I avoid using DAW automation myself), then V-racks are not for you. But it is my understanding that you can do any MIDI stuff you wish.

I typically relegate V-racks to instruments that are not going to change from chunk to chunk, though, as any change you apply to the V-rack instrument is going to carry over into the next chunk using that instrument, as the changes don't "reset" unless you actually do remember to send reset commands, though that is not a complicated thing to do, especially for volume resets which I might do for a new chunk anyway as part of balancing. I keep V-racks (and VEP-hosted instruments) mostly for sampled instruments that won't change other than having volume changes, but you are not limited to that.

Terry

[nk_e]

Terry,

Forgive me if this is an obvious question, but when you say VRacks cannot receive automation data, does that include MIDI cc data? So an instance of Kontakt in a VRack could not respond to cc 11 automation for example?

Thank you.

George

It's definitely not very obvious! No, to clarify, MIDI data is received just fine. It is DP's automation recording that is turned on in the mixer and its curves track that does not work with V-racks. So, if you rely on that (I avoid using DAW automation myself), then V-racks are not for you. But it is my understanding that you can do any MIDI stuff you wish.

I typically relegate V-racks to instruments that are not going to change from chunk to chunk, though, as any change you apply to the V-rack instrument is going to carry over into the next chunk using that instrument, as the changes don't "reset" unless you actually do remember to send reset commands, though that is not a complicated thing to do, especially for volume resets which I might do for a new chunk anyway as part of balancing. I keep V-racks (and VEP-hosted instruments) mostly for sampled instruments that won't change other than having volume changes, but you are not limited to that.

Terry

You have no idea how much time you just saved me. Thanks!

[Michael Canavan]

First of all great list! I don't know how many times this stuff gets posted and answered here!

A couple observations, please take them with the good will they're meant to be.

V-Racks can contain single instruments or entire collections of instruments and AUXes, with the AUXes best serving as routing tools ONLY since Aux tracks do not work to take advantage of "PreGen".

This is true for everything except heavy duty "gluing" reverbs. There's a law of diminishing returns with PreGen, if you have a dozen or more instances of a reverb you want to affect tracks in the same way, you're going to be better served by Aux Tracks than PreGen. PreGen generally gives back more CPU, but in larger setups with sends to an Aux track you will get the same after a point, and more CPU after further tracks instantiate that reverb.

You can test this, I just instantiated 8 instances of Kontakt, sent them to an instance of Altiverb on an Aux Track in a V-Rack, then disabled/deleted the Aux track and put the exact same instance of Altiverb on all 8 tracks. This seems to be the golden zone where the CPU use is about the same on my system, but I have a feeling past that, the Aux track will start to show less CPU use.

VEP instruments remain in the FX Performance list if you don't have them in a V-rack, even if you power them down. Mind you, when powered down, they use no resources, but they still clutter up the list. If placed into a V-rack, then you can power the VEP plugin down and it (or a V-rack full of them) will be removed from the RT list.

Do not take this the wrong way, I've been using DP on and off since about 1997, even used a copy of MOTU Performer back in the 80's, and I did not know how to power down (in MOTU speak disable) a track or V-Rack in a way that took all resources back to DP outside of disabling V-racks.

Just selecting bypass or disabling the plug in in it's own GUI will not disable it fully. You can enable and disable a Sequence Editor track or Mixer/V-rack track in the track itself. "Enabled" in the Tracks three sideways bars menu (DP10 default theme) in the Sequence Editor, and in the Mixer/V-Rack tracks the menus is the downwards pointing arrow at the very bottom of the Mixer/V-Rack track. unchecked it completely disables a track and gives all resources back just like disabling a V-Rack in the Chunks window.

Doing this with VEP instruments (the MAS plug in one, I can try the VSTi as well), here in the Sequence makes them disappear from the Effect Performance window. Hopefully that helps and it's not a VEP, MOTU plus Windows thing.

[HCMarkus]

Great stuff gents!

[Michael Canavan]

Oh, one more thing we both forgot. Multi out instruments apparently now can PreGen!

There are caveats though, setting up a Kontakt instrument with 4 heavily scripted legato instruments from Cinesamples, without the record on any of the MIDI tracks even with Aux outs on all doesn't use but a 20th of the Real Time and Pre Gen meters. Record arming for play one of the instruments MIDI tracks puts the Real Time meter to about 95%. 80% even without playing.

The same instruments as solo instruments do not spike the CPU as hard when record armed. They use the same amount of CPU when tracks are not armed though. My take is to only use multi instruments when you're not killing the CPU. Each track in DP is more or less using only one core of your computer, so you can max out a 12 core computer with one track if you wanted to. In general though, I would go with maybe two or three instruments in a Multi, making it easier to play when a set gets big. Huge multis only make sense with instruments that aren't heavily scripted.

[HCMarkus]

The facts that routing thru Aux abolishes Pre Gen leads one to note that VCAs reduce the need for Aux Bussing for groups of tracks.

Which leads an old Aux Busser Clucker to ask, "How are VCAs working in DP10.11 these days?"

[terrybritton]

Thanks HC and Micheal for the great input!
I've barely touched my VCA's so far, but do plan to. I like the way they work with the track sends for shared reverbs especially. I would still send to a bus acting as input to an audio track over using an AUX for the reasons mentioned here and elsewhere in this thread for permitting using pregen.

I've never used multi's from Kontakt, as it always felt like "opening a can of worms" to me! I do extensive routing to Auxes in V-racks from VEP outputs and busses, but that is using the Auxes explicitly as routing tools only, and one seldom needs to touch them again after the routing is done (to an audio track or monitoring output, sometimes with both outputs and sends being employed).

Terry

[Michael Canavan]

The facts that routing thru Aux abolishes Pre Gen leads one to note that VCAs reduce the need for Aux Bussing for groups of tracks.

It doesn't abolish PreGen, this might be new to DP10 I don't know? So a multi audio out like Kontakt can use multiple Aux tracks and still Pre Gen. What it does though is it puts more CPU on the multi instrument if it goes to Real Time, because the entire instance of Kontakt goes into Real Time, not just the MIDI channel/instrument you're playing on.

[terrybritton]

The facts that routing thru Aux abolishes Pre Gen leads one to note that VCAs reduce the need for Aux Bussing for groups of tracks.

It doesn't abolish PreGen, this might be new to DP10 I don't know? So a multi audio out like Kontakt can use multiple Aux tracks and still Pre Gen. What it does though is it puts more CPU on the multi instrument if it goes to Real Time, because the entire instance of Kontakt goes into Real Time, not just the MIDI channel/instrument you're playing on.

To clarify, Routing through an AUX abolishes pregen for the FX plugin it is hosting only, and does not affect the pregen for the source that is routing to that Aux, like an instrument for instance. But since I can get the same result by hosting my FX plugin in an audio track - plus have the convenience of making a stem and then having that stem use the plugin in pregen mode - hosting my FX plugin in an audio track offers options that Auxes do not possess. (Audio track input monitoring was the feature addition that made that feasible.) Pregen provides a similar kind of benefit that "freezing" that audio track might offer, but the "freezing" is done on-the-fly by the pregen engine. That is how I understand it, anyway. Perhaps there is a clearer way of describing it. But as such, pregen has to use resources that a "frozen" track would not require, as the processing is already done to the "frozen" track.

Terry

[HCMarkus]

To clarify, Routing through an AUX abolishes pregen for the FX plugin it is hosting only, and does not affect the pregen for the source that is routing to that Aux, like an instrument for instance.

Thanks for that Terry. There are definitely places an Aux Bus is gong to continue to be the preferred approach

[yperochiakeraiotita]

My take is to only use multi instruments when you're not killing the CPU. Each track in DP is more or less using only one core of your computer, so you can max out a 12 core computer with one track if you wanted to.

Hi Michael! Thank you for your insights. Regarding the one track to one core, how did you come up with this? I'm currently running a 6-core Min. I'd like to know how this would apply to my situation. I usually work with fairly big orchestral templates with several things going on on maybe 7-10 tracks at a time. So far I haven't experienced bad system chokes but would like to know if there's something I should avoid given my 6-core system.

In general though, I would go with maybe two or three instruments in a Multi, making it easier to play when a set gets big. Huge multis only make sense with instruments that aren't heavily scripted.

This makes a lot of sense. I've found that spreading over resource-heavy libraries (like having a separate instance of Kontakt for 8Dio Anthology only) works better than filling up all 16 slots of Kontakt then making running another instance. Solid advice. Thanks man!

[Michael Canavan]

Hi Michael! Thank you for your insights. Regarding the one track to one core, how did you come up with this? I'm currently running a 6-core Min. I'd like to know how this would apply to my situation. I usually work with fairly big orchestral templates with several things going on on maybe 7-10 tracks at a time. So far I haven't experienced bad system chokes but would like to know if there's something I should avoid given my 6-core system.

Mostly you can do this in real time with the Effect Performance Window. You can monitor between that DP window and in OS X anyway the Activity Monitor, overloading a single CPU is easy to do, but DP like most DAWs assigns a track to a single CPU, and all plug ins in that track to a single CPU core. So knowing that spreading out orchestral templates based on CPU hit is a good idea. Multi patch Kontakt instances with simple scripted instruments, and single patch instruments with heavy scripts. Cinesamples in my case using two instances of heavily scripted string libraries on the same track can take out my CPU. It doesn't even flinch when I put a dozen instances on multiple tracks though. (12 core mac pro)

[cvtonyd]

I may have misunderstood the info in this thread. . . .

my situation is a 4 core i7 2.9Ghz MacBook Pro, 16GB RAM, now redlining DP10.11 real time monitor and getting clicks/pops/delays in playback, even at 1024K buffer.
I'm working with ~40 tracks:
- 7 MIDI
- 5 audio
- 17 aux tracks from VIs
- 11 aux tracks for buses
- about 30 of the tracks have plugins, but none of the efx are in the red in efx monitor, and only 2 are even close to halfway in the graph.

Below you're saying that efx on aux tracks add to realtime CPU load, and you indicate that moving the efx to a standard audio track fixes the problem.

however, when i try to substitute a standard audio track for an aux track, as either a bus or an individual VI track, i get no input on that track, even though it's routed identically to the aux track it replaced.

what am i missing, and is this the source of my CPU overload?

many thanks.