I am new to JUCE and setting out to make a synth-plugin, and I will want it to output 64-bit audio rather than 32-bits, whenever allowed by the plug-in host. However, when I use Projucer to create an Audio Plug-In, it is generating code that assumes I’m outputting 32-bit audio; for example:
void Test2AudioProcessor::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
{
...
// This is the place where you'd normally do the guts of your plugin's
// audio processing...
for (int indexInputChannel = 0; indexInputChannel < totalNumInputChannels; ++indexInputChannel)
{
float* channelData = buffer.getWritePointer (indexInputChannel);
// ..do something to the data...
It assumes I’m writing floats, so where can I learn what I need to support writing doubles?
and eventually implementing the virtual callback which uses double instead float.
As a good learning curve for JUCE is the look at the source code as much as possible. that’s the greatness of open-sourced-api and it’s useful pretty self explanatory.
N.B. the host will call either the the processBlock (AudioBuffer<float>&, MidiBuffer&) OR the processBlock (AudioBuffer<double>&, MidiBuffer&), never both. The best is to write a templated private method and call it from both specialisations).
I’m not thinking anyone would hear the difference under normal use in blind A/B testing. I still want to do it, for extreme-use cases. Someone might want 500 instances summed, in which case the noise floors would add up (I myself actually have done that in practice, not just for the point of being extreme). Someone might want to apply extreme compression and then compensate by raising the gain.
And if people on Gearslutz want to test the precision of my synth eventually, I want it to look good in their meters, even if no one can hear the difference. Because it will make a difference to some users, and I’m aiming to satisfy.
Hosts are supporting 64-bits. I don’t want to be the component that bottlenecks the precision. Even if it’s just a marketing issue.
But as you raise a good point, I could include a user-controllable option for selecting between 32-bit and 64-bit output, for those users who’d rather conserve CPU.
“Even with 500 instances you won’t get any noise with floats. Where would the noise come from?”
Quantization-error creates a noise-floor. The more tracks you sum, the higher the cumulative noise-floor rises. No?
That said, I am rethinking my decision to support 64 bits, in light of your posts. It might serve the synth better if I spent my time on other features.
There are certain presets in NEXUS in which up to 250 stereo-sources (samples & oscillators) are mixed if you hold enough keys on the keyboard. And that is just one instance! No noise to be heard or measured.
I think you underestimate the precision and range of 32-bit float values. We use doubles in our code only for a very few specialized indices etc. but never for the actual audio-output.
I’m not even aware of a single commercial plugin that offers 64-bit output. Even if the host decides that it wants to mix all it’s track in 64-bit, calling your plugin, then doing the mixing while converting from float to double is a standard thing for them, since 99.99% of all plugins only output a 32-bit signal.
“I think you underestimate the precision and range of 32-bit float values.”
Possibly. I’m assuming a 32-bit float uses 23 of those bits to store the significand, i.e., the mantissa. So a sample with an amplitude around +1.0 or -1.0 will have noise at -138 dB, due to the quantization error (since 138 = 23 * 6). Am I mistaken about that?
If I output 32-bit floats only, using the code Projucer generated (shown in my original post), and the host is mixing at 64-bits, will the host automatically do the conversion? Or does my code need to make further provisions for the case where the host is mixing at 64 bits?
@reFX measuring quantization error is extremely difficult in a synth because it doesn’t add white noise, it adds aliases (quantization is deterministic, on periodic signals the error will be periodic). Now I don’t really want to do the math to figure out what it should be, but try your 250 voice example with sines generated using an euler oscillator that should exhibit no aliasing and measure the THD+N, because it will be non-zero. I highly doubt it’s any significance, but that doesn’t mean people on Gearslutz or KVR aren’t going to find it. All in all I agree with what your saying, this is a very minor thing to fuss over.
Luckily we don’t care what people at Gearslutz and KVR say. Our success doesn’t depend on their approval.
Try -145 dB. If anybody on this planet claims to be able to hear any of this, you can safely regard them as nut-jobs with nothing better to do. They won’t use your product anyway. They’re not making music, they’re into discussing conspiracy theories and collecting their toenail clippings.
Yes.
No. If the host wants to mix in 64-bit, it will convert your 32-bit output on the fly.
“-145 dB. If anybody on this planet claims to be able to hear any of this”
-145 dB would be the level of the noise entering the host from the synth, but the level of the noise entering the listener’s ears isn’t necessarily as quiet.
I appreciate your input here – so much that I’m going ahead in 32 bits – but I still believe any quantized signal contains noise, and that no matter how quiet that noise is, it may be amplified into the audible range by subsequent processing. If that sounds unreasonable to you, I’ll give you the last word before this turns into an endless Gearslutz-style debate.
The purpose of 64-bit plugin maths is not to sound better. It’s there so that you can tell your users that your plugin “supports 64-bit output for the highest possible audio quality”.
There will be people who believe they can hear the difference. They’re wrong, but it’s easier to just give them what they want rather than argue about it.
So no, you don’t need to worry about 64-bit maths, especially if you’re just starting out.
BUT… like Daniel suggested above, by using templates it’s trivial to write code that works with either float or double, so there’s really no reason not to do that from day 1. It won’t cost anything and may save you time later.
