Hello all,
I wonder if it has been established what the best combination of multiprocessor settings is for running all 3 programs on the same mac pro 8core. One can tell VE pro how many cores to use, also one can tell kontakt to use multiprocessing or not, and finally Cubase can also be instructed to use or not use MP. Has anyone tried everything?
Also, I am wondering if it is better to set your VEpro plug ins at no buffer whilst moving up the buffer on Cubase or if one is better served with low Cubase buffers and higher VEPro buffers.
-
Ideal combination of multiprocessor/latency settings for VEpro, Kontakt, Cubase on same mac
-
-
I can give you general knowledge, do not enable multiprocessing in Kontakt unless it's a standalone - with any host, use the host's. using both isn't stable, and kontakt's is made for standalone use anyway.
when I have run VE Pro on the same machine as Cubase, I had it enabled on both but allowed for less cores than what would max out cores in VE Pro prefs to let Cubase have at least one. VE Pro should be doing the heavy lifting, note well. Cubase 5.2 at some point improved multicore support, since then I've used VE Pro on a slave.
-
So, what would be more proessor efficient. Running VE Pro instances at max threads/cores, or assigning only a specific number of threads to each instance?
As an example, I have a 12-core Mac Pro. In this situation, what would be more processor efficient: assigning each instance a max of 24 threads, or assigning each instance 6 threads and using 4 instances of the server?
Also, if I set VE Pro to use 6 threads per instance, is it using the same 3 cores? Or is each instance using it's own set of cores? i.e. instance 1 using cores 1-3, instance 2 using cores 4-6, etc. ?
Any help from the development team on this would be grealy appreciated.
-
if you assigned 24 threads per instance, you won't be able to work well unless you've only the one instance; much beyond that, the performance will be poor, and after a point probably unstable. I know because I've forgotten to reset the preferences - I have an 8-core/16 logical cores and I tend to use 3 or 4 instances and assign 5 or 4 threads per...
eg., with 5 threads per instance/4 instances, here are problems [with highly populated instances]. (ie., where 4 threads per/4 instances is not a problem). I've found that on a slave using up all 16 cores, eg., 4x4 is no problem, the OS isn't doing so much else apparently.
If I were running Cubase on the same machine, I'd leave open at least one thread for it, depending on how loaded the cubase project is, with other plugins, or even with a high number of midi tracks, give it a little more. Personally as far as OSX is concerned I wouldn't advise running cubase on the same machine as VE Pro, it's just too slow.
Not sure if I saw this in the manual or from the team here, but I have the received understanding it's best to get the latency as low as possible in the sequencer and add latency in the VE Pro interface when required. I tend to work with ~128 samples in Cubase buffer and x2 buffers in VE Pro, and I get workable [playable] latency even in a mixing scenario. But, Cubase on the same machine, probably max buffers in both, everything else being equal. VE Pro nicely compensates for that tripling in its buffer.
-
Not true at all (on a mac, anyhow)... I recently tested this theory and the multiprocesing in Kontakt is WAY better than the multiprocessing in VEP. Try loading up your performances with K4 or K5's MP turned off and max threads set in VEP and open up your activity monitor. Take a screen grab. Then change to 1 thread in VEP and open K5 in stand alone and turn on the MP to maximum available cores. Then reload your VEP and check out the difference in your activity monitor. I never use VEP's multiprocessing anymore. Not nearly as good as everyone thinks it is.I can give you general knowledge, do not enable multiprocessing in Kontakt unless it's a standalone - with any host, use the host's. using both isn't stable, and kontakt's is made for standalone use anyway.
when I have run VE Pro on the same machine as Cubase, I had it enabled on both but allowed for less cores than what would max out cores in VE Pro prefs to let Cubase have at least one. VE Pro should be doing the heavy lifting, note well. Cubase 5.2 at some point improved multicore support, since then I've used VE Pro on a slave.
-
what is this difference supposed to be in activity monitor? I can't really advisably set VE Pro to one thread per instance as I'm using a couple of things that aren't kontakt.
-
For me (using kontakt exclusively) it was major. Each core in the activity monitor was at about 50% and when I switched each core was at about 15%. If you have another machine you can shot your other instances so that you can have a VEP server that consists of only Kontakt you will get way better performance out of it. That being said, unless you are really hosting a lot of instruments in your other samplers, it can't hurt to try anyway. Set VEP to 1 thread and set Kontakt Multiprocessing to maximum and just have a look.
-
hmmm. it's interesting on a hypothetical level... so you've experienced no stabllity issues? I'm sure I couldn't show causality but I have seemed to have got rid of stability issues when I first started with K4 which had it enabled by default, disabling it. but I did have the threading in VEP as close to maximum available in every case. the percentages in A.M. tend to be high numbers here for the servers, right now in a small project for me the x64 VEP is around 200%, which I would have thought was supposed to be true, ie., using more than one core (3 instances, 5 threads per instance today). But overall I'm seeing around 80% idle in this project. I've never gone near maxing out 16 logical cores, so it isn't any actual issue afaict. The performance here is good.
But for actual use it's a non-starter for me. I might use even up to half Kontakt, but I heavily use Vienna Instruments, and for drums I use BFD2, most projects.
-
For use in DAW, NI advises to not use both the host's and Kontakt's at the same time, is what I was on about. It's been said in response to a typical stability issue, addressed in those terms. When I experienced one with K4 I was working on an assumption.