Many plugins implement both 32-bit and 64-bit code paths, because the VST plugin API allows you to do one or both.
This might be true for 32-bit fixed-point values, as used by DSP chips from the distant past, but this is not true for 32-bit floating point.
There are also other problems than signal-to-noise in plugin processing. Read below.
So much mistaken math in this thread.
First: a “32-bit” floating point number has 24 bits worth of precision. (It has a 23-bit mantissa, but gets one extra bit “for free” because of the specifics of the encoding.)
24 bits of precision, buts the quantization noise floor at about -146 dB.
Using 32-bit floating point precision in Cubase (or any other system) will give you quantization noise that’s at -146 dB, and you’ll probably want to add dither to get it to -143 dB but better sounding.
Second: -146 dB quantization noise is still quite imperceptible, because you need to be playing at full scale to get to that point. If your signal is less than full scale, the quantization noise will also lower itself – this is what the “floating point” is all about. I measured my near-field Genelecs to about 112 dB SPL before distorting out (if I remember correctly – this was long ago – I don’t run them that hot, ever, because I like my ears) so the quantization noise would be below 0 dB even at max – and ears mask signals, so you can’t even hear a +20 dB signal when the room is blasting at 110 dB, much less a -36 dB signal, which you can never hear, almost definitionally.
A 64-bit floating-point number, which many VST plugins can process with these days, gives you 52+1 bits of precision, so a little over 320 dB of headroom above quantization noise at full scale. That’s ludicrous overkill, if all you’re thinking about is quantization noise.
However, in signal processing, something called “recursive filters” (“IIR filters”) are very, very common. Almost all EQ, anti-aliasing, and even compressor responses are implemented using IIR. Recursive filters, especially for frequencies that are low compared to sampling frequency, and up accumulating error in an exponential manner.
Thus, it’s actually very very hard to design an EQ/filter that is stable at 20 Hz (or even 100 Hz) when using 32-bit floating point, but it’s quite doable at 64-bit floating point. Back when VST only did 32-bit, many plugins would internally convert to 64 bit just to be able to run stable filters, and then convert back.
Constant conversion back and forth may eventually degrade the signal, in theory, but in practice you’d need so many plugins that you couldn’t plug in enough screens just to fit the name of all of them for that to matter. But there’s some CPU load involved in the conversion, and the built-in Cubase filters/EQ will certainly work better in 64-bit than in 32-bit.
So, if you ever have a plugin that suddenly goes silent or clicky when you crank frequency low or feedback high, it might be that you’re running into the numerical stability limits of 32-bit floating point values, and if the plugin also supports 64-bit processing, changing your project to 64-bit may fix it.
Btw: What’s often done in practice, is add a small noise signal around -120 dB, so 20 dB above the quantization noise floor, to prevent the plugin from reaching the denormal/numerically unstable state. This noise signal could theoretically be amplified by downstream plugins, too, so it may be that your signal chain becomes quieter when you switch to 64-bit processing, where the same kind of signal only needs to be at -300 dB to serve.