Please make PatchWork with 64 bit processing support for Mac.
Now patchwork truncate my 64 bit processing plugs(DMG Audio,Slate) to 32 bit in Cubase 10 and Studio One
PatchWork with 64 bit processing support for Mac
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981 - KVRAF
- 5820 posts since 8 Sep, 2004 from Paris (France)
-
- KVRer
- Topic Starter
- 10 posts since 26 Sep, 2004
-
- KVRer
- Topic Starter
- 10 posts since 26 Sep, 2004
The interest of 64 bit float is not about "headroom" / "dynamic range"...
pro:
no need to convert between 32 bit and 64 bit float: 64 bit is needed by some plugins for their internal computations. 64 bit then means: small performance gain and no precision lost between succeeding 64 bit plugins.
Better audio precision when mixing audio signals. I explain this at the end of this message.
If audio devices ever go beyond 24 bit precision, 64 bit float will be needed (because 32 bit float means, in fact, 24 bit precision)
con:
requires more memory, which can mean a performance lost (more memory to move). But as soon as a sophisticated plugin is used, this one is likely to become the bottleneck, compared to the memory overhead. Therefore, this is a "relative con".
64 bit CPU instructions are as fast as 32 bit instructions, because the CPUs are 64 bit today. But certain rare instructions are faster with 32 bit float, because the CPU can conjugate 2 of them while in the same time, only one 64 bit instruction is performed (SIMD).
Now, an explanation about 32 bit float vs 64 bit float, for mixing.
While 32 bit float means in fact 24 bit precision, 64 bit float means in fact 48 bit precision. This means, far more precision.
I can illustrate this difference with elementary school maths (this is an analogy of what happens in reality).
Let's say samples can have only values 0, 1, 2, 3, 4, 5,...
Let's start with a sample that has value "3"
An audio gain of "divide by 2", is applied. We get the value "1.5", but this value is not allowed hence must be rounded, eg. the new value becomes 1.
Later another gain "multiply by 2" is applied. The new sample becomes "2".
Consequence: we started from value "3" and ended up with value "2", while the two gains should have cancelled each other.
When this kind of loss is performed multiple of times (complex mixing), then errors stack up.
The consequence is not dramatic, because some errors are (randomly) compensated by others (round-down / round-up), but this compensation actually means "digital fog" aka noise.
64 bit float processing pushes the digital fog far from the 24 bit domain. Hence a cleaner result at the end of the audio chain.
The difference 32/64 is therefore about "audio definition", if your ears can sensible enough. But that's another topic!
Philippe
pro:
no need to convert between 32 bit and 64 bit float: 64 bit is needed by some plugins for their internal computations. 64 bit then means: small performance gain and no precision lost between succeeding 64 bit plugins.
Better audio precision when mixing audio signals. I explain this at the end of this message.
If audio devices ever go beyond 24 bit precision, 64 bit float will be needed (because 32 bit float means, in fact, 24 bit precision)
con:
requires more memory, which can mean a performance lost (more memory to move). But as soon as a sophisticated plugin is used, this one is likely to become the bottleneck, compared to the memory overhead. Therefore, this is a "relative con".
64 bit CPU instructions are as fast as 32 bit instructions, because the CPUs are 64 bit today. But certain rare instructions are faster with 32 bit float, because the CPU can conjugate 2 of them while in the same time, only one 64 bit instruction is performed (SIMD).
Now, an explanation about 32 bit float vs 64 bit float, for mixing.
While 32 bit float means in fact 24 bit precision, 64 bit float means in fact 48 bit precision. This means, far more precision.
I can illustrate this difference with elementary school maths (this is an analogy of what happens in reality).
Let's say samples can have only values 0, 1, 2, 3, 4, 5,...
Let's start with a sample that has value "3"
An audio gain of "divide by 2", is applied. We get the value "1.5", but this value is not allowed hence must be rounded, eg. the new value becomes 1.
Later another gain "multiply by 2" is applied. The new sample becomes "2".
Consequence: we started from value "3" and ended up with value "2", while the two gains should have cancelled each other.
When this kind of loss is performed multiple of times (complex mixing), then errors stack up.
The consequence is not dramatic, because some errors are (randomly) compensated by others (round-down / round-up), but this compensation actually means "digital fog" aka noise.
64 bit float processing pushes the digital fog far from the 24 bit domain. Hence a cleaner result at the end of the audio chain.
The difference 32/64 is therefore about "audio definition", if your ears can sensible enough. But that's another topic!
Philippe
-
- KVRAF
- 2357 posts since 24 Nov, 2012
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 5820 posts since 8 Sep, 2004 from Paris (France)
We indeed have a bit of math and audio processing background, so we know what you are talking about. 
While 64-bit processing is definitely a must-have for many operations internal to plug-ins (recursive operations for example), the full 64-bit processing chain in hosts is hardly noticeable, and is mainly used as a marketing tool. I have yet to find someone who can actually hear the difference... And that's probably also the reason why Pro Tools is still using 32-bit floats.
Another thing to take into account is that many operations are still done with 32-bits floats, even in plug-ins that claim "full 64-bit" (typically for optimized vectorized operations). And many plug-ins will actually add noise to avoid issues with denormal numbers... All in all it's probably not the most important thing to consider in your processing chain.
Anyway, supporting 64-bit processing in our plug-ins that also operate as hosts is a bit of work, as you have to perform conversions for plug-ins and hosts that do not support it, and it will probably have an impact on performance. We currently prefer to focus on other features that add more value to most our customers (in our point of view). Like stability and ease of use for example. It does not mean it won't happen, but there are other things that seem more important to us at the moment. I hope you understand!
While 64-bit processing is definitely a must-have for many operations internal to plug-ins (recursive operations for example), the full 64-bit processing chain in hosts is hardly noticeable, and is mainly used as a marketing tool. I have yet to find someone who can actually hear the difference... And that's probably also the reason why Pro Tools is still using 32-bit floats.
Another thing to take into account is that many operations are still done with 32-bits floats, even in plug-ins that claim "full 64-bit" (typically for optimized vectorized operations). And many plug-ins will actually add noise to avoid issues with denormal numbers... All in all it's probably not the most important thing to consider in your processing chain.
Anyway, supporting 64-bit processing in our plug-ins that also operate as hosts is a bit of work, as you have to perform conversions for plug-ins and hosts that do not support it, and it will probably have an impact on performance. We currently prefer to focus on other features that add more value to most our customers (in our point of view). Like stability and ease of use for example. It does not mean it won't happen, but there are other things that seem more important to us at the moment. I hope you understand!
-
- KVRAF
- 1790 posts since 13 May, 2004 from Germany
snake oil...
