# VE Pro & Threads



## snattack (Jun 20, 2013)

Hi,

I'm adding a new slave to my equipment, but there are still some questions regarding the handling of multiprocessing/threads/etc.

I've gone through the manual of VEP but it only mentions Kontakt, and quite frankly, I don't understand what they mean, and also I use EW Play which currently messes up my sessions with random crashes, etc.

That's why I'm once and for all would like to set straight with the optimal way of configuring the VEP.

Here's the system:

CURRENT SLAVE:
i7 2600K, 32GB Ram, SSDs all over. = 8 threads
Instances: 2 (one with BWW, one with HS)

NEW SLAVE
i5 2500K, 32GB Ram, SSDs = 4 threads
Instances: TBA.


Here are my questions:

1. The VEP-manual states that you should use as few instances as possible. Also it suggests to use 2 threads on a 4 core/8 threads processor system. Question: if I have only two instances on one computer running nothing but VEP, surely I'd set it to use 4 threads? If I had 4 instances, I'd use 2 threads/instance?

2. It says that Kontakt uses a multiprocessing, and therefore that instance should use fewer threads and let kontakt do the multi processing. But in kontakt, it's not that easy: there are several configurations of how many cores you should use.

3. If you were me, how would you set the configurations on Slave 1 with one instances of EW Play running HS and one running BWW in kontakt?

Best,
Andreas


----------



## EastWest Lurker (Jun 20, 2013)

All I can tell you is that I have just started a 1 project (v-frame) = 1 Hollywood series instrument in an m-frame on my slave PC, each set to 2 threads, and it is purring like a kitten.

Ditto in VEPro on my Mac for my Kontakt stuff.


----------



## dgburns (Jun 20, 2013)

just an FYI,but "threads" do not mean "cores",and as for spreading the load via kontakt,you can use many instances inside one project to spread the load rather than one kontakt hoofed up with instruments.Even if you don't have multi processor turned on in Kontakt,Ve Pro will spread the load out,even if each kontakt instance is only using one core.
All in all Ve Pro does a great job at balancing the processor load,but you might want to experiment with the threads option.Mine are set to two threads per....

-David


----------



## jaeroe (Jun 20, 2013)

have you read the manual? seems pretty clear on where to start (just search for 'threads'):

p.9

You may change the number of used threads in the Multiprocessing drop-down menu in real-time, and each Vienna Ensemble PRO instance will use the specified number of process threads. So 1 instance on an 8 core computer should use 8 threads, 2 instances should use 4 threads, and so forth. Ideally you should have as few threads as possible while still using all your cores. If you're also running your host sequencer on the same system as the running instances, it might be wise to reserve a core for it.
To keep it simple, set the amount of threads to your amount of cores. If you run into performance issues, lower the amount of threads.

p.11

A note on Multiprocessing
There are some general guidelines to follow when using Vienna Ensemble PRO on a system with multiple cores. The general rule to follow is that the optimal number of threads on a system should be equal to the number of virtual cores present.
Vienna Ensemble PRO, like most other hosts today, offers multi-threading. This means that it runs instruments and plug-ins in parallel using several different threads, which allows to utilize several cores on the system. Vienna Ensemble Pro Server will generally perform best when running as few instances as possible. With the VST3 or RTAS plugin, this is possible to achieve by increasing the number of midi ports per instance (see below). Using the AU or VST2 plugins, you might be required to run several instances to work around the 16-MIDI-channel limitation of these standards (see page 17 and 36 for workarounds).


----------



## EastWest Lurker (Jun 20, 2013)

Following the general proposition "the optimal number of threads on a system should be equal to the number of virtual cores present. " is a recipe for disaster with large templates IMHO. My advice is to stay with 2 threads.


----------



## jaeroe (Jun 20, 2013)

you can get different performance on different setups, but these are the recommended starting points. (for me, multiprocessor on works best in kontakt). jump in and if you get problems change one thing at a time.

pick your staring point in VEP (a single instance with the VSL's rec on threads works best for my systems). with kontakt, you'll have to experimment turning multiprocessor off/on (start with it off). need to reset the app after changing these settings.

also be aware of what the processor load is doing in your DAW hosting VEP server

don't load your VI instance up to heavily within VE Pro if you're still getting a lot of weird performance issues. for instance, with HW Strings diamond, i use 1 instance per section with about 5 patches per instance.


----------



## Gusfmm (Jun 20, 2013)

EastWest Lurker @ Thu Jun 20 said:


> All I can tell you is that I have just started a 1 project (v-frame) = 1 Hollywood series instrument in an m-frame on my slave PC, each set to 2 threads, and it is purring like a kitten.




I'm unclear on what you're saying. One project (or viframe) with a single metaframe in it is like a single instance, but your description: "*each set to 2 threads*" sounds like there is something else or you think the project somehow uses processing power?

Projects are 'containers' where you instantiate the actual 'worker' VEP's and it provides the actual interface to connect to external sources (directly or via LAN). The real processing happens in the metaframes. So if you only have one metaframe, and your set-up is for 2 threads per instance, then that's all you are using, 2 threads.


----------



## jaeroe (Jun 20, 2013)

Metaframes (connection interface for VEP Server) house Vframes (aka an instance of VE Pro). the thread setting is per instance/Vframe. VEP refers to vframes as also instances (in the mframe window) and projects (the file menu).

jay has a lot of experience using VEP and especially with EW products.


----------



## EastWest Lurker (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> EastWest Lurker @ Thu Jun 20 said:
> 
> 
> > All I can tell you is that I have just started a 1 project (v-frame) = 1 Hollywood series instrument in an m-frame on my slave PC, each set to 2 threads, and it is purring like a kitten.
> ...



Sorry, I phrased it poorly. Yes, as it is a preference, it is global to the metaframe. I have 2 metaframes, one for Play libraries on my PC, one for Kontakt libraries on my Mc, both set to 2 threads.


----------



## Gusfmm (Jun 20, 2013)

I inverted the names, so yes, what I refered to as viframes was meant to be meatframes, and viceversa, what I referred as metaframes was intended to be viframes. Apologies.


----------



## jaeroe (Jun 20, 2013)

just to be clear - the vframes take up the threads, not the mframe, so the mframe iteself isn't using up much processing power (as i understand it). as jay points out, the mframe houses the preferences that apply to the vframe.


----------



## EastWest Lurker (Jun 20, 2013)

jaeroe @ Thu Jun 20 said:


> just to be clear - the vframes take up the threads, not the mframe, so the mframe iteself isn't using up much processing power (as i understand it). as jay points out, the mframe houses the preferences that apply to the vframe.



Well it applies to ALL the v-frmes within the m-frame.


----------



## jaeroe (Jun 20, 2013)

the main point that Gusfmm was originally making was with your configuration, you're only using two threads to handle all of your slave's load. processors are going unused.


----------



## Gusfmm (Jun 20, 2013)

EastWest Lurker @ Thu Jun 20 said:


> I have 2 metaframes, one for Play libraries on my PC, one for Kontakt libraries on my Mc, both set to 2 threads.



Jay- how many viframes do you have instantiated on the PC (single) project (metaframe)?, and how many Play instances do you use per viframe?


----------



## EastWest Lurker (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> EastWest Lurker @ Thu Jun 20 said:
> 
> 
> > I have 2 metaframes, one for Play libraries on my PC, one for Kontakt libraries on my Mc, both set to 2 threads.
> ...



I have started with using 1 v-frame per instrument, so 27 "projects"(v-frames)in my PC metaframe.


----------



## Gusfmm (Jun 20, 2013)

So that's:

1 PROJECT = 1 Metaframe
and you have 
27 viframes = 27 VEP instances
within that single Project.

Which is kind of against what VSL recommends of having fewer VEP instances concurrently being better... but it is working for you, so nothing necessarily wrong with that. However, each one of those viframes is supposed to be set-up to use 2 threads in your set-up... which obviously is impossible, so not sure how VEP handles that, probably just allocating load as needed.

Now, the other question: take your HS first violin viframe, how many Play instances do you use within that single instance?


----------



## jaeroe (Jun 20, 2013)

i run three computers per setup - actual mframes on each. what seems to have the best load on the processors is a single vframe in each mframe with the thread count up as high as possible - the exception being the machine hosting the DAW, as that requires some of its own resources.

just like with any other vi, resources take some additional hit with each instance. with a vi that can handle multiprocessors well, you might be giving up resources unnecessarily if you use multiple instances of the same thing (in this case, say two vframes for an mframe). but, if you run only 1 instance/vframe, you aren't taking advantage of your computer's full processing power if you don't allocate your threads high enough per instance.

i.e. - less vframes, higher thread count on slaves.


----------



## jaeroe (Jun 20, 2013)

jay - wow. i've never heard of anyone doing that. seems like a logistical nightmare! you have that many connections to your DAW?!! that's a whole lot of clicking to connect... but, if it works for you, good on ya.

i'm the opposite. three server instances in protools which connect to each of the mframes on the 3 respective computers. one vframe per mframe. 20 or so VI instances within each vframe.


----------



## EastWest Lurker (Jun 20, 2013)

jaeroe @ Thu Jun 20 said:


> jay - wow. i've never heard of anyone doing that. seems like a logistical nightmare! you have that many connections to your DAW?!! that's a whole lot of clicking to connect... but, if it works for you, good on ya.
> 
> i'm the opposite. three server instances in protools which connect to each of the mframes on the 3 respective computers. one vframe per mframe. 20 or so VI instances within each vframe.



The reason I am doing this is because the Hollywood Series lacks key switches but thanks to Perter Schwartz's Ski Switcher I can navigate through all the HS Violin 1 patches from ONE track, using either key switches or my preference, the program change buttons on my Kurzweil. If I save my Logic template connected but de-coupled, it connects to my 2 m-frames automatically as long as I have loaded them first, which I always do.


----------



## EastWest Lurker (Jun 20, 2013)

Oh, as for threads, understand a couple of things:

I don't trust "virtual cores" in OSX. As far as I am concerned my quad core is just that, 4 cores. So I am balancing spreading the load from a PC m-frame set to two threads, a Mac m-frame set to 2 threads, and a whole bunch of stuff directly loaded into Logic itself.

2 threads seems to be what helps in balancing all that without getting pops and licks or a higher biuffe than iwant to use.


----------



## jaeroe (Jun 20, 2013)

interesting - and how many actual VI instances in each vframe, and how many patches loaded up in each of those?

i manually connect to my vframes these days - had enough corrupt files so that basically whenever i change anything, i save as. so, low vframe count is helpful for my workflow.

do you have any sense of EW incorporating in to PLAY 4 a keyswitch setup or user definable interface, in the ball park of LASS's ARC? that in conjunction with background loading would really open up some more possiblities, especially for stuff like the diamond series of the HW stuff.

what happens when you put the thread count to 1? with that many vframes.....


----------



## EastWest Lurker (Jun 20, 2013)

jaeroe @ Thu Jun 20 said:


> interesting - and how many instances in each vframe, and how many patches loaded up in each of those?
> 
> i manually connect to my vframes these days - had enough corrupt files so that basically whenever i change anything, i save as. so, low vframe count is helpful for my workflow.
> 
> do you have any sense of EW incorporating in to PLAY 4 a keyswitch setup or user definable interface, in the ball park of LASS's ARC? that in conjunction with background loading would really open up some more possiblities, especially for stuff like the diamond series of the HW stuff.



1 Play or Kontakt instance per v-frame, generally 5 or 6 articulations if they don't have key switching.

So for instance HS Vln 1 in the first v-frame of my PC m-frame has 5 articulations while the KH Vln 1 n the first v-frame of my Mac m-frame needs only 1 "All Articulations" KS patch.

I have all my working templates backed up 3 ways from Sunday so if one goes south, I have it covered connected.

No I don't believe that will happen until Play Pro, if we all live long enough 

But the Ski Switcher (and Brian Wherry's app for non-Logic guys) makes that less important IMHO.


----------



## Gusfmm (Jun 20, 2013)

But there is something there, Jay, that is not quite correct. I'm going to speak for the PC, as that is what I use.

You have a multi core processor, which virtualizes the 4 physical cores into 8 virtual cores. So from an OS viewpoint, that allows you to run up to 8 independent threads/processes concurrently.

Since you use the PC exclusively as a slave, you have those 8 virtual processors available all for VEP. 

When you setup your VEP preferences and set multiprocessing for 2 threads per instance, that means each viframe you instantiate within that Project (metaframe) will get that allocation of processing power. So I guess it is Ok to say that ideally, you could have (up to) 4 viframes concurrently, each using 2 threads, and they will have complete availability of those 2 exclusive threads.

In your current case though, you have 27 viframes, competing for 8 threads. Again, I'm not sure how VEP handles that scenario. Maybe Dietz is around and can comment. (although likely this is more of the know-how that can't be shared... specially with you  )

But this is all not this clear cut, as there are also considerations to be had around the power demand of each of your viframes, etc. Thus may second question above.


----------



## Gusfmm (Jun 20, 2013)

I see your response to the second question.

Part of the problem is that Play uses MIDI channels assigned to individual articulations, isn't it?


----------



## jaeroe (Jun 20, 2013)

EastWest Lurker @ Thu Jun 20 said:


> No I don't believe that will happen until Play Pro, if we all live long enough



ROFLMAO! something to see at the pearly gates then!


----------



## EastWest Lurker (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> But there is something there, Jay, that is not quite correct. I'm going to speak for the PC, as that is what I use.
> 
> You have a multi core processor, which virtualizes the 4 physical cores into 8 virtual cores. So from an OS viewpoint, that allows you to run up to 8 independent threads/processes concurrently.
> 
> ...



All I can tell you is that when I followed the VSL recommendation of 8 threads, it did not go well, I got lots of pops and clicks. But maybe I will try 4 threads and see what happens.


----------



## jaeroe (Jun 20, 2013)

while VSL are clear on leaving room for other 3rd party apps to take up processing resources, they don't say the VEP can't compete with itself. seems like the thread count acts as more of a ceiling, but if you put a bunch of bungalows next to each other, you can still house a lot of people (where would LA be without bungalows.....)

sounds like this is working fine for jay, so there you go.

jay - i would think the lower the thread count the better in your case. high thread count is recommend for low vframe count


----------



## Gusfmm (Jun 20, 2013)

I wouldn't try 4 Jay. Following the logic, I might try 1. But even then, you are overallocating each thread, so I don't know that there will be any noticeable difference between 2 and 1. But yeah, if anything, I'd expect 1 might be theoretically better than 2...


----------



## EastWest Lurker (Jun 20, 2013)

I dunno. I'm game to experiment but right now, it is working pretty well.


----------



## Gusfmm (Jun 20, 2013)

If it were a ceiling, then using 8 threads would be the ideal, wouldn't it?


----------



## Gusfmm (Jun 20, 2013)

I hear you Jay. I also see no need to experiment if it is working well as-is.


----------



## jaeroe (Jun 20, 2013)

i find that my templates are a living thing. they are constantly changing in little bits, so i find it easier to just save as and have a dating system in the file names. saved me countless times - either going backwards on something, or with bad files.

i certainly backup - two totally independent systems - but, this just ends up being faster and cleared for going back to things.


----------



## EastWest Lurker (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> I hear you Jay. I also see no need to experiment if it is working well as-is.



Except that by nature I am always intellectually curious, which is how I became the guy who writes books and columns.


----------



## jaeroe (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> If it were a ceiling, then using 8 threads would be the ideal, wouldn't it?



it is weird that he's getting 27 vframes going at 2 threads, at least by VSLs recs, but it is what it is. don't mess with results.


----------



## EastWest Lurker (Jun 20, 2013)

jaeroe @ Thu Jun 20 said:


> Gusfmm @ Thu Jun 20 said:
> 
> 
> > If it were a ceiling, then using 8 threads would be the ideal, wouldn't it?
> ...



Well, to be fair, this is theoretical, set up in a big template and just playing some stuff. The only actual piece I have completed uses 11 v-frames on the PC and 11 on the Mac.

Here is the CPU usage set to 1 thread for each as Guffman suggested.


----------



## EastWest Lurker (Jun 20, 2013)

And with 2 threads. As you can see, it is better. Don't know why.


----------



## Gusfmm (Jun 20, 2013)

In Logic, what is that graphic intended for? The "Audio" label is confusing, I see 8 'channels', is it the virtual core activity perhaps?


----------



## Gusfmm (Jun 20, 2013)

I see your picture labels, so must be core activity, right? I'm not sure I see much of a change though. 

Since you're at it, would you dare to try switching VEP to 4 and then 8 threads, and post the same graphic? That'd be interesting to compare.


----------



## EastWest Lurker (Jun 20, 2013)

Gusfmm @ Thu Jun 20 said:


> In Logic, what is that graphic intended for? The "Audio" label is confusing, I see 8 'channels', is it the virtual core activity perhaps?



Yes, real and virtual cores. The Audio has to do with disk activity.

I just bumped it up to 20 v-frames on the PC and all is still good with 2 threads.


----------



## dgburns (Jun 20, 2013)

I know the manual says to assign one thread per available processor core,but as you can see 20 odd v-frames assigned two threads each does not equal 4 cores,or whatever you have.Check out an app called activity monitor in OSX or resource monitor in Win8.You can see how many process "threads" the system has active,and maybe make adjustments seeing the cores in action there.

I also notice 2 threads per instance is optimal for my use.fwiw


----------



## jaeroe (Jun 20, 2013)

their use of 'thread' is not the same


----------



## EastWest Lurker (Jun 20, 2013)

Activity Monitor is my good friend but it can show one thing and Logic's CPU meters another and the Logic one is a better hinter to me as to when things are going to start to f%^k up.


----------



## dgburns (Jun 20, 2013)

yes,you're totally right,just wanted to show that the resource app is actually usefull to me,and it's buried deep in the bowels of windows.I like the memory useage bar as well.Ultimately,the system has to run all the processes anyway,and it's telling to see so many system threads while running ve pro.not to mention the cpu meters for each core helps to see what is going on...well atleast for me anyway. :wink:


----------



## snattack (Jun 22, 2013)

Jay: ok, this is news to me. Currently I run all of HS i one VI Frame, with 5 channels of Play, one for each section. It was the easiest way when working with Expression maps. Problem is Play is crashing a lot. Two questions:

1. How is it with network performance when using this many instances? The CPU meter in Cubase increases for every connection I establish.

EDIT: clarification, with that many instances that you're using

2. Also, this is what I don't get: using 2 instances (= 1 Mframe w. 2 VI Frames), setting VEP to 2 threads (= 2 VI frames x 2 threads = total 4 threads), doesn't this result in half the cores/threads not being used?


----------

