Kilohearts Plug-ins (My Misunderstanding)

[Jac459]

]A lot and it probably sounds good to them. And good for them. But then again, this discussion was/is about plug-ins that are supposed to be as transparent as possible.

Do we want plugins as transparent as possible? (e.g. 32 vs. 64 vs. .... 1024 vs. ... bit)

Engineering isn't working like that. The core of engineering is defining requirements to fulfill a certain set of use-cases. Of course making requirements harder are linked with higher costs (not just money, but also computation time or memory) and this 32 vs. 64 bit discussion thing is all about, if the market is willing to pay the higher effort to developers for introducing 64 bit precision all over the place. I have the impression, that currenty not...

I think it isn't my quote....

[limitlesssss]

Exactly. Algorithms can be using doubles where needed and floats where needed, but ultimately everything would (in 99% of cases) be done in processReplacing(), not processDoubleReplacing(), barring very few exceptions (for example Airwindows, etc.).

So basically, for the fewest 32-Bit FP to 64-Bit FP and then back to 32-Bit FP conversions, keep your DAW at 32-Bit FP, since most plug-ins are operating at 32-Bit FP anyway.

[HoRNet]

When not marketed as 64-bit, you can be sure it's 32-bit.

well we stopped saying that the plugins are 64 bit because with 64 bit CPUs of today it really does not make sense to use floats anymore, it did not made any sense 10 years ago when we started, it's completely pointless now.

the only case when it can make sense is to optimise performance with vector units since you can process 4 floats or 2 doubles at once but IMHO CPUs are so powerful that it's simpler to keep everything at maximum resolution and don't think about dithering at all (unless you are a bad person and simply truncate double to floats )

Saverio

[limitlesssss]

Uh-oh, another can of worms, dithering doubles when converting to floats. Is that even possible to dither floating point? If I recall correctly Fabien from TDR doesn't believe so? Please don't quote me on that.

My whole goal is to stay in one resolution until the very last moment, to avoid every possible artifact that can occur when resolution conversion happens.

[whyterabbyt]

Uh-oh, another can of worms, dithering doubles when converting to floats. Is that even possible to dither floating point?

Yes its possible. Dither is basically just adding noise.
But its not necessary.

"Conversion between 32 bits and 64 bits floating-point, a regular scenario for audio clips being bussed by the DAW in and out of various, third-party plug-ins, is a completely transparent and lossless process that needs not be dithered in any case and produces no truncation distortion whatsoever, even when going “down” from 64 bits to 32 bits. The scaling nature of floating-point makes for a full-scale accuracy at all possible sample values."

From part 3 of the following series

https://sonimus.com/blog/info/dither-an ... ineer.html
https://sonimus.com/blog/info/dither-an ... -pt-2.html
https://sonimus.com/blog/info/dither-an ... -pt-3.html

[limitlesssss]

Uh-oh, another can of worms, dithering doubles when converting to floats. Is that even possible to dither floating point?

Yes its possible. Dither is basically just adding noise.
But its not necessary.

"Conversion between 32 bits and 64 bits floating-point, a regular scenario for audio clips being bussed by the DAW in and out of various, third-party plug-ins, is a completely transparent and lossless process that needs not be dithered in any case and produces no truncation distortion whatsoever, even when going “down” from 64 bits to 32 bits. The scaling nature of floating-point makes for a full-scale accuracy at all possible sample values."

From part 3 of the following series

https://sonimus.com/blog/info/dither-an ... ineer.html
https://sonimus.com/blog/info/dither-an ... -pt-2.html
https://sonimus.com/blog/info/dither-an ... -pt-3.html

Wow, thank you for the links. I always thought going down from 64-Bit FP to 32-Bit FP could not possibly be lossless. But apparently I was wrong.

Thanks again whyterabbyt.

[stoopicus]

Wow, thank you for the links. I always thought going down from 64-Bit FP to 32-Bit FP could not possibly be lossless. But apparently I was wrong.

Yes and no. It is not mathematically lossless (this would be impossible.) But in terms of audio sample representation it is effectively not an issue for truncation of the intermediate FP values.

[limitlesssss]

Uh-oh, another can of worms, dithering doubles when converting to floats. Is that even possible to dither floating point?

Yes its possible. Dither is basically just adding noise.
But its not necessary.

"Conversion between 32 bits and 64 bits floating-point, a regular scenario for audio clips being bussed by the DAW in and out of various, third-party plug-ins, is a completely transparent and lossless process that needs not be dithered in any case and produces no truncation distortion whatsoever, even when going “down” from 64 bits to 32 bits. The scaling nature of floating-point makes for a full-scale accuracy at all possible sample values."

From part 3 of the following series

https://sonimus.com/blog/info/dither-an ... ineer.html
https://sonimus.com/blog/info/dither-an ... -pt-2.html
https://sonimus.com/blog/info/dither-an ... -pt-3.html

So all this begs the following question:

If conversion between 64-Bit FP and 32-Bit FP is completely lossless, what's the benefit of 64-Bit FP then? The only benefit that comes to my mind, is if your signal's resolution is higher than 24-Bit integer, because 32-Bit integer cannot be fully presented using 32-Bit FP. For that scenario 64-Bit FP is necessary, which also makes me wonder about another question:

IF your original signal is 32-Bit integer, and you manipulate it using 64-Bit FP process, but then convert it down to 32-Bit FP, how can that then be completely lossless? By converting it down to 32-Bit FP, you're effectively throwing away the last 8 bits of your 32-Bit integer signal. Your signal is now effectively a 24-Bit integer signal. So converting it back to 64-Bit FP is not going to bring back those lost 8 bits, is it?

[rafa1981]

the only case when it can make sense is to optimise performance with vector units since you can process 4 floats or 2 doubles at once but IMHO CPUs are so powerful that it's simpler to keep everything at maximum resolution and don't think about dithering at all (unless you are a bad person and simply truncate double to floats )

CPUs are powerful but memory accesses aren't. As long as all data is in registers or on cache things are fine, which is very often the case in audio. If the algorithm is memory "intensive" then using floats may help.

Double to float conversions uses rounding by default on the FPU, not truncation. Float to double is lossless.

Converting a double to float loses resolution on the mantissa, so it's lossy the first time.

As I see it, there is no reason to not transport the audio buffers in single precision. I mean, not so long ago there were 24 bit fixed point systems.

For which purpose should someone dither a floating point sampling scheme with a logarithmic "grid" with much more precision towards zero values? A single precision floating point value has a dynamic range of 1528dB (total, from 1 to epsilon it might be less, assume 760+dB). Also every mantissa value of a normalized nonzero represented value has also the highest (virtual) bit 23 set, so what is the point of adding noise on bit0 to bit-1?

[HoRNet]

the only case when it can make sense is to optimise performance with vector units since you can process 4 floats or 2 doubles at once but IMHO CPUs are so powerful that it's simpler to keep everything at maximum resolution and don't think about dithering at all (unless you are a bad person and simply truncate double to floats )

CPUs are powerful but memory accesses aren't. As long as all data is in registers or on cache things are fine, which is very often the case in audio. If the algorithm is memory "intensive" then using floats may help.

Double to float conversions uses rounding by default on the FPU, not truncation. Float to double is lossless.

Converting a double to float loses resolution on the mantissa, so it's lossy the first time.

As I see it, there is no reason to not transport the audio buffers in single precision. I mean, not so long ago there were 24 bit fixed point systems.

For which purpose should someone dither a floating point sampling scheme with a logarithmic "grid" with much more precision towards zero values? A single precision floating point value has a dynamic range of 1528dB (total, from 1 to epsilon it might be less, assume 760+dB). Also every mantissa value of a normalized nonzero represented value has also the highest (virtual) bit 23 set, so what is the point of adding noise on bit0 to bit-1?

Sure memory plays a role but the DAW sends you doubles anyway (it's beee really a long time since I used floats and I'm not sure DAWs still use the processReplacing with floats) and even then we are talking about max 8192 doubles, even if you do hi precision FFTs you rarely go above 32768 samples / bin and even in that case we are talking about 2MB of memory...

Regarding the rest I agree but honestly since I've been using only doubles for so many times I really did not care/ remember al that technical stuff.

Saverio

[rafa1981]

Well, as you use iPlug I guess you are abstracted for that, but I think that it's still possible for the DAW to send single precision if I'm not wrong. But yes, with reasonable latencies the blocks passed around by the DAW are tiny and we are probably splitting hairs.

The effects are cummulative for each plugin in the chain though, I assume that the memory can be prefetched most of the time, etc. For audio isn't probably worth mentioning unless we talk about reverbs using a lot of memory, samplers, but e.g. on machine learning they seem to store half-precision floats for this reason.

It would be nice to see a full benchmark with multiple 32 vs 64 bit reverbs in parallel. The problem is having a reverb allowing configurable bit depth. The only one I know is Turbopaco, but it's 16 vs 32 bit, so the float16 is slower because it isn't hardware aided, but done with bitshifting.

[SamDi]

I think it isn't my quote....

Sorry, corrected it.

[mixtur.se]

]A lot and it probably sounds good to them. And good for them. But then again, this discussion was/is about plug-ins that are supposed to be as transparent as possible.

Do we want plugins as transparent as possible? (e.g. 32 vs. 64 vs. .... 1024 vs. ... bit)

Engineering isn't working like that. The core of engineering is defining requirements to fulfill a certain set of use-cases. Of course making requirements harder are linked with higher costs (not just money, but also computation time or memory) and this 32 vs. 64 bit discussion thing is all about, if the market is willing to pay the higher effort to developers for introducing 64 bit precision all over the place. I have the impression, that currenty not...

I think it isn't my quote....

Isn't in fact 64 bit engines the norm today? This at least the case for the DAW:s I’ve used in the last 5-10 years

[Windows]

Deleted

[swilow11]

^Read the thread, OP has admitted to a misunderstanding