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.