# VEPro and Cubase - kind of working now



## dtcomposer (Aug 13, 2015)

So this is my first time trying to set up VePro on a two computer system, and I tried to prepare myself for some inevitable issues, but it is a bit worse than I thought and basically unusable for me at the current time. I'm in contact with support from various companies to figure out what is wrong, but I've often found better answers here in the past.

The problems.

1.* PLAY loading and unloading times are massive while connected to Cubase.* If I exit a project with my play instances (2) loaded, it takes about 6-10 minutes to unload all the audio channels, while my kontakt instance takes about 5 seconds to unload the same amount. If I disconnect the PLAY instance to avoid the long unloading process, it takes about 12 minutes to auto-save and freezes Cubase until it is saved. PLAY is on the new Slave build. I have sent a request to EastWest for some guidance since VSL support said that it was a PLAY issue.

*2. CPU levels are high for all instances connected to Cubase.* This applies to Kontakt, PLAY, and other instances on either computer. If I turn on the audio engine in Vepro without being connected the CPU meter reads 0%, once I connect Vepro in Cubase the meter jumps in proportion to the size of the instance in RAM. Here are the instances I have tested so far, the numbers were the same individually or when all loaded.

1. Omnisphere,SWAM,Amplesound (3-5 GB) - 7-10% CPU at rest
2. Kontakt (20 GB) - 50-60% CPU at rest
3. PLAY 1 (36 GB) - 70-80% CPU at rest
4. PLAY 2 (13 GB) - 60-70% CPU at rest
5. PLAY Together - 90%! Cpu at rest.

I ran latency monitors while this was happening and they all checked out in the green. The CPU was actually running at these speeds according to the CPUID CPU monitor. The fact that the same issues are happening on both computers leads me to believe that it is a VePro-Cubase8 issue.

Things I have tried without improvement:

Update all drivers and software on both computers
Uninstall/Re-install PLAY, VEPro (haven't yet re-installed Cubase)
Adjust Hyperthreading combination
VE pro cores (1-6)
Kontakt hyperthreading on off in combination with low/high VEpro cores

Turned off ASIO guard
Turned on ASIO guard on different levels
Adjusted Buffer settings in VEPro (0-4 buffers attempted)
Adjusted number of midi,audio outputs
tried with audio outputs disconnected entirely 

Honestly I am at a loss at this point. What else could I try? I think my computers should be able to handle the load without too much issue. I'm especially interested to hear from Cubase 8/Vepro users with larger templates who are having success. I'll update when I hear back from VSL, or as I find new answers.


----------



## DR BOOWHO (Aug 13, 2015)

I am having similar problems with Play Vep and Cubase. On my X99,5960x and 64gb ram when I close VEP and monitor the ram unloading it takes minutes, yet on my i7 920 only running Kontakt which has 24gb ram and is 5 or 6 years old it clears 20gb of ram in 20 secs or so.Loading times are very poor on new machine running Play.I got the same response from VSL saying it was a Play issue and as yet heard nothing back from East West. 
Another thing I notice is when it finally does load each time I change to a different sound on a different instance of kontakt or play there is a delay before the sound plays. Don't know if that's normal only I never noticed it before I went to Main and 2 slaves.
Hollywood Percussion will crash the system if I try and load a large selection of instruments so I can't use it in my template.
So although I have no answers you are not alone


----------



## EastWest Lurker (Aug 13, 2015)

Big Hollywood Orchestra patches do take a while to unload on both my Mac and PC but the other stuff, I am not seeing connected to Logic Pro.

You guys are hopefully working decoupled, right?


----------



## dtcomposer (Aug 13, 2015)

EastWest Lurker said:


> Big Hollywood Orchestra patches do take a while to unload on both my Mac and PC but the other stuff, I am not seeing connected to Logic Pro.
> 
> You guys are hopefully working decoupled, right?



I am always working decoupled, yes. I can confirm that the RAM unload is glacial when involving PLAY libraries for whatever reason. I wouldn't really care about that if I could just load the patches once per day, and keep them separate from Cubase. They connect without issue, but disconnecting in any way, or closing a project causes chaos delays. I also had some crashes when trying to load separate instances for each section of Hollywood Orchestra, but was able to load everything but percussion up on one big instance. I'm assuming something similar is going on with loading and unloading audio outs. the first time I assign audio outputs it takes forever if connected, but after that I think they pre-load before connected to PLAY.

Do you know if EastWest is addressing this issue at all? VSL's stance is that they can't do anything about it, but they sent copies of VePro to EastWest for testing. I'm stuck with a worthless slave computer until/unless this gets fixed.


----------



## EastWest Lurker (Aug 13, 2015)

Once again, I am seeing none of the problems you're describing with Cubase with Logic Pro (other than slow unload times) and I do indeed load my templates once a day.

Please email me a detailed description of the issue and perhaps a zipped m-frame with Play instances only and a zipped Cubase project and let me at least make sure that it is brought to their attention.


----------



## dtcomposer (Aug 13, 2015)

OK I'll do that shortly. It is certainly possible that Cubase is somehow the culprit, among other things. Thanks.


----------



## Daryl (Aug 13, 2015)

Jay, do remember that these guys are probably working with multiple MIDI ports, so you need to take that into account when you're troubleshooting.

D


----------



## EastWest Lurker (Aug 13, 2015)

Thanks Daryl but since I do not own Cubase, I will not personally be doing any troubleshooting.


----------



## dtcomposer (Aug 13, 2015)

Email Sent. Also yes, I am working with 48(x16) midi ports on each instance. I did experiment with less midi ports but saw no change. 

I realize you won't be working on this, but I do appreciate you sending the info along.


----------



## mbagalacomposer (Aug 13, 2015)

Are you running Kontakt and Play in the same VEP instance? 

I've had a lot of bad luck with that in the past and have since moved to keeping Kontakt and Play always in separate instances and the issue seems to have resolved itself.


----------



## dtcomposer (Aug 13, 2015)

Yeah, I remember reading some threads about that before buying, so I even went one step further and have Play and Kontakt on different computers, though not just because of that.


----------



## dtcomposer (Aug 14, 2015)

-Update-

So, things are moving along with the VSL tech support. It looks like some of the CPU issues relate to the amount of midi ports I was using. That is problematic in that I bought VePro to set up a large template.

*For other Cubase/Vepro users do you have an immediate cpu level other than 0% when connecting an instance with cubase?* Is this normal behavior? The lowest that I can get the Vepro CPU meter to read at the moment is 7% while sitting static in Cubase. Before connecting to cubase it is at 0%. That is for the Kontakt instance. I think that 7% might be workable as long as that 7% doesn't mean crazy spikes when actually playing back samples.

The Play instances are not going so well. I have not been able to load everything with under 80% CPU. Completely unusable, though just loading the hollywood series (minus percussion) in one instance I can get to 25% cpu. EW Support just got back to me, and I'm hoping we can figure something out.


----------



## Killiard (Aug 14, 2015)

As soon as I connect up all my instances of VEP (about 6) on my slave to Cubase I get anywhere between 7- 25% cpu levels in each VEP instance. All Kontakt. 

I don't have any play libraries so can't help there sorry.


----------



## brett (Aug 14, 2015)

There are a lot of variables and people experience different results with different setups

I run VEP on a 64GB Master and 24GB slave and have always experienced less severe versions of what you see: CPU bump on connecting, load unloading times. I also experience occasional hangs on disconnecting cubase.

My first thoughts were load distribution, number of midi ports, number of audio outs, multipliers, ASIO guard, hungry patches...

Is the high cpu spread evenly across all cores? Check in task manager. I've had problems in this regard where Audio apps / plugins aren't spreading the load evenly depending on the settings or way I've chosen to structure my template. For example, some people swear by minimizing their VEP instances but I've been having more luck having instruments (that don't share samples) spread across greater instances rather than fewer. Ymmv. Try switching off each instance of VEP (power button top left ) while watching CPU levels and you may find one instances has greater culpability and is hogging a single core. (As an aside, switching on CPU monitoring in Kontakt can help to track down troublesome patches)

One possible advantage spreading load across greater numbers on VEP instances is you may not have to activate as many ports or audio outs per instance. We're your figures 48 ports per instance? I've never gone above 10 here for what it's worth. 

How many cores per instance is VEP set to?

I have deactivated ASIO guard at the individual plugin level for all VSL plugs

I'm also surprised messing with the buffer multiplier doesn't ease the load. On that, certainly during playback, I've found some patches in kontakt perform better at higher multipliers than others so while I mostly operate at x1 (with a higher buffer in the host to keep CPU levels manageable) some instances are at x2 or x3 - not just due to audio crackle but due to cpu issues

Brett


----------



## dtcomposer (Aug 14, 2015)

Thanks these are some really helpful answers. Thanks especially for the ideas, Brett. I'm trying some of them out with the slave libraries and the results are already a little bit better. I'm going to keep testing, and post again once I see some better results.

The VEP cores have been set to everything from 1-6, but most recently I had them each using 2. I know that is what they say to do for 3 instances. I'm not sure how the core distribution is actually working though, because I got similar performance when setting the global CPU to 6 cores. I think with a little more help from the VSL guy, and my own tweaking I might be able to make this work. I was questioning my existence yesterday, so this is a positive step.


----------



## brett (Aug 14, 2015)

What about CPU load distribution across all cores in task manager / resource monitor? I still have one or more cores parked at rest but these wake up on play and all cores have a mostly even load which seems to be about right here.


----------



## dtcomposer (Aug 14, 2015)

Yeah it was similar. I had 6 cores active and 6 parked while at rest. They all seemed to handle about the same load in the monitor. I just played some unison stuff with all the most resource hungry legato patches for winds, brass, and strings (like 15 patches at once) and the 6 cores were still parked, but the meters for each instance never went over 30%. Maybe I'll need to push it more to really see it jump to all 12 cores?


----------



## kdm (Aug 14, 2015)

Let VEPro decide how to allocate cores instead of splitting. I think I have all 12 active on my i7 host, and all 6 on the slave i7 (will double check tomorrow - at one time I did reserve a core or 2). 

I'm running Nuendo 7 with VEPro on a 64G host and 2 VEP slaves. Everything is decoupled, but my slaves are running hardware I/O and MidiOverLan instead of VEP's streaming I/O. I don't see excessive disconnect times, but I won't say Cubase/Nuendo are fast per se. Load times aren't bad, but I'm using SSDs for all Play libraries (Hollywood Orch Diamond). 

Are you running the latest version of VEPro? There was an issue with long connect/disconnect times that was supposedly fixed in a recent update.


----------



## dtcomposer (Aug 14, 2015)

Yes I am running the latest version. I rolled back to PLAY 4.22 and made the other changes and I have seen some good improvement, but you are saying that the global setting should just be max threads (12, and 8 in my case)? I am running everything off of SSD's as well, but only strings, and percussion will be diamond. I'm going to try one more time with the latest PLAY update to see if I get improvement now that I have most of these VEP settings dialed in. I will try using max threads to see if that helps. 

The MidiOverLAn looks kind of intriguing to me, especially if it would free up resources. So you are just using VEPro to host your VI's then? Can you compare the efficiency of MOL vs VEP routing, or have you always used MOL?


----------



## EastWest Lurker (Aug 15, 2015)

Boy, all I can say is that Cubase must interact with VE Pro 5 _very_ differently than Logic Pro. When Logic Pro is idle it shows almost no CPU usage and I leave it set to two threads.


----------



## DR BOOWHO (Aug 15, 2015)

I have done a few tests on my setup and one thing I noticed was that "Antimalware Service Executable" seemed to be running as I was loading up Template, as in it was showing disk activity.. So I timed a fresh start and it took 
22.5 minutes to load up 50 gig of samples.

I then did another fresh start but this time I went into Admin tools....Task Scheduler....Task Schedular Library...Microsoft....Windows...Windows Defender... Then there are four Headers reading ...Windows Defender Cache Maintenance...Windows Defender Cleanup....Windows Defender Scheduled Scan.....Windows Defender Verification....You have to click on each one and uncheck "Run with Highest Privileges" and also under the "Conditions header uncheck any of the boxes in there.

Now Im not saying it will work for everyone who has slow loading times but as soon as I did this my Template loaded in 6mins and 18 secs the same 50GB template... So I hope this might be of use to someone
I tried it twice to make sure it wasn't a fluke


----------



## kdm (Aug 15, 2015)

dtcomposer said:


> Yes I am running the latest version. I rolled back to PLAY 4.22 and made the other changes and I have seen some good improvement, but you are saying that the global setting should just be max threads (12, and 8 in my case)? I am running everything off of SSD's as well, but only strings, and percussion will be diamond. I'm going to try one more time with the latest PLAY update to see if I get improvement now that I have most of these VEP settings dialed in. I will try using max threads to see if that helps.
> 
> The MidiOverLAn looks kind of intriguing to me, especially if it would free up resources. So you are just using VEPro to host your VI's then? Can you compare the efficiency of MOL vs VEP routing, or have you always used MOL?



If you are running one instance, VSL recommends using the maximum number of threads, but also says you might want to reserve one for the host app. For multiple instances, you divide the thread allocations down by instances (4 of 8 for 2 instances, 2 of 8 for 4 instances, etc).

I have it set to use the max number of threads on my slaves (one instance of VEPro each), and 2 threads each on my host. Turn multiprocessing on in Cubase (if not already on). Limit the number of audio ins/outs in VEPro to just what you need. There might be something else going on because I don't think any of these settings will necessarily change loading by as much as you are seeing - I would think 10-20% variation might be the most we would see on an i7.

I haven't tested VEPro's streaming in version 5. The last time I tried it (v4 a couple of years ago), I couldn't get a single stream to work without distorting (sounded like an audio sync problem, as ASIO/cpu loading was low). I took the hardware route for audio I/O with slaves a few years ago for the added reliability vs. relying on the LAN. 

MidiOverLan (or similar LAN midi app) is really the best way to run several midi ports for VEPro slaves, if you don't use VEP's streaming system. It works brilliantly. I have 80 ports available between two different MOL licenses, which is more than enough for a large template.


----------



## sinkd (Aug 15, 2015)

kdm said:


> MidiOverLan (or similar LAN midi app) is really the best way to run several midi ports for VEPro slaves, if you don't use VEP's streaming system. It works brilliantly. I have 80 ports available between two different MOL licenses, which is more than enough for a large template.



I used to use MOL before VEPro. Just curious why this could still be preferable to running all MIDI through VEPro?

DP user here. I have to disable something called Pre-Gen mode for plugins/VIs in DP in order for VEPro to run most efficiently with my two slave setup. Is there anything like that in Cubase? Might have already been covered.

DS


----------



## EastWest Lurker (Aug 15, 2015)

I don't know if this is helpful to Cubase users at all but here is what happens with Logic Pro and VE Pro with the Hollywood Orchestra on my slave PC. My large template takes 5:11 to load, 27 seconds to disconnect from Logic Pro, and 55 seconds to unload the Play instruments when quitting VE Pro. (Hardly, "glacierly slow".)

Also, here are 2 pics: the first with Logic Pro connected to the VE Pro templates on both the PC for Play and Kontakt for Mac but idle. The second is when I start Logic running without any regions playing through it, at a 256 audio buffer, 2 threads each for VE Pro instances.The only conclusion that I can reach is that while Cubase is a fine DAW and reportedly superior to Logic Pro in many areas, for the specific task of interaction with VE Pro, it clearly seems to be inferior to Logic Pro. Am I wrong?


----------



## scarred bunny (Aug 15, 2015)

I don't think you're wrong. Cubase and VEP aren't always in love with each other, it seems.

Many have reported problems with long connection times when using the VST3 version of VEP with a lot on midi ports enabled. I used to have a serious issue where it would freeze and take forever to connect to VEP (it might as well have just crashed) when hosting certain large Kontakt libraries, although this problem went away for me with a VEP update earlier this spring. I suspect these issues are related either to Cubase or the VST spec, since I never saw the same behavior with the AAX or MAS versions in ProTools or DP respectively. (I forget how the VST2.x plugin behaved in Cubase.)

For me, the key to optimizing performance in general was to split my instruments out across many small instances of VEP each hosting a single Kontakt (or whatever), and enabling the Asio Guard double buffering scheme. Which is where a lot of people run into problems, since Asio Guard and VEP don't seem to get along very well. For me the problems there went away by setting VEP's latency to 0 - all smooth sailing after that. But I use a single machine setup, and I have not yet heard of anyone having success with this method while using network streaming.

As for Play... I do get the same odd behavior where it takes a pretty long time to disconnect the VEP instance that's hosting it. I didn't actually time it, but it's in the range of a few seconds to disconnect an instance hosting a Kontakt, and a minute or more when hosting Play. Which can add up to a lot when using many instances. I did some quick testing after reading this thread, but I get the same behavior in both the VST2.x and VST3 versions of VEP, and regardless of the number of midi ports and audio outputs enabled. If there's a viable workaround, I didn't find it. (I don't use a ton of Play libraries at the moment, so it's not a deal breaker for me personally.)

'fraid I don't have any other clever ideas at the moment. :(


----------



## dtcomposer (Aug 15, 2015)

DR BOOWHO said:


> I have done a few tests on my setup and one thing I noticed was that "Antimalware Service Executable" seemed to be running as I was loading up Template, as in it was showing disk activity.. So I timed a fresh start and it took
> 22.5 minutes to load up 50 gig of samples.
> 
> I then did another fresh start but this time I went into Admin tools....Task Scheduler....Task Schedular Library...Microsoft....Windows...Windows Defender... Then there are four Headers reading ...Windows Defender Cache Maintenance...Windows Defender Cleanup....Windows Defender Scheduled Scan.....Windows Defender Verification....You have to click on each one and uncheck "Run with Highest Privileges" and also under the "Conditions header uncheck any of the boxes in there.
> ...



Wow. I couldn't find the file you were talking about in my scheduler, but I just uninstalled all the Microsoft security stuff, restarted my computer, and the samples are flying now. I didn't time it, but it seemed like about 5 min for 48 GB. Awesome tip as long as I don't get hacked. Thanks.


----------



## dtcomposer (Aug 15, 2015)

So I have to say that when I rolled back to Play 4.22 the audio port unloading issue, and slower save time went away very noticeably (It was suggested by EW support). I'm not saying everyone is going to have the issue with the newer version, since I'm sure many are not. But on my computer whatever interaction exists between Cubase, VePro, and the latest Play version is making it slow down. I'm just finishing up a report to Play Tech support, who wanted to know the results of my test. They had me just download 4.22 from the main download screen if anyone else feels like testing that particular issue. I didn't see a change in CPU usage from one version to another though.


----------



## dtcomposer (Aug 15, 2015)

kdm said:


> If you are running one instance, VSL recommends using the maximum number of threads, but also says you might want to reserve one for the host app. For multiple instances, you divide the thread allocations down by instances (4 of 8 for 2 instances, 2 of 8 for 4 instances, etc).
> 
> I have it set to use the max number of threads on my slaves (one instance of VEPro each), and 2 threads each on my host. Turn multiprocessing on in Cubase (if not already on). Limit the number of audio ins/outs in VEPro to just what you need. There might be something else going on because I don't think any of these settings will necessarily change loading by as much as you are seeing - I would think 10-20% variation might be the most we would see on an i7.
> 
> ...


OK Thanks. I didn't see a difference in CPU when I increased to max threads. But I am not using one large instance either. Originally that was my plan, but it was really slowing everything down. Once I get things up and running I'm going to try to build one large instance again, and I think I might also experiment with MOL if I'm not happy with my VEP performance.


----------



## DR BOOWHO (Aug 15, 2015)

dtcomposer said:


> Wow. I couldn't find the file you were talking about in my scheduler, but I just uninstalled all the Microsoft security stuff, restarted my computer, and the samples are flying now. I didn't time it, but it seemed like about 5 min for 48 GB. Awesome tip as long as I don't get hacked. Thanks.


Good to hear... You shouldn't have to remove any security as it shouldn't affect WINDOWS DEFENDER..It will still work but not slow up your operation....Its not a bad idea not letting your PC have access to the outside world if you can avoid it.Let me know if you need to change it back and I will post a few pics to hopefully help you find the link to the settings


----------



## kdm (Aug 15, 2015)

sinkd said:


> I used to use MOL before VEPro. Just curious why this could still be preferable to running all MIDI through VEPro?



VEP's midi ports are only accessible if you connect with it's audio streaming system. No way to run hardware I/O while running VEP's midi ports (last I tried it at least).


----------



## Guy Rowland (Aug 15, 2015)

I think that's a very hasty conclusion, Jay. There are clearly specifics with certain versions of Play for one thing, and we're generally in a state of flux with Cubase and VE Pro for another (this week Steinberg released a new SDK that should ultimately help VSL get things working smoother with Cubase using asioguard 2).

Perhaps more than either of those things, I find the meters in general behave very differently from app to app. I can use VE Pro with low asioguard in C8, and the meters are quite high at idle. But they change very little when under load. The real world performance is what counts. It could be that Logic does work better right now - I think Steinberg have work to do with C8 and efficiency - but you're a long way from demonstrating that.


----------



## Audio Birdi (Aug 15, 2015)

EastWest Lurker said:


> Boy, all I can say is that Cubase must interact with VE Pro 5 _very_ differently than Logic Pro. When Logic Pro is idle it shows almost no CPU usage and I leave it set to two threads.


Been playing with both recently, Logic's audio engine kind of switches off when it's idle, so no CPU usage is used at all by VEP / Logic Pro.

Cubase on the other hand, ends up having the audio engine always on, hence the CPU always being used, even when idle.

I've tried VEP with Ableton, Cubase, Logic, Reaper and Digital Performer.

It appears that Logic is the only one that essentially switches itself off when Idle.

This was done a couple of weeks ago.


----------



## EastWest Lurker (Aug 15, 2015)

Pleasse understand folks, that is no way am I engaged in a DAW war. All I am saying is that people here are reporting performance issues with Cubase and VE Pro 5 that I do not experience with Logic Pro X and VE Pro 5.

People can draw or _not_ draw any conclusions they like based on that.


----------



## samphony (Aug 16, 2015)

EastWest Lurker said:


> Boy, all I can say is that Cubase must interact with VE Pro 5 _very_ differently than Logic Pro. When Logic Pro is idle it shows almost no CPU usage and I leave it set to two threads.



Thanks to he AU implementation. When nothing is used (idle) the cores get released to do their OS tasks


----------



## Daryl (Aug 16, 2015)

samphony said:


> Thanks to he AU implementation. When nothing is used (idle) the cores get released to do their OS tasks


Or is that the process buffer in action? Who knows...!

D


----------



## sinkd (Aug 17, 2015)

kdm said:


> VEP's midi ports are only accessible if you connect with it's audio streaming system. No way to run hardware I/O while running VEP's midi ports (last I tried it at least).


Ah. Understood. Thanks.


----------



## kdm (Aug 17, 2015)

samphony said:


> Thanks to he AU implementation. When nothing is used (idle) the cores get released to do their OS tasks



Afaik Logic has always used a process buffer (separate from the audio buffer) that only activates a plugin's process when there is data present. It was this way in Logic 4 on PC, back when I was using Logic. I don't think it has anything to do with AU. It is Logic's own implementation. The downside, at the time (not now I assume), was lack of release tails (reverb) when playback stopped.

There could be issues with Cubase 8 and VEPro for some, and load times of coupled instances was one, but I thought a recent VEPro update addressed that.


----------



## Przemek K. (Aug 19, 2015)

DR BOOWHO said:


> I have done a few tests on my setup and one thing I noticed was that "Antimalware Service Executable" seemed to be running as I was loading up Template, as in it was showing disk activity.. So I timed a fresh start and it took
> 22.5 minutes to load up 50 gig of samples.
> 
> I then did another fresh start but this time I went into Admin tools....Task Scheduler....Task Schedular Library...Microsoft....Windows...Windows Defender... Then there are four Headers reading ...Windows Defender Cache Maintenance...Windows Defender Cleanup....Windows Defender Scheduled Scan.....Windows Defender Verification....You have to click on each one and uncheck "Run with Highest Privileges" and also under the "Conditions header uncheck any of the boxes in there.
> ...



Thanks for testing this. I tried a different approach though. I just disabled the scheduled scan task and the realtime scan directly in microsoft security essentials. What a pleasant surprise, my HO Diamond template ( 24 gigs) loaded in about 3 min compared to about 13 min when mse was active


----------



## IFM (Aug 19, 2015)

Well I just ordered C8P so will see how it interacts with my template on the slave PC which uses one instance per section.


----------



## dtcomposer (Aug 19, 2015)

Play is definitely working better for me with smaller instances, though my Kontakt libraries don't see a big difference either way. I haven't tested it yet with a really dense piece, but so far, even though it loads a bit high on CPU the meter doesn't seem to go up all that much while playing.

I'd just like to say thanks to everyone for helping out, and being so generous with knowledge and time.


----------



## JT3_Jon (Aug 19, 2015)

I'm sorry if this was already answered, but I've skimmed your posts and didn't see it. How may AUDIO RETURNS are you using in Cubase for your ve pro instances? To find in Cubase go to your VST instruments window and click the "Activate outputs" button (to the right of the instrument name). I believe by default it opens to just 1/2 but can accept up to 32 inputs if you click the "all outputs" button. In VE pro you can have all audio returning to cubase on just the master 1-2, or you can separate each instrument and have each going to a separate Audio returns to Cubase (which again you turn on in the "activate outputs" button in Cubase). I personally try to do as much mixing as possible directly in VE pro and have an instrument group return back into Cubase. For example, I try to keep all my string Long on one return, String Shorts on another, etc and not have all my individual patches/libraries returning to Cubase. If I need to add individual outputs for synths or instruments I want to process directly in Cubase using Cubase plugins, I try to spread them across Multiple VE pro's. For the audio returns I manually activate them as needed and never use the "all outputs" button in Cubase. 

I have been told that having too many audio returns to cubase can cause problems like you're describing. I believe this is true by just turning them on in Cubase, regardless of if you are actually using them in VE pro. So if by default you have all your VE pro's using 16 stereo audio returns in the VST, this could be the problem. Since Logic is limited to 16 MIDI channels per VE pro (which means you would never use more than 16 audio returns anyway) while Cubase can load multiple ports of 16 midi channels each, its possible in cubase to load your entire VE pro template in one instance and use all 32 audio inputs - which I personally thought was AWESOME until read where people were having problems when they had to use more audio inputs back into Cubase. I know you are not doing this, but perhaps you are loading all teh available audio returns by default? Perhaps this is the difference Jay is seeing as I believe he uses one VE pro instance per instrument section which would also cut down on audio returns? 

p.s. I run both Logic and Cubase regularly on my machines and have not noticed a difference in CPU usage between Logic and Cubase regarding VE pro. I have AISO guard OFF for Cubase and use 2 threads per instance, and tend to load about 6-8 separate instance of VE pro per machine. I actually ran a test a year or so ago where I loaded the exact same project (which was nearing maxing out my machine in Logic) in both Logic and Cubase using VE pro, and the performance was identical. This was on Cubase 7 though. 

Please keep us updated and hopefully you are able to find a solution.


----------



## dtcomposer (Aug 19, 2015)

Honestly, it might end up making more sense for me to just do all the mixing in VePro eventually. Originally, that was the plan, but I realized that I would have to buy an extra license for a bunch of my plugins after I had already blown the money for the slave. So I made the choice to just use Cubase for all effects. Maybe that is short-sighted, though.

I am loading unused audio outputs because my Kontakt instance uses 90 (45 pairs) where my play instances on the slave use 16-20 (8-10) per instance. I also just loaded the ones I needed for the play instances, after some traumatic "load all" experiences. Once I get my current template balanced, and stress tested I will try to split the Kontakt instance into several smaller, and see If I can take some of the mixing out of Cubase to reduce audio inputs further. I'll report back for posterity!

Thanks for another great suggestion.


----------



## DR BOOWHO (Aug 20, 2015)

Przemek K. said:


> Thanks for testing this. I tried a different approach though. I just disabled the scheduled scan task and the realtime scan directly in microsoft security essentials. What a pleasant surprise, my HO Diamond template ( 24 gigs) loaded in about 3 min compared to about 13 min when mse was active


I think Microsoft security is causing problems for quite a few people with issues on loading times,and it makes you wonder if it would be better disabling entirely it provided you can keep it off any internet connection.


----------



## Przemek K. (Aug 20, 2015)

DR BOOWHO said:


> I think Microsoft security is causing problems for quite a few people with issues on loading times,and it makes you wonder if it would be better disabling entirely it provided you can keep it off any internet connection.


Well, I disable the ethernet connection before I disable the realtime scan. Although it would be better to have something like a scripted launcher which you just click on it and it disables/enables both with one click. But I don't mind the extra step.


----------

