# Cubase template - disabled instrument tracks hosting VEP instances



## shomynik (Jul 21, 2018)

Does any of you on Cubase uses instrument tracks hosting VEP instances connected to a slave?

I haven't came across mentions of this, but it seems to me that combination of Cubase disable track feature and VEPs sampler slaving could be a very very powerful setup. I can't see why it couldn't work, I tried it a bit, but I'm kind of scared investing days in building that setup just to realize a flaw...building that template would mean that one have to host a single patch/articulation per VEP instance which would lead to hundreds of VEP instances....actually around 1300 in my case, split between three machines.

My story behind this:

So I upgraded my master machine (5820k 64gb) to a new one - 7820x 64gb ...old one is used as a slave now and also I have one more old slave, 2600k 32gb.

I made a new Cubase template, 1300 instrument/midi tracks, all hosted in VEP instances on the slaves and some on the master. What I'm noticing is that 300 stereo audio returns (just connected, no playback or anything), along with a few verbs activated, are getting my Cubase ASIO meeter, as well as my CPU to 50% idle at buffer of 256.

I don't like that and I'm pretty sure I could do better.

Lowering audio return count IS freeing resources, but i don't like that solution - I would like to have all those tracks for mixing in Cubase.

I was trying different things as to how to "turn off" that VEP connection for those returns - stopping VEP audio engine, or deactivating VEP plugin in Cubase IS freeing resources but only partly. The ONLY thing I found that completely turns that connection off while retaining all the tracks, routings and such, is Cubase track disable feature.

Disabled template is a such a great feature...but if you host everything in the Cubase on one machine, there is a limit how many tracks you can utilize at the same time.

But, if I'm not missing anything, one could use both! Disabled template that utilize power of multiple machines.

Right?


----------



## Grizzlymv (Jul 21, 2018)

Well. Not sure if that would help but anyway. I've been toying with the template with/without vep for quite some time and the conclusions I've come up with is to use an hybrid setup. I have all my orchestra (strings, woods, brass, some percs) in vep with rack/midi tracks in Cubase. Then everything else I may need to tweak the vi (synths, pianos, choirs, hybrid percs, etc) as instrument disabled tracks in cubase. 

Having everything as instrument / disabled tracks on a single PC is interesting (was doing it until not so long ago) but it uses so much resources that I had to put my asio setting way too high. Also, the project file size because incredibly high (around 1 GB) which slow down significantly the save process .Breaks the workflow

And having too many sessions in vep will causes slow downs as well. 

The way I am right now is only 4 instances of vep (strings, brass, woods and percs). Since I've reduced the amount of instrument tracks, the file size of the cpr have reduced to about 250 MB and the asio can be much lower too. 

The recents videos from Jason graves helped me quite a bit in optimizing the whole thing. You should have a look at his YouTube channel. 

Good luck.


----------



## shomynik (Jul 22, 2018)

Thanks for the reply! I actually read some of your earlier posts on the theme, so good to know where you ended in your tryouts 

And thanks for the info on Jason's videos, I had no idea he made those. Absolutely fantastic.

In my case, it turns out that I underestimated Slate VCC that I had on literally every track, as well as many reverbs that were just bypassed and not disabled. After sorting those out my ASIO meter dropped significantly, around the spot where Jason has it.

But I still like the idea of instrument tracks hosting VEP, but I think I will not go full template route now but start using additional instruments in that way and try it out.


----------



## Guy Rowland (Jul 22, 2018)

It is a very good idea, but there is a big problem. Disabled multi-out instrument tracks are buggy as hell (search here, TSB, Cubase forums). Once re-enabled, they grow phantom outputs, get jumbled up etc. Last week I even had clips on one play on a muted track. It's been this way across multiple machines certainly in windows since at least Cubase 8. It is logged with Steinberg and has a case number, but still no word on a fix after years.

So before you bet the farm on a 1,300 track template on this, at the very least I'd do some small scale tests. As it is, disabled multi out instrument tracks are to be used with great care. Monotimbral ones are stable, as are multi-out tracks that have never been disabled and re-enabled.


----------



## shomynik (Jul 22, 2018)

Guy Rowland said:


> It is a very good idea, but there is a big problem. Disabled multi-out instrument tracks are buggy as hell (search here, TSB, Cubase forums). Once re-enabled, they grow phantom outputs, get jumbled up etc. Last week I even had clips on one play on a muted track. It's been this way across multiple machines certainly in windows since at least Cubase 8. It is logged with Steinberg and has a case number, but still no word on a fix after years.
> 
> So before you bet the farm on a 1,300 track template on this, at the very least I'd do some small scale tests. As it is, disabled multi out instrument tracks are to be used with great care. Monotimbral ones are stable, as are multi-out tracks that have never been disabled and re-enabled.



Ah yes, I know everything about those problems with multiout instances, my attached midi tracks were losing routings and that was the reason I abandoned the whole thing when the feature was first introduced (can't remember if it was c8?).

HOWEVER, what I had in mind here is using single outs, so instrument tracks ONLY, with a single patch/articulation/instrument per VEP instance, so in my case, 1300 VEP instances. It's basically the same as using disabled Cubase template but only using slaves and expanding the thing.

It wouldn't look good in VEP though, but can't really see the problem cause with automatic instance raise feature in VEP, you get to your instrument GUI with a single key-command.


----------



## Grizzlymv (Jul 22, 2018)

Well, based on my past experience, 1300 instances of vep will probably not turn out great performances wise. Don't forget that you have a limited amount of channels you can have per instance in vep. So you'll end up using several instances in vep (one instance can hold several vst instances ). In my own experience, with two dozen of vep instances of maxed vst instances, my system was dying in term of perfs. So I can't imagine over a hundred. If you really want to go with 1 track = 1 instrument = 1 vst in cubase, I'd keep everything as disabled instrument tracks in cubase. 

Worked fine for the most part. But handling all the CPU and memory usage for such a large template over cubase wasn't the best for me. Sending over vep part of it helped quite a bit. Don't forget you can also disable vst instances in vep as well (although less convenient than within cubase). 

As other have suggested, try with a smaller scale, see if the workflow make sense for you. I'd also recommend you to have a track that is taxing your system already written. Then try it out over the different setups you are doing. You will have a better idea of which one respond the better for your need. 

For instance, I was trying to write a trailer track with a lot of processing for my last one .It was the first time I was taxing my system that much in a all cubase / disabled instrument track scenario. Wasn't holding up. Had a lot of cracks and drop out. Was barely able to mix. And that was with asio buffer set to the max (2048) which is unplayable for recording. The same track over a mixed setup of orchestra/percs in vep + midi rack tracks, and the rest in cubase with disabled instrument tracks was running smooth at 512... Same everything. So that was quite a LOT of improvement for me. 

There's no single solution from what I've learn. Try out, experiment, and see what works best for your workflow and your gears.


----------



## Prockamanisc (Jul 22, 2018)

Here's an incredibly helpful tip: save your tracks as Track Presets, then remove the VST from the track, then disable the track. When you want it back, it's very simple- enable the track, his the "refresh" circle/arrow thing in the track preset, and voila, your VST is back up as you left it. This saves CONSIDERABLY in project file size, and also save times.

Truth be told, I never really liked using a slave. Almost all of that is due to the fact that you can't easily put plugins on MIDI channels. Now my slave is relegated to being my VSL machine, and everything else is run as a track as needed in my master.


----------



## shomynik (Jul 22, 2018)

Grizzlymv said:


> Well, based on my past experience, 1300 instances of vep will probably not turn out great performances wise. Don't forget that you have a limited amount of channels you can have per instance in vep. So you'll end up using several instances in vep (one instance can hold several vst instances ). In my own experience, with two dozen of vep instances of maxed vst instances, my system was dying in term of perfs. So I can't imagine over a hundred. If you really want to go with 1 track = 1 instrument = 1 vst in cubase, I'd keep everything as disabled instrument tracks in cubase.



Well yes but here there would be only one stereo in/out (so 2 audio channels) and one midi channel per instance. Also, I have 3 machines (master+ 2 slaves), so 3 VEP projects, and those 1300 tracks are distributed between those (strings on one slave, woods/brass on second, percs/keys/synts/ on the master). So audio returns are distributed as well and.

But the best thing of all is that you don't have to preserve anything in VEP server project. Everything is saved in cubase with it's disabled tracks, so the 1300 track template in my case would look like this:

-1300 disabled instrument tracks in Cubase
-all the groups and FX channels
-3 VEP server projects on 3 machines - EMPTY!
-that's all!

Enabling a single instrument track in the Cubase would load a VEP plugin, open it's singe VEP instance in it's corresponding VEP project, activated, with all the cubase routings, ready to go. So you are enabling only what you need, and disable everything else. The count of audio returns corresponds to instrument count so you don't have 1300 stereo returns... well, you do IF you activate every single track, but no reason to do that.

One doesn't have to mess with VEP at all, doesn't have to label instances or whatever. It's a single VEP plugin, automatically connected to a single instance, with a single master stereo out, directly opened and activated by enabling instrument track, VEP instance raised on a single key-command.

How would that go with, let's say, 400 enabled instruments? I'm very curious. I think I will try that as soon as I have time, and report back.


----------



## shomynik (Jul 22, 2018)

Prockamanisc said:


> Here's an incredibly helpful tip: save your tracks as Track Presets, then remove the VST from the track, then disable the track. When you want it back, it's very simple- enable the track, his the "refresh" circle/arrow thing in the track preset, and voila, your VST is back up as you left it. This saves CONSIDERABLY in project file size, and also save times.
> 
> Truth be told, I never really liked using a slave. Almost all of that is due to the fact that you can't easily put plugins on MIDI channels. Now my slave is relegated to being my VSL machine, and everything else is run as a track as needed in my master.



I was actually using Track Presets, they are GREAT. But on my new system, with new version of Cubase, for some reason they don't work well, not sure what's the cause. My saved tracks take a minute+ to load which is crazy. It depends of the size of the preset ofc, but they were loading much much faster earlier.

But I'm curious... why do you remove VST and disable the track? Why don't you just delete them and just load when you need them?


----------



## composerlarkin (Jul 23, 2018)

shomynik said:


> Well yes but here there would be only one stereo in/out (so 2 audio channels) and one midi channel per instance. Also, I have 3 machines (master+ 2 slaves), so 3 VEP projects, and those 1300 tracks are distributed between those (strings on one slave, woods/brass on second, percs/keys/synts/ on the master). So audio returns are distributed as well and.
> 
> But the best thing of all is that you don't have to preserve anything in VEP server project. Everything is saved in cubase with it's disabled tracks, so the 1300 track template in my case would look like this:
> 
> ...



Am very interested to hear if this system works. On paper it makes a lot of sense. Please report back if you give it a shot!


----------



## shomynik (Jul 23, 2018)

composerlarkin said:


> Am very interested to hear if this system works. On paper it makes a lot of sense. Please report back if you give it a shot!


----------



## Guy Rowland (Jul 23, 2018)

I rarely have more than a dozen VEP instances tops, so 1,300 is a very long way above my experience. It seems very unwieldily to me. But from Cubase's end, it should work fine.



Grizzlymv said:


> There's no single solution from what I've learn.



That's my experience too.

I've heard on the grapevine that we may see some real improvements in this whole area in Cubase 10. I've got a sort of bodge system at the moment that is actually working very well in the most part, but it's far from a perfect solution. But I've no motivation to improve on it because I run into problems and bugs every direction I take. I'm just down to waiting for Cubase 10 and hoping the rumour mill is true.


----------



## shomynik (Jul 23, 2018)

And yes, saving times and project file size are all well controlled as you have the VEP decouple feature to use.


----------



## shomynik (Jul 23, 2018)

Guy Rowland said:


> I've heard on the grapevine that we may see some real improvements in this whole area in Cubase 10. I've got a sort of bodge system at the moment that is actually working very well in the most part, but it's far from a perfect solution. But I've no motivation to improve on it because I run into problems and bugs every direction I take. I'm just down to waiting for Cubase 10 and hoping the rumour mill is true.



That's very nice to hear!


----------



## Prockamanisc (Jul 23, 2018)

shomynik said:


> I was actually using Track Presets, they are GREAT. But on my new system, with new version of Cubase, for some reason they don't work well, not sure what's the cause. My saved tracks take a minute+ to load which is crazy. It depends of the size of the preset ofc, but they were loading much much faster earlier.
> 
> But I'm curious... why do you remove VST and disable the track? Why don't you just delete them and just load when you need them?


Mine don't take nearly as long to load, maybe between 3 and 10 seconds, from the smallest to the largest instruments. I'm using instrument tracks right inside Cubase again, not using VEP. Specifically with Spitfire instruments (not my VSL, they're still on my slave). When I load a Spitfire instrument, I have to load its legato patch, core patch, and decorative patch, and then route them to the proper place, etc. It takes a fe minutes for every instrument. So that's why I don't delete them. Does that answer your question?


----------



## shomynik (Jul 23, 2018)

Prockamanisc said:


> Mine don't take nearly as long to load, maybe between 3 and 10 seconds, from the smallest to the largest instruments. I'm using instrument tracks right inside Cubase again, not using VEP. Specifically with Spitfire instruments (not my VSL, they're still on my slave). When I load a Spitfire instrument, I have to load its legato patch, core patch, and decorative patch, and then route them to the proper place, etc. It takes a fe minutes for every instrument. So that's why I don't delete them. Does that answer your question?



But if you save the whole "package" of tracks as a track preset, you save all the routings and everything. For example... I have an instrument track hosting VEP instance connected to Hollywood Strings instance, and many midi tracks routed to that as well as 12 stereo audio returns, everything set like I want to. So, I just select all the HW Strings tracks (instrument track+midi tracks) and save everything as a single track preset so when I load that preset everything loads as it was saved, naming, midi/audio routings, everything. That's why I don't quite understand why don'y you just delete them if you don't use them.

Sorry if I'm telling you something well known and obvious to you.


----------



## Guy Rowland (Jul 23, 2018)

...umm... I'm going to have to check this out myself. I've never been able to recall routings, and Steinberg have never claimed it as a feature... so you're saying while it doesn't remember routings for 1 channel, it does for more than 1 saved as a track preset?!! Very much news to me if so.


----------



## shomynik (Jul 23, 2018)

Guy Rowland said:


> ...umm... I'm going to have to check this out myself. I've never been able to recall routings, and Steinberg have never claimed it as a feature... so you're saying while it doesn't remember routings for 1 channel, it does for more than 1 saved as a track preset?!! Very much news to me if so.



Oh yeah, it doesn't remember groups :/ I forgot that. It defaults to stereo out. But it saves everything else. But like I said, ATM it takes a LONG time to load one of my libraries that way. It wasn't like that earlier (I don't use the feature that much)


----------



## benmrx (Jul 23, 2018)

FWIW, my new template is setup somewhat similar to how the OP is thinking. I've got 1 VEPRO instance per instrument, and each instance only has 1 stereo out, and 4 MIDI ports. So, for example, I have a single VEPRO instance for SCS Violins 1. Inside that 1 VEPRO instance is 3 instances of Kontakt. Those 3 Kontakts are all loaded up with the various articulations for SCS Violins 1. I then have a single MIDI track in Cubase that is assigned to each of those articulations. So around 43 MIDI tracks are assigned to that 1 VEPRO instance.

Going this route, I've currently got around 50 VEPRO instances (still have another 30-40 to add).

My thought is that I can easily remove any VEPRO instances my current cue isn't using...., however all my MIDI and routing in Cubase stays. Then if I need to bring something back I can load that particular instance of VEPRO and then re-connect to that instance inside Cubase.

[EDIT]
However, I'm using 'RACK Instruments' in Cubase. I originally was trying to use 'Track Instruments'..., but I kept having issues where the VEPRO plugins in Cubase were losing connection with the actual VEPRO instances.


----------



## shomynik (Jul 23, 2018)

benmrx said:


> FWIW, my new template is setup somewhat similar to how the OP is thinking. I've got 1 VEPRO instance per instrument, and each instance only has 1 stereo out, and 4 MIDI ports. So, for example, I have a single VEPRO instance for SCS Violins 1. Inside that 1 VEPRO instance is 3 instances of Kontakt. Those 3 Kontakts are all loaded up with the various articulations for SCS Violins 1. I then have a single MIDI track in Cubase that is assigned to each of those articulations. So around 43 MIDI tracks are assigned to that 1 VEPRO instance.
> 
> Going this route, I've currently got around 50 VEPRO instances (still have another 30-40 to add).
> 
> ...


Well not really...what you described I use now in my template except with instrument tracks instead of racks (which is kind of the same, but I like the possibility to click on the instrument track in the project window and that track is automatically focused in the mixer) . And the idea here is using instrument tracks ONLY > containing a SINGLE vep plugin > connected to a SINGLE vep instance > containing a SINGLE kontakt instance > containing a SINGLE patch/instrument. This way you can disable the whole chain simply by disabling the Cubase instrument track, and in the mixer you get ONLY returns that you use.


----------



## benmrx (Jul 23, 2018)

shomynik said:


> Well not really...what you described I use now in my template except with instrument tracks instead of racks (which is kind of the same, but I like the possibility to click on the instrument track in the project window and that track is automatically focused in the mixer) . And the idea here is using instrument tracks ONLY > containing a SINGLE vep plugin > connected to a SINGLE vep instance > containing a SINGLE kontakt instance > containing a SINGLE patch/instrument. This way you can disable the whole chain simply by disabling the Cubase instrument track, and in the mixer you get ONLY returns that you use.



Yeah...., that's why I mentioned at the end that I'm using Rack Instruments. I didn't say my setup was _EXACTLY_ the same...lol. Just that it's similar in that there's only ONE 'instrument' per VEPRO instance, with each VEPRO instance only having 1 stereo out. 

FWIW I personally had MAJOR problems trying to use Cubase 'Instrument Tracks' for hosting VEPRO. It became too unreliable. _I wanted it to work_, because I would MUCH rather use a Track Instrument for various reasons (deactivating being one those reasons)...., but it just wasn't a reliable solution. At least for my system.


----------



## shomynik (Jul 23, 2018)

benmrx said:


> Yeah...., that's why I mentioned at the end that I'm using Rack Instruments. I didn't say my setup was _EXACTLY_ the same...lol. Just that it's similar in that there's only ONE 'instrument' per VEPRO instance, with each VEPRO instance only having 1 stereo out.
> 
> FWIW I personally had MAJOR problems trying to use Cubase 'Instrument Tracks' for hosting VEPRO. It became too unreliable. _I wanted it to work_, because I would MUCH rather use a Track Instrument for various reasons (deactivating being one those reasons)...., but it just wasn't a reliable solution. At least for my system.




Yes, there are major problems with disabling multiout instrument tracks.


----------



## Guy Rowland (Jul 23, 2018)

shomynik said:


> Oh yeah, it doesn't remember groups :/ I forgot that. It defaults to stereo out. But it saves everything else.



I think there's quite a bit else it doesn't recall - expression maps, Quick Controls, colours...

Quick Controls is quite important for me, but routing is very important. Its no small chore to load a library and then route it all.

Anyway, here's to optimism and Cubase 10...


----------



## shomynik (Jul 23, 2018)

Guy Rowland said:


> I think there's quite a bit else it doesn't recall - expression maps, Quick Controls, colours...
> 
> Quick Controls is quite important for me, but routing is very important. Its no small chore to load a library and then route it all.
> 
> Anyway, here's to optimism and Cubase 10...



I see... well, i don't use any of those...except colors, and those are actually fixed!


----------



## benmrx (Jul 23, 2018)

shomynik said:


> Yes, there are major problems with disabling multiout instrument tracks.



Not only that, but I was getting constant 'dropped' instances of VEPRO, where the instance would appear to be connected, but no MIDI would get through. This would happen randomly after closing my session and re-opening it. Sometimes instances would stay in-tact, other times they wouldn't. At first I thought it had something to do with specific Kontakt patches, but I soon realized the issue was using VEPRO on "Instrument Tracks". After I switched to "Racks", I haven't had a single issue.


----------



## shomynik (Jul 23, 2018)

benmrx said:


> Not only that, but I was getting constant 'dropped' instances of VEPRO, where the instance would appear to be connected, but no MIDI would get through. This would happen randomly after closing my session and re-opening it. Sometimes instances would stay in-tact, other times they wouldn't. At first I thought it had something to do with specific Kontakt patches, but I soon realized the issue was using VEPRO on "Instrument Tracks". After I switched to "Racks", I haven't had a single issue.


Wow, I started experiencing something similar, everything connected but midi doesn't go through...or it does, but the instrument in the VEP doesnt work for some reason and I have to reload it. Maybe's a similar culprit


----------



## benmrx (Jul 23, 2018)

shomynik said:


> Wow, I started experiencing something similar, everything connected but midi doesn't go through...or it does, but the instrument in the VEP doesnt work for some reason and I have to reload it. Maybe's a similar culprit



Sounds.... very similar to the issue I was having. Everything about the VEPRO instances 'looked' OK..., but nothing worked. And, as far as I could tell it was completely random. I even had an instance 'drop off' in the middle of having the Cubase project open. I just had to conclude that (at least on my system: OSX 10.11, Cubase 9.5, VEPRO 6) I _had_ to use Rack Instruments for working with VEPRO. So far after settling on Rack Instruments, all is well.


----------



## garyhiebner (Jul 23, 2018)

This looks pretty interesting. I have been using Logic and single instances. Obviously this is one of the preferred methods with Logic, as it doesn't handle Muti-timbral instruments as effective as Cubase. And I always remember reading that less VEP instances is better with Cubase. But keen to hear if this number of instances works for you with Cubase. Cos then I might move across to Cubase instead of my Logic + VEP setup.


----------



## Grizzlymv (Jul 23, 2018)

Prockamanisc said:


> Here's an incredibly helpful tip: save your tracks as Track Presets, then remove the VST from the track, then disable the track. When you want it back, it's very simple- enable the track, his the "refresh" circle/arrow thing in the track preset, and voila, your VST is back up as you left it. This saves CONSIDERABLY in project file size, and also save times.



That is a very interresting idea there! Just tried it with one track, and it seems to works well, so I might give this a try as well (will try with a recent project I did which killed my machine, hence the move to the hybrid mode). If project size and loading time is reduced, and doesnt't add much more to the complexity of enabling a track (maybe I can script something that enable + refresh track preset from a single hotkey), then I might get a winner and keep everything as disabled track. Thanks for the tip!


----------



## Synetos (Jul 24, 2018)

I also gave this a try. It seems to work pretty good with Track instruments, but not so good with Rack instruments since it really just disables the midi track and not the Rack instrument.

One thing though, when I disable the Track instrument, the VEP instance pops back on the list of available instances to connect another track. A list of 1300 would be really hard to manage without a good naming convention for the instances. 

I suppose it would be okay if while building the template I dont disable anything until I am done. It may also take a while to populate the list of instances when trying to connect a new track. Once the template is made though, I really wouldnt have to be opening this unless I am modifying the template. I think that was your point about not really having to mess with VEP connection once setup.

Otherwise, it is really a slick idea. I had moved away from using VEP and starting doing more with disabled tracks. It left me with my slave machine not being used for anything. Now, I can put it back in service, and run my localhost to move all the instruments out of my DAW environment. 

Thanks for sharing.


----------



## shomynik (Jul 24, 2018)

Synetos said:


> I also gave this a try. It seems to work pretty good with Track instruments, but not so good with Rack instruments since it really just disables the midi track and not the Rack instrument.
> 
> One thing though, when I disable the Track instrument, the VEP instance pops back on the list of available instances to connect another track. A list of 1300 would be really hard to manage without a good naming convention for the instances.
> 
> I suppose it would be okay if while building the template I dont disable anything until I am done. It may also take a while to populate the list of instances when trying to connect a new track. Once the template is made though, I really wouldnt have to be opening this unless I am modifying the template. I think that was your point about not really having to mess with VEP connection once setup.



The catch here is to un-preserve the instance (little lock icon, just unlock it), that way the instance disappear when you disable the instrument track and again appears (everything saved) when you enable the track. So everything should by unreserved (so it doesn't stay after disabling track) and coupled (so to be saved with cubase project. Of course, in the middle of writing, once you have a lot of active tracks and long save times, you can decouple everything and couple them just for saving.



Synetos said:


> Otherwise, it is really a slick idea. I had moved away from using VEP and starting doing more with disabled tracks. It left me with my slave machine not being used for anything. Now, I can put it back in service, and run my localhost to move all the instruments out of my DAW environment.
> 
> Thanks for sharing.



Glad to share an idea  Would be great if you report back once you finish your template!


----------



## Synetos (Jul 25, 2018)

Ah, I see, thanks. It worked just as you described. Perfectly!
I wont have as complex of a setup as some, as I do not do orchestral mock-ups, but I have many VST libraries that I like to have ready. 

I am loving the concept, so far. Thanks again for sharing!


----------



## Grizzlymv (Jul 26, 2018)

so. if I get it right (I'm more a visual guy),you guys are having 1 project (instance) in VEP (the colored boxes at the top), which contains 1 channel set (plugin) (the colored lines on the left pane) which contains 1 instance of Kontakt (in the right pane), with only 1 NKI instrument loaded in it, meaning that each VEP project (instance) would not have more than 1 channel set, and the Kontakt instance within that channel set would not have more than 1 instrument/audio out pair? 

Meaning in VEP for Strings, I'd have:
- "CSS Violin 1 - Spiccato" (VEP project (instance))
- "Kontakt 5" (Channel set) on MIDI 1 - Channel 1 - Audio 1/2
- "CSS Violin 1" with only the Spiccato articulation loaded on MIDI 1 / Out 1/2
- CSS Violin 1 - Staccato (VEP project (instance))
- Kontakt 5 (Channel set) on MIDI 1 - Channel 1 - Audio 1/2
- "CSS Violin 1" with only the Staccato articulation loaded on MIDI 1 / Out 1/2
and so on... 

then in Cubase, I'd have:
- Track 1 named "CSS-Violin 1 - Spiccato" (Instrument track) -> connected to a VEPro VST named "V1-Spic" on V1-Spic 1 / Midi 1

that "V1-Spic" VST would be connected to "CSS Violin 1 Spiccato" on my VEP Server, with the lock icon unlocked and decoupled (the (!) highlighted).

- Track 2 named "CSS-Violin 1 - Staccato" (Instrument track) -> connected to a VEPro VST named "V1-Stac" on V1-Stac 1 / Midi 1

that "V1-Stac" VST would be connected to "CSS Violin 1 - Staccato" on my VEP Server, with the lock icon unlocked and decoupled (the (!) highlighted).

Is that right? 

So that way, if I disable the the instrument track CSS-Violin 1 - Staccato in cubase, it would also unload the instance CSS Violin 1 - Staccato from the VEP server, so I would end up only with CSS Violin 1 - Spiccato on VEP Server?

That might be interesting, but I'm not sure how it would keep the CPR file size on the low side, as you'd still get hundreds of instrument tracks in Cubase (even if they are disabled). Unless you add the Track preset trick on top of it, but then it become kind of complicated to enable/disable a track. Unless I missed something along the way...


----------



## shomynik (Jul 26, 2018)

Grizzlymv said:


> so. if I get it right (I'm more a visual guy),you guys are having 1 project (instance) in VEP (the colored boxes at the top), which contains 1 channel set (plugin) (the colored lines on the left pane) which contains 1 instance of Kontakt (in the right pane), with only 1 NKI instrument loaded in it, meaning that each VEP project (instance) would not have more than 1 channel set, and the Kontakt instance within that channel set would not have more than 1 instrument/audio out pair?
> 
> Meaning in VEP for Strings, I'd have:
> - "CSS Violin 1 - Spiccato" (VEP project (instance))
> ...



Everything right except the VEP instances should be COUPLED so to be saved inside Cubase, otherwise, if not saved prior the instrument track disabling, it would not be loaded after enabling the instrument track. Only after saving the whole template, you could decouple VEP just during project saving so to avoid long saving time during writing.

I wonder about RAM load of instrument tracks as well, but a simple test can be easily done, just load, for example, 300 instrument tracks loaded with VEP plugins, and see (I can't do it myself right now).

The trick with preset tracks wouldn't be good as those don't save group routings.


----------



## Grizzlymv (Jul 26, 2018)

shomynik said:


> Everything right except the VEP instances should be COUPLED so to be saved inside Cubase, otherwise, if not saved prior the instrument track disabling, it would not be loaded after enabling the instrument track. Only after saving the whole template, you could decouple VEP just during project saving so to avoid long saving time during writing.



You're right. Just did a quick test with the scenario I've described above, and that's what I realized. So, all in all, it works fine (need to check the CPR size for several hundred tracks), however, it takes MUCH longer to enable a track that way than having the VST directly within Cubase. For instance, enabling a disabled Kontakt instrument track will take 4 seconds. The same with the VEP instance will take up to 8 seconds, twice the time!. not sure I'd gain anything compared to host the libs in VEP with less insances and access them through rack tracks.


----------



## Grizzlymv (Jul 26, 2018)

well. that solution won't be a good fit for me. I just tried with a 25 tracks CPR, each tracks being an Instrument Track hooked on a VEP instance (so 25 instances in VEP), each containing 1 articulation from CSS. CPR size is already 13 Mb, and the load time is up to 2mins 45 seconds!. so I can't imagine how a full project with more than hundred track would be to load. Considering the file size is about a little more than half the amount of track, we could say that a thousand would be between 500-600 Mb. The loading time for a 150 tracks would be 17-18 minutes... that's crazy. My Cubase Instrument track only (without VEP) would take max 5 minutes to load. That's definitely something to think about and I'd strongly recommend to do some tests at different levels before you go all in with the solution above.


----------



## shomynik (Jul 27, 2018)

Grizzlymv said:


> well. that solution won't be a good fit for me. I just tried with a 25 tracks CPR, each tracks being an Instrument Track hooked on a VEP instance (so 25 instances in VEP), each containing 1 articulation from CSS. CPR size is already 13 Mb, and the load time is up to 2mins 45 seconds!. so I can't imagine how a full project with more than hundred track would be to load. Considering the file size is about a little more than half the amount of track, we could say that a thousand would be between 500-600 Mb. The loading time for a 150 tracks would be 17-18 minutes... that's crazy. My Cubase Instrument track only (without VEP) would take max 5 minutes to load. That's definitely something to think about and I'd strongly recommend to do some tests at different levels before you go all in with the solution above.



I see...I have to try it.

But, you don't have to ever save thousands of active tracks, just the ones you use. Your full template should be saved disabled, so VEP servers should be empty.

So, by your count... 250 active track project should be a size of 130mb, which sounds very ok to me.

But those saving times sure sound scary... but I don't remember 8sec loading per track when I tried.

I'll try with larger track count and report back.


----------



## Grizzlymv (Jul 27, 2018)

Well it is not the saving time that is the issue but the loading time. But to be honest, it could be a little bit reduced. I used css violin 1 classic legato patch which I duplicated 24 time. So using another articulation which takes a little less resources might be a little faster to load. But still, it will cut down a few seconds, but not so much. 

Also, the 250 tracks count was for an active project, not for the whole template . It's not rare I work on a project which have above 200 enabled tracks. With 1 articulation per track, the count increase quickly. But that's still over 800 tracks that would be disabled . So 18 minutes to open a project is way too long for me .

And finally, been thinking about it, and maybe I missed something, but I don't see the gain of using vep in that one to one scenario. Beside adding a middle man which will put away the vst UI, I don't see any other gain unless your vep server run on a slave machine. To me, the real advantage of vep is when you have multiple tracks using the same channel or instance in vep, which saves resources in the daw or to use in multiple machines. In my case, my main one is powerful enougj so everything run on it. 

So after all those tests, the best scenario to date is still an hybrid one where you have some disabled tracks in cubase, but offload the main orchestra and other samples you don't really need to access the vst UI in vep, using rack tracks binded to few instances. This greatly reduced the stress on the daw, greatly reduced the file size of the cpr, greatly reduced the loading time as well ( for the daw, as for vep, it is increased like crazy, unless you disable the channels within vep as week, which I don't since I have enough memory to keep them loaded). 

Would be interesting to know what the results of your tests are on your side. Maybe I overlooked something.. 

Best.


----------

