What's new

VEpro - Lots of instances vs Lots of Midi Channels

MoeWalsaad

Member
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.
 
Last edited:
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.
 
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.
 
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.
 
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?
 
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...
 
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.
 
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.
 
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?
 
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?
 
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.
 
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
 
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.
 
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
 
Last edited:
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
 
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.
 
Last edited:
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...
 
That's a separate question. i think trying to find one instance out of hundreds or thousands of instances would be a nightmare. ;)
 
Top Bottom