Huh? Waves should work, they just don’t take advantage of the 64Bit float engine.
What seems to be broken if the reports are right, is the external FX ping not responding when in 64Bit float mode.
Currently I can’t test as I am rebuilding my rack.
current Waves works fine, just make sure u use the latest version
O.K. Raphie…will try updating.
The "symptom"is that the channel meter on the tracks with the offending Waves plugs will show overload into the red. Playback is muted on the track and the Waves plug will not “release.” The only option is to quit. At least, this is what happened on my rig.
I’m having some trouble with some Waves plugins, the CLA series. I get
Program Files (x86)\VSTPlugins\WavesShell-VST 9.91.dll
on the blacklist, but another version:
Prorgram Files\VSTPlugins\WavesShell-VST 9.91_x64.dll
that’s not blacklisted. The Plugin manager tends to crash a lot.
I’ve had _Program Files(x86)\VSTPlugins_ on my plugin path because I left some 64 bit VSTis there once. So I moved them to _Program Files\VSTPlugins_ (which is where they belong) and eliminated _Program Files(x86)\VSTPlugins_ from the search paths of plugin manager. Then restart C9.5. The Plugin Manager still crashes when updating plugin information, and CLA Bass/CLA Guitars/CLA Vocals still crash fail to load.
I have not tried saving the project under another name. This happens if I start an empty project, add an audio track, then add an insert (CLA Bass). It happens with both 64 bit and 32 bit VST audio systems.
============== UPDATE ============
The problem was solved by Martan at Waves tech support, who responded within 10 minutes of my e-mail for help. 
Basically, it involved uninstalling and re-installing, but (I think) not using the easy install the 2nd time. Someone somewhere else on the forum had a similar experience. (t.ex. Waves plugins not seen by Pro 9 - #14 by EliottNess - Cubase - Steinberg Forums) The uninstall is a bit complex, the details were similar to KurtOzz’ description. This success was with 64 bit VST audio.
Cons? None really. The only real con is a theoretical heavier system load, since you are talking double precision math instead of single precision. However modern CPUs are real, real good at DP math as a lot uses it. Likewise mixing is a very simply operation for a modern CPU, so you aren’t spending much of your power there. So in theory maybe it drops the number of tracks you can have, in practice I doubt it.
Pros? Basically just a buffer against potential rounding errors. Single precision floating point, aka 32-bit, is done as an 8-bit exponent (the range) with a 24-bit significand (the precision). So that means it maintains 24-bits of precision over a wide range of volumes. This works great as we prevent clipping, prevent LSB loss, and maintain the output precision at all times… BUT there is the issue that we are going to be performing some math at the precision of export, which means rounding errors can creep in.
Realistically, this is not a big deal. If there’s rounding errors in 1 or 2 LSB (or even 3 or 4) who really cares? It’s not only below audibility, it is below the ability of converters to reproduce. Totally irrelevant to the enjoyment of the music. However, what if we could solve it so it was just totally a non-issue? With double precision, aka 64-it, we can. This gets us an 11-bit exponent with a 53-bit significand. Now we have WAAAAY more precision than we need. Rounding errors will be so low they will never, even in edge cases, be able to creep in to the final signal. It just solves any theoretical problem.
So it is not at all something I’d worry about, not something that is badly needed, but I turn it on because why not? My system is not hurting for power, and it just feature that makes sure that the math the computer is doing is never an issue to the results, which is as it should be.
has there anywhere posted a blindtest. i would like to liusten myself of the difference. havent bought yet the update.
To my ears, running a complex project (130+tracks) I’m hearing more openness and clarity in the mix. Maybe it’s a placebo effects, but it was immediately noticeable when I switched the project I’d been working on for 3 weeks in 32-bit to 64-bit.
Surely its easy enough to find out? Export the project with the 32bit engine. Reload and export the project with 64bit precision. Re-import and null test.
The problem posting Null tests is the music has to be without any copyright restrictions and not using any free floating LFO or other modulation FX that are not a 100% in sync.
Drum plugins have some human touch to them, varying the velocity and groove slightly every time, but never the same.
And all should be documented, supplying the project and resulting files, so everyone can try to recreate.
Better IMHO to do it for yourself, and draw your own conclusions.
The C9.5 Demo does not NULL, but I don’t think it will even if exported using the same settings twice, have not bothered to try.
I would imagine the implementation is also a half way house for 64bit cpus until steinberg can fully implement hypertheading into their code. Im on an intel i7 8th gen and cubase barley touches its capacity when it comes to hyperthreading. I supose the use of 64bit float goes a small way to utilizing 64 bit multi thread cpus.
Ehh we are taking internal audio engine bitdepth here. It’s not there to calculate faster, but to produce more precise calculations. Less rounding errors.
If a performance increase is to be found, it probably comes from keeping the format 64 bit double precision from daw to plugin and back. Provided the vst3 plugin is coded to handle 64 bit double precision in the first place.
I had random +100db peaks with Amplitube 4 and 64-bit floating precision enabled. Seemed a bit too dangerous for my ears so I changed it back to 32-bit. Another user had the same problem in the german forum.
Hi Guys,
If we take into account than plugins upscale internally audio signal very high to obtain best audio quality, it seems to me a good idea to increase the precision in the sequencer itself.
This precision is noticeable in the context of a mix with a lot of tracks.
On another hand our OS are 64 bits, so it seems also a good idea to avoid more conversion and to work direclty in 64 bits.
On another hand our OS are 64 bits, so it seems also a good idea to avoid more conversion and to work directly in 64 bits.
You make a confusion here. Your argument is not valid.
A 64 bits OS is not an OS that is using specifically 64 bits processing. 32 bits OS can do that since a long time, and even 8 bits micro controllers can do 64 bits processing if you are using the right math library to do it.
When we are talking about the OS bit depth, we are talking about the memory bus addressing capability, 32 bits or 64 bits.
This is the quantity of memory directly addressable (without extension API). This has nothing to do with processing depth.
Since a long time, and well before 64 bits OS, it was possible to use 64 bits float processing without math library emulation, as the Intel Floating Point Unit was 80 bits internally. So with a 32 bits OS, it was possible to make 64 bits hardware processing at the same speed than in a 64 bits OS.
As a side note, with a 32 bits OS, well before 64 bits OS, (since Intel Pentium Pro and AMD Athlon processors) it was also possible to address more than 32 bits of memory, using a system extension (PAE extension for Windows for example). This is not something well known.
From Microsoft :
Certain 32-bit versions of Windows Server running on x86-based systems can use PAE to access up to 64 GB or 128 GB of physical memory
In fact is it possible to enable this PAE extension even on Windows 7 non server OS.
So it is important to not confuse processing depth, physical memory addressing width and OS memory allocation width, that can be extended anyway with a special OS extension for older 32 bits systems.
If 64 bits OSs did facilitate memory management for DAWs and large sessions, they did almost nothing for processing capabilities. Newer processors and compilers did nevertheless, with newer SIMD and vector execution units (MMX, SSE, AVX…).
When the IBM PC / DOS was first introduced, it had a maximum memory capacity of 640k. Not gigabytes. Not megabytes. 640 Kilobytes.
When asked about the limitation the response was, “640k is more than we’ll ever need.”
Really.
You guys should run Waves Central and update your plugins. While I’ve upgraded most to v10, my SSL and Vocal Rider plugins are only available in version 9. They’re working fine in both Cubase 9.5 and Cubase 10. If for whatever reason you’re not getting 64 bit versions contact Waves support - their service is very good.
Some plugins do work internally at 64 bits float processing depth (sometimes only for the more complex part of the processing), but most of them do exchange audio data at 32 bits float with the DAW host.
I think that developers try to not use 64 bits everywhere so that they can compute four 32 bits words at the same time using SIMD instructions. This speed up the process.
You can check this enabling the “show plugins that support 64 bits float processing” option in the Nuendo Plugin manager.
I think that this display option show plugins that can exchange data at 64 bits float (even if those plugins do not use this resolution internally !).
You will see that most plugins are not communicating at 64 bits float; except Steinberg ones and some rare recent ones.
This mean that as of today, most plugins are communicating with the DAWs at 32 bits float depth, with some of them eventually processing at 64 bits float internally.
Very few of them have data exchange at 64 bits float and internal processing at 64 bits.
And we will probably see in a near futur, updated version of existing plugins that will exchange audio data at 64 bits float, but that will keep their internal processing at 32 bits float ! for marketing reasons !
To be sure about a full 64 bits path from end to end in a DAW, it is possible to use a bit meter at the end of the path. Can be done in Wavelab for example. I’m not sure if something similar do exist in Cubase or Nuendo for checking that. For even more serious testing, a 64 bits float signal generator and a level meter than can display very low 64 bits float levels would be necessary. Something probably not available.
Last, i would be curious to listen for null tests, nulling the same mix at 32 and 64 bits float.
.
It’s possible to check if a plugin output 64 bits precision using the free Stillwell Bitter plugin. It’s a bitscope plugin that can show if there is data for the lowest bits.
Put this plugin after another one, and you will see if the preceding plugin do output data at 32 or 64 bits precision.
Be aware that this is not a full proof that a plugin is really 64 bits from end to end. A plugin could output data with dither on the lowest 32 bits, but still compute internally with 32 bits float precision. In this case bitter would show that 64 bits are used, but only the 32 highest bits would convey real audio data. The lowest 32 ones could be only dither noise.
To fully check if a plugin is really 64 bits float from end to end would ask a more complicated test, for example using a signal generator just before the plugin, and an analyzer after, to check that the lowest bits of the tested plugin are effectively conveying real audio data and not dither noise. This could be done for example using a very low level 1 KHz signal, below the 32 bits level, and watch if this signal is still present at the right level after the tested plugin.
I"m not sure if such analyzers and generators capable of dealing with very low levels below the 32 bits boundary are available in the vst format. Perhaps Plugin doctor from DDMF is usable for that.
It’s a standalone analyzer application that can load VST plugins to test them, outside of the DAW.
repeat untill you belive it hard enough : I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure I am sure
I have been looking for info about this to decide wether to set cubase 32bit or 64 bit precision and bumped here (cubase default is 32bit).
I found something else that makes me wonder, so more info to the pool :
Should I export 32-bit float?
For ultra-high-dynamic-range recording, 32-bit float is an ideal recording format . The primary benefit of these files is their ability to record signals exceeding 0 dBFS. There is in fact so much headroom that from a fidelity standpoint, it doesn’t matter where gains are set while recording. 16/03/2022
Modern, professional DAW software can read 32-bit float files. When a DAW first reads a 32-bit file, signals greater than 0 dBFS may first appear clipped since, by default, files are read in with 0 dB of gain applied. By applying attenuation to the file in the DAW, signals above 0 dBFS can be brought below 0 dBFS, undistorted, and used just like any 24- or 16-bit file.
For 32-bit float recording, exact setting of the trim and fader gain while recording is no longer a worry, from a fidelity standpoint. The recorded levels may appear to be either very low or very high while recording, but they can easily be scaled after recording by the DAW software with no additional noise or distortion. This can be seen with these sample files. This is the same source, one recorded with 24-bit fixed and the other with 32-bit float. Both files appear clipped when initially read into DAW software, but the 32-bit file’s gain can be scaled by the DAW.
Is this real/true? Even if the signal clips the AD converters? 
I understand the logic from the perspective of digitally generated files, but I can’t get my head around the AD conversion process.
I.E. in the specs of a pro interface like the UAD Apollo (from their website):
UA engineers obsessively auditioned the latest A/D and D/A converters — ultimately pairing elite-class 24-bit/192 kHz converters with all-new analog circuitry for an ultra-pristine signal path.
The Sound Devices does mention 32bit converters in the specs.
This raises the question, is there any advantage to record 32bit files if the AD converters only go up to 24bit?
Once the audio is processed in the DAW (something like as a simple gain change) the resolution goes up to the defined processing precision. Am I correct? So no need to use extra storage space if the AD converters stop at 24bit.