• SONAR
  • Is Ozone 5 Using Just the 1st thread in cpu? (p.2)
2014/02/07 09:19:47
drummaman
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
2014/02/07 13:05:45
lawp
doesn't ozone5 have the individual modules available as individual plugs?
 
2014/02/07 14:07:07
drummaman
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" ...!!
2014/02/08 11:51:34
ptheisen
Hi mudgel,
 
What I'm referring to is that Sonar displays little marks below each effect in the effects bin to indicate whether the audio path through that effect is mono or stereo, 32bit or 64bit. The mono/stereo choice is usually determined by the track interleave setting. The 32/64 bit choice is determined by the effect itself. The marks look like this:
 mono 32bit          '
mono 64bit           ''
stereo 32bit    '            '
stereo 64bit    ''           ''
 
On my system, the VST2 version displays the 64bit marks, while the VST3 version displays the 32bit marks. Do you see the same thing on your system?
 
2014/02/08 12:03:06
lawp
yes, this has been there for quite a while now
2014/02/08 17:45:59
mudgel
Perhaps it's a display bug with VST3.
Did you know that there is a 32 and 64 bit VST3 plugin installed? Check to make sure that Sonar is using the 64bit version. The 32bit version is installed in the same relative position in the Program Files. (x86) tree.
2014/02/08 19:09:09
ptheisen
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.
 
2014/02/08 20:44:13
mudgel
The guys at iZotope are very open and helpful. Why don't you send them an email with your questions.
2014/02/08 23:14:25
ptheisen
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.
2014/02/09 00:14:22
mudgel
After some more testing and looking at Sonar's manual etc. The double indicators actually show whether or not the plugin is making use of Sonar's Double precision mix engine. (DPME)
 
It seems there are more than a few VST plugins (2 & 3) that while being 64 bit do not make use of Sonar's 64 DPME. eg none of the Native instrument 64 bit plugins (VST2.4) use the DPME in fact most of my plugins do not.
 
Then there are odd ones like VC64 which is a 32 bit plugin and when its bridged in 64 bit Sonar does make use of the double precision mix engine.
 
I don't think this indicator being on makes a plugin any less 64 bit plugin, it just doesn't use sonar's 64 bit DPME.
 
Someone from Cakewalk would need to explain the ramifications. If there are any. I think some plugins just don't send the data that Sonar needs to show this indicator.
12
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account