If the 64 Bit version (of what) needs a huge amount of CPU, this is a bug somewhere and should be found and cured.
It's unlikely that the 32 version of the same program needs less CPU than the 64 bit version. On the contrary it should be more efficient, but might need more RAM.
I run the full Brass setup (Horns, Trp, Trb, Btrb and Tuba). When I shut of all other tracks (WW, Strings etc) and play only the brass section, 66% of my CPU is beeing used. Frozen they use only 42. Thats well 25% increase in CPU! (This is including all other processes going on in Logic and VEP).
When I turn on the other instruments it´s 75% used and only 50 when I freeze the brass tracks.
I run a 2015 top spec iMac, 40 Gb Ram. This is doing 256 buffer in Logic (witch shouldn´t matter as I guess VEP is taking all the load).
It´s all fine, but as I start editing the fan is going of, and it bothers me If I start adding more percussion and synths and maybe more dense orchestration, I worry I will hit the roof.
eirikbj wrote:
I run the full Brass setup (Horns, Trp, Trb, Btrb and Tuba). When I shut of all other tracks (WW, Strings etc) and play only the brass section, 66% of my CPU is beeing used. Frozen they use only 42. Thats well 25% increase in CPU! (This is including all other processes going on in Logic and VEP).
When I turn on the other instruments it´s 75% used and only 50 when I freeze the brass tracks.
I run a 2015 top spec iMac, 40 Gb Ram. This is doing 256 buffer in Logic (witch shouldn´t matter as I guess VEP is taking all the load).
Are you running each brass instrument in its own Kontakt window? Or do you have them all stacked in one window?
Because it is more efficient and works better when you assign each instrument to its own window.
Ben H wrote:
it is more efficient and works better when you assign each instrument to its own window.
By "Window" you mean "instance of the Kontakt VSTi" ?
That could be the case if Kontakt only uses a single CPU per instance (would be silly but possible).
But there should be means to see the used CPU performance per CPU.
(I suppose by "kill my CPU" the OP did not claim that his box only has one, nor did he say how he did a measurement.)
BTW.: especially Kontakt should benefit form running it as 64 Bit, as it uses a huge amount of memory to hold the samples, and this can be organized a lot better with the 64 bit instruction set. So using the 32 Bit Kontakt should make things greatly worse.
BTW2.: AFAIK, there is no 32 bit / 64 Bit version of Kontakt libraries. If the OP wants to use 32 Bit Kontakt, he can just d/l same from NI.
BTW3.: If he uses a 64 Bit host, it is not granted that it can run 32 Bit VSTs "out of the box". Here a "VST Bridge" is necessary. Some host do have it other don't.
Kontakt is designed primarily as a highly optimised sample streaming engine. It is lauded as being significantly better and more efficient than other players at this task. You can get many more track counts with Kontakt than say with the PLAY engine, for example.
The problem with SM instruments is that they are highly computational instead and demand more CPU, as they are not simply playing samples back, but performing lots of processor intensive, real-time calculations to make the instruments sound more real. Obviously this comes at the cost of a higher CPU hit.
Combine that with the fact that SM are having to shoe-horn their Sample Modeling paradigm into a traditional sample player and thus its obviously not going to be as suited to the task or efficient as their own SWAM engine.
I see that libraries using extremely versatile / complex scripting might bring up Kontakt's CPU hunger decently, especially, as obviously scripts of any kind are less efficient than native programming. But I feel that in times of ever increasing CPU resources, it is very viable to base such an instrument on a solid base such as Kontakt instead of implementing everything from scratch. (As they did with SWAM which is a lot less Sample-driven and more physical modeling than the Kontakt based instruments.)
OTOH, I really don't understand why a single Kontakt instance with multiple libraries should necessarily perform worse than multiple instances with the same libraries loaded one by one.
As discussed that might be an issue of a single instance not using multiple CPUs. That might be a shortcoming of Kontakt itself, but it also might be a shortcoming of the VST host not assigning multiple CPUs to a single track. And this again (a wild guess of mine) might be an issue of the VST3 vs VST2 specification.
Anyway first step should be to measure the load of each single CPU during the performance.
In CPU profiling mode each SWAM instance uses 8,6% Cpu. I guess that is 8,6 of one core, but if I use all instruments that consolidates to 103% CPU, that answers to one full core.
This is one instrument in one kontakt instrument, run from one vep instance.
I have tried to consolidate all samplemodeling instruments to one kontakt instance (one vep instance) at it almost makes things worse.
Comments
It's unlikely that the 32 version of the same program needs less CPU than the 64 bit version. On the contrary it should be more efficient, but might need more RAM.
-Michael
When I turn on the other instruments it´s 75% used and only 50 when I freeze the brass tracks.
I run a 2015 top spec iMac, 40 Gb Ram. This is doing 256 buffer in Logic (witch shouldn´t matter as I guess VEP is taking all the load).
It´s all fine, but as I start editing the fan is going of, and it bothers me
(Regarding the Kontakt Instruments, I suppose, SampleModeling can't do anything about their performance, anyway.)
Can you find out the amount of CPU power each of them uses ?
-Michael
When I turn on the other instruments it´s 75% used and only 50 when I freeze the brass tracks.
I run a 2015 top spec iMac, 40 Gb Ram. This is doing 256 buffer in Logic (witch shouldn´t matter as I guess VEP is taking all the load).
Are you running each brass instrument in its own Kontakt window? Or do you have them all stacked in one window?
Because it is more efficient and works better when you assign each instrument to its own window.
By "Window" you mean "instance of the Kontakt VSTi" ?
That could be the case if Kontakt only uses a single CPU per instance (would be silly but possible).
But there should be means to see the used CPU performance per CPU.
(I suppose by "kill my CPU" the OP did not claim that his box only has one, nor did he say how he did a measurement.)
BTW.: especially Kontakt should benefit form running it as 64 Bit, as it uses a huge amount of memory to hold the samples, and this can be organized a lot better with the 64 bit instruction set. So using the 32 Bit Kontakt should make things greatly worse.
BTW2.: AFAIK, there is no 32 bit / 64 Bit version of Kontakt libraries. If the OP wants to use 32 Bit Kontakt, he can just d/l same from NI.
BTW3.: If he uses a 64 Bit host, it is not granted that it can run 32 Bit VSTs "out of the box". Here a "VST Bridge" is necessary. Some host do have it other don't.
-Michael
By "Window" you mean "instance of the Kontakt VSTi" ?
That could be the case if Kontakt only uses a single CPU per instance (would be silly but possible).
Yes.
It uses a little bit more RAM that way (although not drastic) and not a concern since the OP has 40GB.
But it threads/load balances whatever terminology you want to use better with one Kontakt instance per instrument.
This has been mentioned many times before on here.
-Michael
Kontakt is designed primarily as a highly optimised sample streaming engine. It is lauded as being significantly better and more efficient than other players at this task. You can get many more track counts with Kontakt than say with the PLAY engine, for example.
The problem with SM instruments is that they are highly computational instead and demand more CPU, as they are not simply playing samples back, but performing lots of processor intensive, real-time calculations to make the instruments sound more real. Obviously this comes at the cost of a higher CPU hit.
Combine that with the fact that SM are having to shoe-horn their Sample Modeling paradigm into a traditional sample player and thus its obviously not going to be as suited to the task or efficient as their own SWAM engine.
OTOH, I really don't understand why a single Kontakt instance with multiple libraries should necessarily perform worse than multiple instances with the same libraries loaded one by one.
As discussed that might be an issue of a single instance not using multiple CPUs. That might be a shortcoming of Kontakt itself, but it also might be a shortcoming of the VST host not assigning multiple CPUs to a single track. And this again (a wild guess of mine) might be an issue of the VST3 vs VST2 specification.
Anyway first step should be to measure the load of each single CPU during the performance.
-Michael
This is one instrument in one kontakt instrument, run from one vep instance.
I have tried to consolidate all samplemodeling instruments to one kontakt instance (one vep instance) at it almost makes things worse.