# VEpro - Lots of instances vs Lots of Midi Channels



## MoeWalsaad

Hello,
I'm halfway through building my first grand template on Vienna Ensemble Pro7 and Cubase10, but some concerns are arising.

I wonder what would be the ups and downs of having too many VEP instances vs too many Plugin Channels vs too many Midi channels coming from less Kontakt Instances.

*It's a big advantage to me to load so many instruments each in one Kontakt instance because this will give me the chance to enable and disable them when I need to save memory.*
but I don't know what would be the long term flaws and limits of this workflow.

While if one Kontakt instance was containing too many instruments in several midi and output channels, I wouldn't be able to disable just one instrument but rather the whole Kontakt instance, which means less freedom, but as I see from Youtube tutorials many composers are going with this method but I am not sure why.

Also what would be the ups and downs of having too many VEP instances, so you can enable and activate them whenever you need? most users on Youtube seems to be conservative at the number of VEP instances and I'm not sure why.

I would like to learn from your experiences because building a template takes forever, but I don't want to waste time on a system that doesn't work.

Thanks in advance.


----------



## Ashermusic

It depends on your DAW. I can only speak for Logic Pro. Historically Logic likes more instances with less in them and spread over two computers I have used over 80. One of my Logic clients had a separate slave computer for each section of the orchestra so he had what was then the maximum of 256 software instruments in Logic. However, AU 3 apparently is changing the calculus on this with Logic, according to Dewdman, and others. So it may come down to user preference.

Again, I cannot speak to other DAWs.


----------



## Ben

In general it is good to have as few VEP instances as possible. This allows VEP to distribute the load evenly between the CPU cores and the computer has not to handle with the overhead that comes with each instance.
Aside from this it is fine to have one Kontakt instance per instrument.


----------



## MoeWalsaad

Ashermusic said:


> It depends on your DAW. I can only speak for Logic Pro. Historically Logic likes more instances with less in them and spread over two computers I have used over 80. One of my Logic clients had a separate slave computer for each section of the orchestra so he had what was then the maximum of 256 software instruments in Logic. However, AU 3 apparently is changing the calculus on this with Logic, according to Dewdman, and others. So it may come down to user preference.
> 
> Again, I cannot speak to other DAWs.


Thanks Jay, interesting, but do you mean over 80 instances of VEpro or VST plugin instances?


I'm using Cubase, I don't seem to have any limits or problems so far with the (more midi outputs approach) except that I'm not liking it because there is less freedom with loading and unloading.

That's why I wish to learn more about how practical would it be if I go with (lots of plugin instances) and (lots of VEpro instances) approaches in Cubase.


----------



## MoeWalsaad

Ben said:


> In general it is good to have as few VEP instances as possible. This allows VEP to distribute the load evenly between the CPU cores and the computer has not to handle with the overhead that comes with each instance.
> Aside from this it is fine to have one Kontakt instance per instrument.



Interesting, thanks, I'm using Cubase, so any idea if it can handle lots of Kontakt instances coming from VEpro?


----------



## Dewdman42

Ben said:


> In general it is good to have as few VEP instances as possible. This allows VEP to distribute the load evenly between the CPU cores and the computer has not to handle with the overhead that comes with each instance.
> Aside from this it is fine to have one Kontakt instance per instrument.



VEP does a very good job of distributing load across cores. VEP has one parameter that is a little troublesome which is the setting about number of cores per instance. The problem is that if you are running a few instances, then you may not be able to set that setting optimally. If you are running only a single VEP instance, then its easy, you set that setting to something big, like maybe the number of cores-2 or something, or maybe its 2x-2, I can't remember now. But anway, used that way, VEP will take advantages of as many cores as it can and its very good at it. 

Alternatively, if you use one instance per instrument, then you would set that parameter to 1 or 2. Each instance would be handling only a single channel and would only need 1 core, leaving the other cores for other instances. That doesn't spread the load around with one track playing, but it does with 20 tracks playing...

If you have let's say 4 instances, then what do you set that VEP setting to? At first we'd say set it to the number of cores/4. But when if at a certain moment in time, only two of the instances are playing stuff and the other two instances are idle? Then VEP would be underutilizing cores.

In general, a single VEP instance is best in terms of always having as many cores as possible for VEP to use and spread the load while its playing, regardless of how many tracks happen to be playing...


----------



## reddognoyz

I use DP and it's happier with less instances of VEP. I have a Visiondaw slave and I have 38 VI's, mostly instances of kontakt, in VEP, Most of the the Kontakt with over 10 instruments. running splits and separate reverb sends per stem, maybe 60 audio tracks? All in one instance...with room to grow.


----------



## Ben

Dewdman42 said:


> what do you set that VEP [thread-] setting to


It depends on your setup. Each VEP instance needs some CPU cycles of overhead, even if no instrument is triggered inside the instance. The less instances the less CPU cycles you throw away. Inside an instance VEP can manage the load and decide how to ditribute the load to the cores. But an instance does not know what the laod of an other instance is. So in worst case scenaria you have all the heavy instances on one core while the other cores have almost nothing to do.
I have a 6 core CPU and set the VEP thread count to 4, and it works fine for me. I have ~6 instances.


----------



## givemenoughrope

VST Expression maps in Cubase + Flexrouter in Kontakt = lots of options and 64 midi channels in one instance of Kontakt...


----------



## Dewdman42

Ben said:


> It depends on your setup. Each VEP instance needs some CPU cycles of overhead, even if no instrument is triggered inside the instance. The less instances the less CPU cycles you throw away. Inside an instance VEP can manage the load and decide how to ditribute the load to the cores. But an instance does not know what the laod of an other instance is. So in worst case scenaria you have all the heavy instances on one core while the other cores have almost nothing to do.
> I have a 6 core CPU and set the VEP thread count to 4, and it works fine for me. I have ~6 instances.



exactly ben but its still the same if you have two instances, then do you change that setting to 2? And what if one instance happens to be idle at some point during playback?


----------



## JonS

Ben said:


> It depends on your setup. Each VEP instance needs some CPU cycles of overhead, even if no instrument is triggered inside the instance. The less instances the less CPU cycles you throw away. Inside an instance VEP can manage the load and decide how to ditribute the load to the cores. But an instance does not know what the laod of an other instance is. So in worst case scenaria you have all the heavy instances on one core while the other cores have almost nothing to do.
> I have a 6 core CPU and set the VEP thread count to 4, and it works fine for me. I have ~6 instances.


Does it ever make sense to assign more threads to each instance than one has total ie. 8-core with 16 threads 🧵 and 4 VEPro Instances each with 6 threads instead of 4? This way if one Instance is not being used the others have access to more CPU juice 🧃 

Or would you never assign more threads to an Instance than the Mac can a lot?


----------



## Ashermusic

Ben said:


> In general it is good to have as few VEP instances as possible. This allows VEP to distribute the load evenly between the CPU cores and the computer has not to handle with the overhead that comes with each instance.
> Aside from this it is fine to have one Kontakt instance per instrument.



Not with Logic Pro, in my experience. I used to have 1 instance of each instrument of the Hollywood Orchestra Diamond in VE Pro on my slave PC and it ran like butter.


----------



## ptram

I wonder if it is the same in the Mac and the PC. Also, maybe Logic is taking priority over Vienna Ensemble, and be the one to distribute threads.

Paolo


----------



## Dewdman42

My view is that the two extremes are best. EITHER use one single instance in vepro, or use many instances (at least as many as the number of cores). The first method distributes load through vepro intelligence, the second method distributes load through OS intelligence.

if you are in between with 2 or a few instances then it’s possible that core load may not be evenly distributed in some cases but in reality as long as all the instances are active and busy then it would not matter there either.

having a single instance is really the most ideal in theory because then vepro itself is using less resources. Internally each vepro instance is like a seperate running server. Each server requires resources.


----------



## ptram

Dewdman42 said:


> having a single instance is really the most ideal in theory because then vepro itself is using less resources.


However, having separate instances is great for organization. It's much easier to jump to the desired group, and manage each groups separately as sub-projects you can load separately.

Paolo


----------



## Dewdman42

I was speaking only in terms of multithreading performance. There very well may be workflow considerations thst are worth a slight compromise in performance.

another way to improve performance would be to use less plugins. But we use whatever plugins we want to use to get the sound we want As long as the cpu doesn’t overload. Workflow is different for everyone and that’s what the computer exists for


----------



## dadadave

JonS said:


> Does it ever make sense to assign more threads to each instance than one has total ie. 8-core with 16 threads 🧵 and 4 VEPro Instances each with 6 threads instead of 4? This way if one Instance is not being used the others have access to more CPU juice 🧃
> 
> Or would you never assign more threads to an Instance than the Mac can a lot?




I have been wondering about this, as well. What happens when multiple instances try to use more threads in total than are available? 

Edit: Ben's old post seems to suggest that's a workable approach, but it makes me wonder what the point is of assigning threads to VEP instances in the first place.


----------



## Dewdman42

You can't really run out of threads, practically speaking...I mean there is some upper limit but its not the same limit as your number of cores. Your system always has more threads running then the number of cores. But what happens is that if you have too many threads all trying to work at the same time, they are taking turns on the cores..and if you have too many of them taking turns all at the same time...the contention creates more overhead which isn't always good. The contention for resources can grind the system down...

I think the thread per instance strategy is ok, but it just depends on how you use it and there are ways to use that strategy where you could either end up slamming your system with too many threads at once, or you could go the other way and not have enough threads.. So don't use it that way!

Some kind of dynamic thread balancing strategy across instances would be interesting, but really what I think would benefit everyone the most, if VSL is listening..is if they could figure out a way to make a single instance use more than 768 midi channels. I for one, would love it if we could connect to a single instance from multiple VePro plugins....using thousands of total midi channels...but all entering into one single VePro instance, where thread allocation would be best managed within that single instance.

In the above, for example, then we could use one track per instrument in LogicPro...no more multi-timbral shenanigans... specify the "port" in the plugin....and route all the midi channels you want into a single VePro instance...then just configure the threading simply and let VePro manage it all. There very well could be technical reasons why that can't be done though...so just dreaming out loud...


----------



## Ashermusic

I think trying to find anything in that massive single instance would be a nightmare.


----------



## Dewdman42

That's a separate question. i think trying to find one instance out of hundreds or thousands of instances would be a nightmare.


----------



## dadadave

Dewdman42 said:


> You can't really run out of threads, practically speaking...I mean there is some upper limit but its not the same limit as your number of cores. Your system always has more threads running then the number of cores. But what happens is that if you have too many threads all trying to work at the same time, they are taking turns on the cores..and if you have too many of them taking turns all at the same time...the contention creates more overhead which isn't always good. The contention for resources can grind the system down...



I figured that was the case, but then what is the point of setting a thread limit per instance? If you set a low limit and the instance is doing a lot, you run into trouble. If you set a high number and there's no other downside to it than the case where all instances together actually demand more threads than are available (a situation would mean trouble in any case), why would you ever set a low threat count limit per instance?


----------



## Ashermusic

Dewdman42 said:


> That's a separate question. i think trying to find one instance out of hundreds or thousands of instances would be a nightmare.



Not with the Raise feature added in VE Pro 7.


----------



## JonS

Ashermusic said:


> I think trying to find anything in that massive single instance would be a nightmare.


When you record enable a track in DP it automatically brings up that corresponding track in the sidebar mixer in VEPro 7, so that is not an issue at all.


----------



## Ashermusic

JonS said:


> When you record enable a track in DP it automatically brings up that corresponding track in the sidebar mixer in VEPro 7, so that is not an issue at all.



Ah, then that’s a nice feature in DP that I wish we had in Logic.


----------



## Dewdman42

dadadave said:


> I figured that was the case, but then what is the point of setting a thread limit per instance? If you set a low limit and the instance is doing a lot, you run into trouble. If you set a high number and there's no other downside to it than the case where all instances together actually demand more threads than are available (a situation would mean trouble in any case), why would you ever set a low threat count limit per instance?



The reason its per instance has more to do with the fact that each instance is a separate isolated running server that runs in its own process space...there are technical reasons why this is very common in server oriented software...which is basically what VePro is. Its not impossible to unify separate servers into some kind of unified and globally managed thing, but ends up being monumentally more complex from a software design perspective and perhaps even compromises performance in some ways.

In any case, that is how VePro appears to be architected...each instance is for all intents and purposes its own running copy of VePro...completely separated from the others, except for the fact that the GUI presents them in all in one GUI for you to see them all together, internally they are completely separate running entities...that is just how its architected....

again.... If you have one instance with a large number of threads..its not a harm if those threads are sitting idle. They do not hurt your system. So one instance with 16 threads, no problem. VePro will manage the threads to best fit the channels you have and balance them out in the best way for processing plugins on channels

If you have a few instances, then its a challenge to know what to set it to. if you set it to 16 threads each, then again..as long as you don't have all of those instances all going full tilt at the same time..it won't be a problem...in other words, if you have 4 instances with 16 threads each, but at any given moment they are each only using 4 of their 16 threads, then the system will handle it just fine. See what I mean?

The problem is if they all go full tilt at the same time...then you'd have 64 threads hitting the system at once...and that could grind your system down potentially. You can avoid that in how you manage your tracks in the various instances.

The alternative would be to turn down the thread setting.. Ok, so let's say you turned them down to 4 threads each, so there is no more than 16 threads total. Ok... but if you hit a section of music where 3 instances are idle and one instance is playing back 25 tracks at once...that one busy instance would only have 4 threads to work with and would be under utilizing your 8 core machine...probably.

So... How you set the threads depends on your project and how you spread the tracks around. If you keep all 4 instances evenly playing the same number of tracks at all times, then a 4-thread setting would make sense...but if tends to be all notes from instance1 for a while then all notes from instance2 for a while, etc..then it would be better to allocate 16 threads per instance, and only 16 threads would ever really be active at any given time because of the way your tracks and music is laid out.

See what I mean.

if that seems too complicated, then just stick with either one mondo instance with lots of threads (probably 2x your core count), or else go with one instance per instrument, with 1-2 threads per instance. In the latter case the OS will automatically balance the load, in the prior, VePro will balance the load.


----------



## Dewdman42

JonS said:


> When you record enable a track in DP it automatically brings up that corresponding track in the sidebar mixer in VEPro 7, so that is not an issue at all.



Hmm, interesting, have to look at AU3 to see if that happens. Is that a feature of the MAS version of the VePro plugin perhaps?


----------



## JonS

Ashermusic said:


> Ah, then that’s a nice feature in DP that I wish we had in Logic.


I think its a preference setting inside VEPro actually. Turn on MIDI Activity Focus and just play a couple of notes in Logic or just Solo a track in Logic, Jay.


----------



## Dewdman42

Ashermusic said:


> Not with the Raise feature added in VE Pro 7.



I'll admit I need to explore more this mode of operation with only one instrument per instance. for me, that defeats much of the usefulness of VePro to the point that I would probably just stop using it altogether, at that point I could just as well put each instrument directly in LogicPro. I use VePro to submix channels in various capacities and particularly handling MirPro in there, etc. A lot of that usefulness of VePro is lost when using only one instance per instrument. I do think this mode eliminates any concerns about core balancing. It also eliminates all the horrendous multi-timbral shenanigans in LogicPro and provides also for me the ability to put much simpler scripter scripts on each channel, each one handling just one single instrument. So I definitely see the advantages, but there are disadvantages too...and for me...I think I would probably just probably avoid using VePro altogether if I changed over to that mode of operation. It could be still be useful basically only for the sake of keeping an orchestra loaded and able to switch between DAW projects without having to reload samples. And it could be useful for using a server farm too, which I'm not. But many other useful advantages of VePro are not utilized in that mode.


----------



## jiten

Interesting discussion. I wonder if there are any Cubase users here who can share their findings (if any) RE fewer instances vs lots of instances, specifically in relation to Asio Guard. As I understand Asio Guard in Cubase, an entire VSTi is brought into 'live' mode at your buffer setting when its armed, and all other (playback only) tracks receive a slightly larger buffer to alleviate real-time computing pressure, thus squeezing more performance out of the system.

With this sort of behavior, it technically makes more sense to run lots of VEP instances to get maximum Asio Guard benefit, even though it may mean more overhead from each instance. With one giant instance, as soon as you arm any track, the entire template will basically be brought into 'live'/low-latency mode and stress real-time computing resources, and there would be no performance benefit from Asio Guard. I've also noticed that long-standing issue with playback gaps in Cubase/VEP/Asio Guard when selecting or deselecting tracks is better when using many, smaller instances. I haven't personally done any performance tests for this, but very curious to know if someone else has.


----------



## Dewdman42

VSL generally advises to disable ASIO guard, FWIW.


----------



## Ben

Dewdman42 said:


> VSL generally advises to disable ASIO guard, FWIW.


For all VEP plugins, especially when using the Audio Input plugin.
It can be de-activated in Cubase' Plugin-Manager.


----------



## jiten

Dewdman42 said:


> VSL generally advises to disable ASIO guard, FWIW.





Ben said:


> For all VEP plugins, especially when using the Audio Input plugin.
> It can be de-activated in Cubase' Plugin-Manager.



Yeah, I did see that. Personally, I've kept it on the "low" setting without problems. I am also not using the Audio Input plugin. Maybe a question for you @Ben, but out of curiousity, is the advice for keeping AG off based on performance tests with/without AG at various settings and various number of instances?

From what I remember the last time I looked into this, using the normal/high settings resulted in more disruptive playback interruption, but I also recall it not being that bad if the instances were really small (as in 1-2 instruments loaded per instance). It's been awhile since I've checked though, and should probably just do my own testing to figure out if one way works better or not.


----------



## Ben

jiten said:


> is the advice for keeping AG off based on performance tests with/without AG at various settings and various number of instances?


Not based on performance measures, but on all kinds of issues when ASIO Guard is enabled for VEP plugins. You don't have to disable it completly, but only for all VEP plugins in the Plugin-Manager.
We had (and still have) so many issues reported in support that were solved by simply deactivating ASIO Guard.


----------



## JonS

Ben said:


> Not based on performance measures, but on all kinds of issues when ASIO Guard is enabled for VEP plugins. You don't have to disable it completly, but only for all VEP plugins in the Plugin-Manager.
> We had (and still have) so many issues reported in support that were solved by simply deactivating ASIO Guard.


Ben, is there a definitive answer to the maximum number of threads per instance based on the total amount of threads of one’s computer or can you set VEPro instances to more threads than your computer has in its capability?


----------



## Dewdman42

Plus it should be pointed out that all ASIO guard really does is add some extra internal latency to pre process instrument tracks as much ahead of time as usual. Logicpro does that as the default case always. But in the case of VePro, VePro is adding its own large buffer of extra latency..in effect...VePro is already providing the same benefit as ASIO guard. so you don't really need it on for the VePro tracks.


----------



## Dewdman42

JonS said:


> Ben, is there a definitive answer to the maximum number of threads per instance based on the total amount of threads of one’s computer or can you set VEPro instances to more threads than your computer has in its capability?



Your computer doesn't have a total number of _*threads*_, it has a total number of _*cores*_.

Carry on...


----------



## jiten

Dewdman42 said:


> Plus it should be pointed out that all ASIO guard really does is add some extra internal latency to pre process instrument tracks as much ahead of time as usual. Logicpro does that as the default case always. But in the case of VePro, VePro is adding its own large buffer of extra latency..in effect...VePro is already providing the same benefit as ASIO guard. so you don't really need it on for the VePro tracks.



That's a good point too, I'm just going to go ahead disable it for VEP as recommended


----------



## Ben

JonS said:


> Ben, is there a definitive answer to the maximum number of threads per instance based on the total amount of threads of one’s computer or can you set VEPro instances to more threads than your computer has in its capability?


At some point there will be a hard limit by the OS, but before that your system will be probably completely unresponsive. When increasing the number of threads you will reach a point where adding more threads will hurt performance. Because of the amount of combinations of hardware, OS and OS versions (and not to forget your project size, workflow and habits), it is impossible to give perfect instructions what settings are best for you (in this case we would do that in the background and not make accessable in the settings).

My recommendation from my experience: 
- Each instance should get at least 2 threads (especially if you are using one player instance per VEP instance; please don't, you give me nightmares )
- If you use more then 2-3 VEP instances, don't set the thread count to the max value.
- If you have hyperthreading enabled and use multiple VEP instances, you probably should not go over the physical core count

I mostly have 5-7 VEP instances and at the moment 6 Cores without Hyperthreading. My thread-count is set to 4.


----------



## JonS

Ben said:


> At some point there will be a hard limit by the OS, but before that your system will be probably completely unresponsive. When increasing the number of threads you will reach a point where adding more threads will hurt performance. Because of the amount of combinations of hardware, OS and OS versions (and not to forget your project size, workflow and habits), it is impossible to give perfect instructions what settings are best for you (in this case we would do that in the background and not make accessable in the settings).
> 
> My recommendation from my experience:
> - Each instance should get at least 2 threads (especially if you are using one player instance per VEP instance; please don't, you give me nightmares )
> - If you use more then 2-3 VEP instances, don't set the thread count to the max value.
> - If you have hyperthreading enabled and use multiple VEP instances, you probably should not go over the physical core count
> 
> I mostly have 5-7 VEP instances and at the moment 6 Cores without Hyperthreading. My thread-count is set to 4.


So to make sure I understand you correctly, the maximum physical thread count you have is 12 threads, but you assign 4 threads to say 5 instances which is a maximum of 20 threads at once even though your computer only technically has 12 thread capability. Is that right?


----------



## Dewdman42

The above is very sound advice from Ben!

Just want to comment slightly on the following:



Ben said:


> At some point there will be a hard limit by the OS, but before that your system will be probably completely unresponsive.



The limit on MacOS and linux is in the thousands of threads per process. In other words, its not a relevant limit. As Ben said, your system would grind to a halt WAAAAY before hitting the limit on how many threads VePro is able to spawn.




> My recommendation from my experience:
> - Each instance should get at least 2 threads (especially if you are using one player instance per VEP instance; please don't, you give me nightmares )
> - If you use more then 2-3 VEP instances, don't set the thread count to the max value.
> - If you have hyperthreading enabled and use multiple VEP instances, you probably should not go over the physical core count
> 
> I mostly have 5-7 VEP instances and at the moment 6 Cores without Hyperthreading. My thread-count is set to 4.



In theory there is no harm in attempting to set the number of threads per instance higher to see what happens, but basically if you have 20 threads waiting in line to use 6 cores...it is not gaining any advantage...and adding more threads does add software overhead. That's the catch. There can still be advantage perhaps to having a few extra threads beyond the physical core count, but just be advised that if you slam all the threads at once, the system could hit that thread thrashing overhead and be worse then if you had less threads. At other times, the extra threads might be advantageous....and it really depends on the musical project the way tracks are layed out into instances and how the music focuses on this instance or that instance during different sections of music.

But I think the general advice Ben gave above is very sound...set it and forget it kind of setting..and don't lose a lot of sleep over it.


----------



## Dewdman42

JonS said:


> So to make sure I understand you correctly, the maximum physical thread count you have is 12 threads, but you assign 4 threads to say 5 instances which is a maximum of 20 threads at once even though your computer only technically has 12 thread capability. Is that right?



You don't have physical threads. Threads are a software thing. The max is in the thousands. You have physical cores!

at any moment in time your computer has dozens of threads across multiple processes and programs that are all sharing time with your 12 physical cores.


----------



## Ben

JonS said:


> So to make sure I understand you correctly, the maximum physical thread count you have is 12 threads, but you assign 4 threads to say 5 instances which is a maximum of 20 threads at once even though your computer only technically has 12 thread capability. Is that right?


I have only 6 parallel threads (-> no hyperthreading).

Yes, I don't want to say it is the perfect setting, I have not tried many other alternatives, but it works for me, and as long as it works I work with it


----------



## Dewdman42

You said 5-7 instances at 4 threads each which is as many as 28 total threads. If all 7 instances are playing at least 4 channels at the same time then all 28 threads would be active too


----------



## Ben

Dewdman42 said:


> If all 7 instances are playing at least 4 channels at the same time then all 28 threads would be active too


Most of the time not happening. And even if it does fo a while it works for me at the moment.

Also keep in mind that nowadays most of the time when I use VEP I'm reproducing a bug or testing a feature. For this I have 1-3 instances.


----------



## dadadave

Dewdman42 said:


> If you have a few instances, then its a challenge to know what to set it to. if you set it to 16 threads each, then again..as long as you don't have all of those instances all going full tilt at the same time..it won't be a problem...in other words, if you have 4 instances with 16 threads each, but at any given moment they are each only using 4 of their 16 threads, then the system will handle it just fine. See what I mean?
> 
> The problem is if they all go full tilt at the same time...then you'd have 64 threads hitting the system at once...and that could grind your system down potentially. You can avoid that in how you manage your tracks in the various instances.
> 
> [...]



First of all, thank you (and Ben) for taking the time to explain at length, I appreciate it! 

I think the part that I (still) don't quite get is what the downside is of using a small number of instances (let's say 4, one per orchestral section) and giving each a high max thread limit. Here are my assumptions, maybe you can point out what I'm missing:

-it seems like setting a high max thread count for an instance doesn't do any harm if they're not being utilized

-if an instance is very busy and could use more threads, but it's capped, while other instances are sitting idly, that underutilizes the available cores (so there's a potential downside to setting max threads conservatively)

-if a project is firing on all cylinders, so to speak, and using lots of threads on ALL instances at the same time, that can will a problem, regardless of how those threads are spread among the instances and how many instances they are. (*maybe this is the key point I get wrong?*)

Basically: will a single instance with a thread limit of 16 deal with a musical part that asks for 64 threads in a better way than 4 instances with a thread limit of 16 each? (maybe that's not how thread-creation works in the first place)




Ben said:


> - If you use more then 2-3 VEP instances, don't set the thread count to the max value.
> - If you have hyperthreading enabled and use multiple VEP instances, you probably should not go over the physical core count



oh, right, hyperthreading, that feels to me like yet another knob with no labels on the black box that this whole thing is. 


Lol, maybe I shouldn't worry too much, just go ahead building my template and deal with performance issues when they arise (I went with 4 instances for now, that seemed like it offered a balance of sufficient midi inputs and keeping instance number low as recommended in the manual)


----------



## Ben

dadadave said:


> oh, right, hyperthreading, that feels to me like yet another knob with no labels on the black box that this whole thing is.


Simplyfied: It's just some additional wires, so some CPU operations can process two data-sets at the same time.



dadadave said:


> Lol, maybe I shouldn't worry too much, just go ahead building my template and deal with performance issues when they arise


Exactly. Always better then over-optimizing something that did not need optimizations in the first place.


----------



## Synetos

So...I run Windows 10, Cubase, with or without VEP on a 7980XE. I alternate between running everything on one machine, or running my DAW on a 5960x, and VEP on the 7980XE. I have found hyperthreading to improve CPU performance by about 10-15%, when I monitor with task manager/performance monitor.

I struggle more with trying to get a workflow that feels creative using VEP. I have tried one large single instance, but found it hard to navigate...even with folders setup. I have tried lots of instances, even using "disabled Track approach". All approaches seem to work, and they all have pros and cons.

What i mostly strive for is to have low RT latency. I have my setup running at 64 samples which gives me ~5ms RTL. That is where I start. I want a responsive, real-time setup.

What I wish was available in VEP would be settings that are specific to each instance...like # of audio IN/OUT/MIDI channels, and how many threads (Cores) are assigned to that particular instance.

For example: My XLN Drum kits benefit from 14 stereo returns. But my pianos instance could all share 1 stereo return. I only need audio inputs on my FX instance, not the other 5 instances in my setup.. 

One size fits all for every instance, seems to waste resources if VEP is "setting up" those I/O routings behind the scenes...even if I dont enable them in Cubase. 

I don't do orchestral mock ups, so I have no need for 1000's of midi channels. I cant stand seeing all that in Cubase...even if I can hide them. Makes for a huge titanic like template.

I tend to play in my parts for VST one at a time, so I probably could really get by without using VEP. I just like to have everything at my fingertips.


----------



## Dewdman42

@dadadave, if you have an 8 core machine there is very little or no value to having more then 16 threads firing at the same time because 16 threads have to wait in queue to take their turn using time in the 8 cores. See what I mean? 64 threads won’t gain you anything and at some point the overhead of having so many threads will slow you down! The challenge is trying to figure out the best configuration so that depending on how you are using your instances it will work out to roughly 8-16 active threads. As you noted if you end up with only 4 active threads while one instance is working hard then the cores will be underutilized. If you end up with 64 active threads then there is a possibility that the overhead associated with 64 threads competing for resources will grind down the cpu. You have to balance those extremes.

ben have some very good middle of the road reccomendations that can keep you out of trouble.

i happen to think that many systems can handle more threads at times then one or two per core but It depends on si many factors. That’s why it doesn’t hurt to experiment. Most people want a set it and forget it setting, which is what Vsl and Ben have already provided, which should be fine honestly and don’t lose sleep over it.


----------



## reddognoyz

Ashermusic said:


> Not with Logic Pro, in my experience. I used to have 1 instance of each instrument of the Hollywood Orchestra Diamond in VE Pro on my slave PC and it ran like butter.



I have my template set up in DP in as few instances as possible. My assistant, who uses logic ,has the same template set up as Jay suggests. Jay helped us set that up and indeed Logic is much happier that way.


----------



## ptram

Dewdman42 said:


> i think trying to find one instance out of hundreds or thousands of instances would be a nightmare.



I think to have found a balance by using around fifty instances, sorted as in the traditional orchestral order, and shown in a vertical column in the VE server project. I find it to be very fast.

Paolo


----------



## ptram

Dewdman42 said:


> I use VePro to submix channels in various capacities and particularly handling MirPro in there, etc.


You can use MIR as a plugin in VEPRO, sending all the channels in all the instances to a separate MIR window. So, you can choose to have a single interface for mixing everything on stage, or the separate MIR pages in the instances to sub-mix them.

Paolo


----------



## thomasjdev

ptram said:


> You can use MIR as a plugin in VEPRO, sending all the channels in all the instances to a separate MIR window. So, you can choose to have a single interface for mixing everything on stage, or the separate MIR pages in the instances to sub-mix them.
> 
> Paolo


Do you mean that you have each of the instances all sharing a single Mir Pro instance? I thought each instance in VEP was independent? How do you set that up?

I was experimenting with adding a send on each of the group tracks I have in Cubase to a VEP Input Bus instance and then using a dedicated MIR instance with a bus for each send coming in. It worked but felt like there should be a better way to handle this I'm just not thinking about.


----------



## thomasjdev

I think I found the answer. 
Unchecking the box for Disable AU Mir Plugins lets you add MIR as a regular FX plugin (VST or AU) and send all those to the dedicated MIR Pro instance running outside of VEP Pro.


----------



## ptram

thomasjdev said:


> Do you mean that you have each of the instances all sharing a single Mir Pro instance? I thought each instance in VEP was independent? How do you set that up?


As far as I remember, I sent multiple instruments, for example Flute 1 and Flute 2, to a "Flute" bus. From there, I sent the signal to MIR, where they were processed by the Flute Ensemble icon.

Paolo


----------



## Collywobbles

Quick question for anyone still following this _thread_: If I set my Default Thread Count to 4, will this apply to instances made before I changed the setting, or will those still be limited to whatever the setting was on when they were created?


----------



## Ben

Collywobbles said:


> Quick question for anyone still following this _thread_: If I set my Default Thread Count to 4, will this apply to instances made before I changed the setting, or will those still be limited to whatever the setting was on when they were created?


It should change the default of all instances, including previously loaded ones, to 4. But you can overwrite the thread count per project here:


----------



## Collywobbles

Ben said:


> It should change the default of all instances, including previously loaded ones, to 4. But you can overwrite the thread count per project here:


Awesome, thank you very much Ben!


----------



## LeeThompson

Hi Guys

I wonder if you could give me some personal recommendations about which way to go with VE 7.
I’m new to orchestral stuff but have been using tech for music for years, including VE.

My system is a Mac Mini 3.2 gig 6 core i7 with 64 gig RAM on Catalina using Logic Pro.

I want to offload Abbey Road, BBCSO, Hollywood Orchestra and Spitfire Chamber Strings from native in Logic to VE Pro using key switching to change articulations.

At the moment I have it running using 10 instances of VE Pro - 3 x Woods, Brass, Strings + Chamber Strings - using the standard AU plug in with its 16 midi channels.

I could try and put them all in one instance by using the AU3 plug in which may make it a better ‘server’ scenario.

I’ve read various posts, but it seems
a) there’s debate about the AU3 plug in not being quite there
b) the issues with VE Pro using multiple instances making it less efficient ?

What would be the best option with this particular Mac set up.

Should I stick with the 10 instances or get into one using AU3 ???

(BTW I’m a basic hobbies user not a power guy writing scripting into my template etc)

Thanks for your help
Lee


----------



## ProfoundSilence

I was trying to use an instance per instrument, but I hit a brick wall where it would just straight up freeze and not load any instruments. 

Kind of sucks because I can't use ports, the event input plug-in adds and absurd amount of latency


----------



## Dewdman42

LeeThompson said:


> Should I stick with the 10 instances or get into one using AU3 ???
> 
> (BTW I’m a basic hobbies user not a power guy writing scripting into my template etc)
> 
> Thanks for your help
> Lee



Try it out all three ways and decide for yourself. AU3 mostly works fine unless you have tempo sync'd instruments. Those can't use AU3. Single instance per instrument is not the most efficient, but has many operational advantages...and is definitely the most simple way to go.


----------



## storyteller

ProfoundSilence said:


> I was trying to use an instance per instrument, but I hit a brick wall where it would just straight up freeze and not load any instruments.
> 
> Kind of sucks because I can't use ports, the event input plug-in adds and absurd amount of latency


How many instances were you at? I’m currently attempting this method and have been building numerous small “server projects” for each library as I go so that I can ultimately combine them in a master template on each vepro server. But I’m sort of flying blind to how many instances it will handle... haven’t reached a point to put it through the paces yet.


----------

