Is Ozone 5 Using Just the 1st thread in cpu?

Is there any work around to get ozone 5 using all threads in my quad core ?, to me visually looking at X2 CPU meter, it only uses the 1st thread,
any pointers would be very helpfull to clear this up.
X2
Windows 7 H/Premium 64Bit
Quad core something ( the number escapes me at this moment but its pretty high)
8 Gig Memory
StudioCapture
 
BTW: Ive done the core spread thingy bob in the regedit & x2 thread tweak, and tried the ozone propertys tweak
Additional Info: I can normally load a bucket full of plug in's + BFD 3, and the meters/threads just barely come above the 2-3/10ths mark, but as soon as I load Ozone 5 the first thread goes ( when playing tracks) upto between 8 and 9/10ths  and sometime causes a drop out, the other meters/threads do increase aprox 3/10ths.
Please help as Ozone does polish my T****
 
 

Thanks
I guess I will need to contact Isotope directly, anyway thanks again for answering my post.

iZotope's RX is coded for multi-core...

Check page 140 of the Ozone 5 help PDF.

I haven't done any performance comparisons between the VST2 and VST3 versions, but I was surprised to notice, at least on my system, that the VST3 version does not operate with a 64 bit audio stream. Since I try to only use effects that do operate with a 64 bit audio stream, I have chosen to not use the VST3 version.
 
Can anyone else confirm that the VST3 version operates only with a 32 bit audio stream?

Hmmm...
I know software manufacturers can take advantage of multi-core processing, but thought that the actual load balance of the cores was controlled more by the OS...

Per the following Cakewalk blog concerning testing:
http://blog.cakewalk.com/...oduction-applications/

We get this:

"SONAR multi-core CPU load balancing at low latency

Workloads for cores are more evenly balanced at low latencies on Windows 8.
Better balanced core workloads translate to more efficient use of multiple CPU core hardware and
thereby better workload scaling for large projects.

low latency plugins… 23% improvement
input monitoring… 31.7% improvement
high track count… 30.6% improvement
High bandwidth audio …17.5% improvement "

I've been wanting to update to Win8 x64 ever since reading this...

Cheers,
MG

They are great, but I think they only come with the Advanced version for now:
"Ozone 5 Advanced includes individual component plug-ins of each module in Ozone. Now you can selectively load individual modules into your session, each with their own dedicated module preset system."

You also get the meter bridge, which is a handy tool.

Maybe, if enough people ask, iZotope will release them "A la carte" ...!!

yes, this has been there for quite a while now

I know about the separate 32bit and 64bit plugins, but I'm not referring to whether it is a 32bit or 64bit application. My 64bit installation of Sonar X3d uses only 64bit plugins, it is not even aware of 32bit plugins. Conversely, my 32bit installation of Sonar X3d is only aware of 32bit plugins. There is no possibility of confusion or the need for a bit bridge, which is the way I want it.
 
I'm referring to the bit depth of the audio path, directly related to Sonar's ability to use either 32bit (standard) or 64bit (Double Precision Engine). Regardless of whether the 32 or 64bit application of Sonar is launched, and the corresponding plugin inserted, if the Double Precision Engine is turned on, plugins that process audio at 64bit will display the 64bit marks I referred to in my earlier post, while plugins that process audio at 32bit display the 32bit marks.
 
I just found it very odd that the VST3 version of Ozone 5, whether a 32 or 64bit application, displays the 32bit marks, while the VST2 version, whether a 32 or 64bit application, displays the 64bit marks, and I was hoping that someone could confirm whether the same thing happens on their system when they actually try to replicate the scenario.
 
It does not appear to be a display bug that applies to all VST3 plugins. With the Double Precision Engine turned on, the Voxengo Span VST3 plugin displays the 64bit marks, just as its VST2 counterpart always has, and again, regardless of whether using the 32 or 64bit application.
 
Would any Ozone 5 users care to check this out on their system?
 
Sorry to hijack the thread. As for the OP's question, I second mudgel's reference to page 140 in the manual and the other pages linked to there. With that information, you should be able to reduce Ozone's demand on your CPU and still have it work well.
 

Sure, I can do that. I'd still welcome anyone letting me know if the VST3 version appears to use 32bit audio processing when Sonar's Double Precision Engine is turned on in their DAW, or if it's just me.