What's new

VE Pro 5 - high CPU usage on one thread

Near Decision

New Member
While turning another PC into a VE Pro slave machine, I've noticed that I have peculiarly high CPU usage on one thread, even when no instances are actually connected to the master.

System Specs
  • 12-core/24-thread Intel Xeon CPU
  • 48GB RAM
  • 2x SSDs (1 OS drive; 1 samples drive)

Here's the scenario...

- I've amassed 99 instances in VE Pro, with only a single track/plugin in each one.
- VE Pro is configured to use only a couple audio/MIDI ports per instance.
- This exclusively uses PLAY libraries, though the only demanding patches are from four instances of Symphonic Choirs. The rest are extremely lightweight instrument/percussion patches.
- The high CPU usage means that the VE Pro interface is extremely sluggish, and in some cases, downright unresponsive.

I've set up VE Pro with the following settings:


At idle, this is the CPU usage...
(Again, no instances are connected yet)


Alternatives I've tried (individually, and in combination)...

* Consolidated several instances into one
- This has a net zero effect on CPU usage

* Allowed VE Pro to use 4..12..16 threads per instance
- This has a virtually insignificant effect on overall CPU usage

* Connected to several VE Pro instances from master
- CPU usage remained steady, and after a while increased (as generally expected)

It looks like I've got 99 (instance) problems... and available resources ain't one of 'em.

I'd love to know if anyone has any strategies or tips on how to deal with this situation -- or if I'm just completely off my rocker with trying to have that many instances loaded at once. :P

Cheers all!

- Justin


dealt with this recently again as well...

u can load up all of those instances in VEPro, as u see that is not a problem. But once the DAW connects to the VIs the CPU usage goes sky high.

two approaches to deal with this:

(1) get slaves and divide the resources needed
(2) manage ur resources properly

re (2):

I highly doubt u need all 99 VIs playing in the same song or cue. So disable the connections to the instances and only enable connection to the instances that u need playing back the current song / cue.

various ways to do that in each of the DAWs.

if u want as many VIs as possible being available to test out stuff and experiment around, then enable as many as u can to still be able to play back notes without glitches etc.

VEPro is very modular, in the way that...

(a) u can save a single channel setup
(b) u can save a project setup, which is a single VEPro instance
(c) u can save a metaframe, which is a collection of VEPro projects/instances
(d) when u open a saved instance/project and import it into a metaframe, it lets you choose which channels to import - so u could optionally decide only to pull the ones in that u need (to minimize resources)

The trick is to save ur projects smartly, and group VIs that will always be used together. For example: I have one project/instance just for BBR Trumpets (all of them, plus ensemble). So if I want those Trumpets, I'll add them to the metaframe that I'm currently using on the current film project.


> think in modular patterns to optimize the resources being used

> create VEPro projects / instances smartly. Group instruments that will always/usually be needed together. Save the projects to be re-used later in other metaframes. Also, if possible try to use up to 12-16 patches in a Kontakt instance (if that instruments has that many articulations). Every additional Kontakt instance eats up RAM. Not much, but everything adds up quickly, especially on single systems with just 48 GB (that is not a lot).

> create a metaframe with only the instruments needed on the current project. No need to load all instances/projects all the time if you do not use these VIs.

> only enable connections to the VEPro instances that are needed

> RAM usage (without any samples) is decided by what is in the metaframe

> CPU usage is decided by how many of these instances are connected to the DAW

Hope this helps a bit.

Near Decision

New Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #3
Hi Ultra,

Thanks very much for the detailed reply.

I'm further experimenting with consolidating some instances of common patches into one, and I can see that being quite beneficial in terms of project management going forward -- being able to load sets of instruments into a metaframe in a "modular" way as you mention. Thanks for that!
It seems I might also be stuck performance-wise -- not being able to take advantage of the full power of the system (see last section below), so this will definitely help in that way too.

In terms of setup and performance, just to clarify particulars, when you say "connection(s)" regarding VE Pro, I take that to mean instances of VE Pro that have an active connection to the master computer via the Server Interface plugin? If that's the case, then my situation is rather different: as I mentioned in my first post, this high CPU use on one thread is happening before any instances are actually connected/active -- hence why I thought the behaviour to be strange.

With that said, upon further research, it actually looks like there might be a reason for that usage with disconnected/inactive instances: the EW Stormdrum 3 library specifically is the likely for the significant increase in CPU usage. Each additional SD3 patch that I add to an instance creates about a 5%-8% increase in CPU load, and only on one single thread (none of my other PLAY libraries do this). And as a thread by fellow member @rgames would indicate, I'm apparently not alone in this issue.
In my case, I'm using a 256-sample buffer size, but the effect is still significant.

Since I've isolated it to that specific library, the worst-case (and overkill) scenario would be to build a (much smaller) slave PC just for SD3, but, taking Ultra's advice, I might just push those patches into a separate instance of VE Pro that can be loaded when I need it, and then I can unload other parts of the Metaframe to save up CPU resources.


yes, with a connection I was referring to the DAW having an open/enabled connection to a specific VEPro instance (whether notes are being played or not)... and usually you have many connections, so the CPU usage goes higher and higher, whether notes are played or not...

the CPU usage being that high before any connection is made by the DAW is very strange. On this current project I load about 80GB into the metaframe and have about 2-3% VEPro CPU activity before the DAW connects.

Regarding selective enabling of connection to VEPro instances: this is very easy to do in DP, Cubase I believe has the enable tracks option, not sure about other DAWs...

Another thing: make sure to purge all samples from ALL Kontakt instances before saving a VEPro instance/project to disk (so that you then later can potentially add it to a metaframe) ! Otherwise all these samples are always loaded, and you may not need them at all.
Top Bottom