New 64-bit Cubase 9.5 engine and Melda
-
- KVRist
- Topic Starter
- 353 posts since 27 Jan, 2015
Hi - How, if at all, will things be different going from Cubase 9's 32-bit engine to 9.5's 64-bit engine in terms of Melda plugins? (I use only the VST3 versions).
Thanks for any insight!
Thanks for any insight!
- KVRian
- 707 posts since 29 Dec, 2016 from India
i have been using reaper which has 64 bit mixing engine from long agoalexis1 wrote:Hi - How, if at all, will things be different going from Cubase 9's 32-bit engine to 9.5's 64-bit engine in terms of Melda plugins? (I use only the VST3 versions).
Thanks for any insight!
and i dont think it will cause any difference to the sound you will listen to
Technically speaking the rounding errors in a 32 bit engine should fall way below normal perception and going up to a 64 bit engine does not simply double the math headroom...it moves it up a logarithmic scale...
Basically in terms of a user experience and hearing math artifacts a 64 bit engine should not have ANY that you can hear...but in truth that applies to a 32 bit engine as well since the range of human hearing is a fairly known metric...
there will be a bit of difference when you will have a long reverb tail but then also you will have to increase the sound level and solo that channel
so just chill and dont worry until you get a issue or a bug......... peace
Win 10 x64 with specs enough to run DAW without bouncing any track
KZ IEM,32-bit 384Khz dac running at 32bit 48Khz
mainly use REAPER, MTotalbundle, Unfiltered Audio TRIAD and LION, NI classic collection,......... ETC
KZ IEM,32-bit 384Khz dac running at 32bit 48Khz
mainly use REAPER, MTotalbundle, Unfiltered Audio TRIAD and LION, NI classic collection,......... ETC
-
- KVRist
- Topic Starter
- 353 posts since 27 Jan, 2015
Great, thx, I wasn't even sure whether the plugins were all 64-bit to begin with.Apratim wrote:i have been using reaper which has 64 bit mixing engine from long agoalexis1 wrote:Hi - How, if at all, will things be different going from Cubase 9's 32-bit engine to 9.5's 64-bit engine in terms of Melda plugins? (I use only the VST3 versions).
Thanks for any insight!
and i dont think it will cause any difference to the sound you will listen to
Technically speaking the rounding errors in a 32 bit engine should fall way below normal perception and going up to a 64 bit engine does not simply double the math headroom...it moves it up a logarithmic scale...
Basically in terms of a user experience and hearing math artifacts a 64 bit engine should not have ANY that you can hear...but in truth that applies to a 32 bit engine as well since the range of human hearing is a fairly known metric...
there will be a bit of difference when you will have a long reverb tail but then also you will have to increase the sound level and solo that channel
so just chill and dont worry until you get a issue or a bug......... peace
-
- KVRAF
- 10310 posts since 2 Sep, 2003 from Surrey, UK
MeldaProduction plug-ins are available in 64-bit and 32-bit editions. But, that number indicates the technology used to build them. It is not the same as the audio signal depth; which is what the "the new pristine 64-bit floating-point mixing engine" uses.
I am pretty sure (but may have mis-remembered) that the MP plug-ins use 64-bit audio processing throughout, so the Cubase engine has caught up with them
This might help, too:
https://www.meldaproduction.com/text-tutorials/32vs64
I am pretty sure (but may have mis-remembered) that the MP plug-ins use 64-bit audio processing throughout, so the Cubase engine has caught up with them
This might help, too:
https://www.meldaproduction.com/text-tutorials/32vs64
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
DarkStar, I think they are talking about 64-bit processing, in the sense that host sends 64-bit samples. It's a bit confusing unfortunately and people often mingle these 2...
Anyways the plugins do not support receiving 64-bit samples as it is quite pointless. However the plugins internally use 64-bit processing whenever needed to provide optimum CPU usage and optimum audio quality at the same time.
Anyways the plugins do not support receiving 64-bit samples as it is quite pointless. However the plugins internally use 64-bit processing whenever needed to provide optimum CPU usage and optimum audio quality at the same time.
-
- KVRAF
- 10310 posts since 2 Sep, 2003 from Surrey, UK
^^^
Yep, that's what I meant, even if I did not explain it clearly.
Yep, that's what I meant, even if I did not explain it clearly.
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
Aaaaah, damn, if I had read it properly , sorry .
-
- KVRist
- 66 posts since 19 May, 2007
Yes, plugins often utilize 64-bit processing internally. And the new 64-bit audio engine has been introduced into Cubase to avoid the need for multiple back-and-forth conversions between 32-bit samples and 64-bit samples in the signal chain inside the DAW. Therefore, I think there is a valid point in making your plugins capable of receiving and outputting 64-bit samples. Computational resources needed for these conversions are in play as well. So, I wish you would reconsider this optionMeldaProduction wrote:Anyways the plugins do not support receiving 64-bit samples as it is quite pointless. However the plugins internally use 64-bit processing whenever needed to provide optimum CPU usage and optimum audio quality at the same time.
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
Actually I don't think it does give you anything really. Think about it - the accuracy of floating point samples is 24 bits plus exponent. So at any given sample, you have about -140dB accuracy below the actual value (I don't mean static -140dB, it's -140dB for each sample, so if the value of the sample is say 0.01, which is -40dB, then you can also represent about -180dB). If you try static listening test with changing sines between say 0dBFS and -60dBFS, in most cases the lower one would pretty much appear silent. Try this in MOScillator to check yourself:
So the resolution of human ear is reaaaaally poor, and our monitoring equipment isn't much better.
Now what we are talking about is rounding error below -140dB then. Statistically that would sound as white noise at -140dB below the local maximum, which is actually pretty pleasant, and there's more noise in just about everything . And if you are performing such a brutal distortion, that would bring this up to -60dB, where it would potentially could be audible, then any such detail is loooooooong gone in the distortion itself. I don't think any other process than a brutal distortion would even be capable of this. Now, when's the last time you tried +80dB drive . If you did, you know how that ended up. I unfortunately did that, not willingly . The results weren't very useful .
So no I'm afraid, I'm not really going to change my mind, sorry. It looks good as specs, but it's absolutely pointless. Maybe once the hardware becomes better and humans grow huge ears .
Code: Select all
$eNrtWNtu4zYQfc9XCHqPraslA7YXzsWbAHGSWsa2feRKjMVGIrUSlct+fWeoi2k7SVM0+1AgDhCZw+GZ4XDmcOTJl6c8Mx5oWTHBp6Y9sEyD8lgkjG+mZi3vjkPzy+xosrypYpZlRIqyolLCbGWcChAUFU1WbJPKW8JpNjVh-angsoQ5AD3n5HtGEyW+WkVFxqSkZcR+UhuMOd54X+xMzZEF0iV5ulrcnGQivkfx1HQd0yhISXIKmqeUy0qB9qKz8nlXsCjpjxq28oy7ci3bcsbjsT8aaSo3sSQPdA-olsk43RVFNGdS8H3N36kEbF3AEqmWziZRSgpqLEUCrl+LMieZaTyQrIahD9Pn-IFmAjTOSvIIwWwUceGtYFwai4xsqhNA91xzeCgEL55AfeD4poH7e0snaHSOX1RylZKaGnY+gfOSFsalpLmlMkJ9TCWwEWhH4uyruAcq3r6Kf6Ay2lcJdlTQoTNaNMFVI9Q5FTWHEwjR+5uClkRCDlezybokvLqDoP9zdF8Mit0GpQ-tsEecTeY5Zmud0H9lBQGP7TcO4tDmoSEQ6tscqhzD2rw8u1xRKMshDKBqYA7+W0ZffACrVQPkw25eKgMMSqoRn-OU8JgmuJEus69YJW-LxsZWaizqLFsRvoFVnmn08mt4TE0oD9NoZ63BKHSDwHFcdxxC0n1rSsEa2EEQOsHYsy3La8UnJL6vC5x07ZHjBMFoZNlBX1MfdaZN9CbD3uuZHshthS6AycQjLRuDV2JDSibTnMWw4VL8RWOpknJFM0oqumY5bTSXhNcQXUBFcDwTCogJDGIg0SWYULvFLzsza+RVUU7NxWLkWdZiYXaqa2OeFSnByPhtYfSq+AEBqF7yopaPwGuYMtoSZ3-JFn3YuThPHtTRG3Mp4RRwmQUxa0bNthakgmOd11K0O44Kqgh+AIptxkUsoacpYVxF-JaS+wuRJXqYWv12tETN7aRu6LWwGqtldEX5RlGCcrI3ev5Dv3V68dfOn14Cd8xiajotxWjS31SIdRnjSlMTQZ4IjsFSHGsFUEZpSeltCt4uWAbxVDeo1cirtAnAwMVyq2kTD7sZwFbw+2xyWldS5E20353sr14Ahyl-gN+Z7I7yl9nUDUAhb49qNvlakiKdTQqFpJ-cjzayNgZXPheq+h6jlGZ3pvEHXhiBMwZq8Bz4M40-G2cvSJkLzuIKjSvQd2JjmipcZ2D7oR04oe+E9ofi+uEo8DxAdcN34L6F5ULK+67tBxb0NB-oozvwPDcMA-DQd-477gU0htsDcwdh4Hh+6I8CbPHeAB+2STEvIWuwF2Q5NIEr8Vj17K2n0LDjrZ0uBtm8Z-F5jLfmzd3d1IykKIwKMjyjZifnKCal3MrPotWa5oWInnk8NWGhqZOi041URqvtn9GYPHdkpAb6XEaa9rQnwss8pwkjkm4ZcYcdnX60hYlyIWTa8UoEldVx2p6r2APRHIj+sw39bEN-dRuqpxr2ElrZgZ91wkSfZu9pmPT7Uq3+f7VQw50dzybQACcib0uwKeCdxhEPAd84keX6Jn1FoZChKPreCqsHCOo7y9hPFfiOaHaaC3ViEdtwkr1c87b9WfSfRf8h754qy+C44M4xukbcUYvx3bN5VPA+qv0YhK+n10LSPdGyziTr38IaUVtMl3w5bNpFfN7UEh-qV5YliEVdxsgp9E7vt9GFTgVWYCXjaK0Xuqpa4xurGHQv7SJV9IfM8ZLWC9Tgv04N6H6MrYoGblkj7xC813yPgRZi2O1yvctkh+htMN4B3a7XaO0Ivh3+Ajg7+huVAilk
Now what we are talking about is rounding error below -140dB then. Statistically that would sound as white noise at -140dB below the local maximum, which is actually pretty pleasant, and there's more noise in just about everything . And if you are performing such a brutal distortion, that would bring this up to -60dB, where it would potentially could be audible, then any such detail is loooooooong gone in the distortion itself. I don't think any other process than a brutal distortion would even be capable of this. Now, when's the last time you tried +80dB drive . If you did, you know how that ended up. I unfortunately did that, not willingly . The results weren't very useful .
So no I'm afraid, I'm not really going to change my mind, sorry. It looks good as specs, but it's absolutely pointless. Maybe once the hardware becomes better and humans grow huge ears .
-
- KVRist
- 66 posts since 19 May, 2007
Yes, I understand these arguments But despite them, you mentioned that even your plugins sometimes utilize internal 64-bit processing... So, why?
Then, the reasoning goes further: if even you use 64-bit processing, why not extend it to the whole signal chain to avoid multiple conversions? Let's say we have a DAW project with a channel strip containing 8 chained insert FXs, each of them working 64-bit internally. In a standard 32-bit DAW engine, this yields the necessity to perform 8-times the 32->64 conversion and 8-times the 64->32 conversion. On the other hand, in a 64-bit DAW engine there could be just one conversion at the beginning of the signal chain and one conversion at the end. Of course, it can work this way only if each used plugin accepts 64-bit samples on its I/O. And that's my point!
Then, the reasoning goes further: if even you use 64-bit processing, why not extend it to the whole signal chain to avoid multiple conversions? Let's say we have a DAW project with a channel strip containing 8 chained insert FXs, each of them working 64-bit internally. In a standard 32-bit DAW engine, this yields the necessity to perform 8-times the 32->64 conversion and 8-times the 64->32 conversion. On the other hand, in a 64-bit DAW engine there could be just one conversion at the beginning of the signal chain and one conversion at the end. Of course, it can work this way only if each used plugin accepts 64-bit samples on its I/O. And that's my point!
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
Hehe simple - 64-bit processing would mean rewriting the entire engine, plus existing optimizations for important parts could be completely lost. So it's not a work for a day, not even for a month. And the benefits? Zero!
Now why some internal processes use 64-bit? First an example, where it is pointless - gain. Gain is a simple multiplication. While 64-bit multiplication would get you better accuracy, it wouldn't lead to any enhancement as I explained before. Now where it does matter for example - IIRs - infinite impulse response filters have potentially infinite decay and hence there needs to be some (or multiple) accumulator for some temporary state, which can go very low, while the output can still be high. Also the coefficients used internally may be very small. In other words, this time we may be working with numbers going easily as low as -100dBFS while processing 0dBFS signal.
Btw. the conversion 32<->64 is very very cheap compared to cache misses triggered by 2x as large data blocks 64-bit processing would require.
Now why some internal processes use 64-bit? First an example, where it is pointless - gain. Gain is a simple multiplication. While 64-bit multiplication would get you better accuracy, it wouldn't lead to any enhancement as I explained before. Now where it does matter for example - IIRs - infinite impulse response filters have potentially infinite decay and hence there needs to be some (or multiple) accumulator for some temporary state, which can go very low, while the output can still be high. Also the coefficients used internally may be very small. In other words, this time we may be working with numbers going easily as low as -100dBFS while processing 0dBFS signal.
Btw. the conversion 32<->64 is very very cheap compared to cache misses triggered by 2x as large data blocks 64-bit processing would require.
-
- KVRist
- 66 posts since 19 May, 2007
Okay, Vojtech, now I got it I thought that your whole internal architecture already used the 64-bit floating point. In such a case it would suffice to enable the 64-bit input/output. But now it's a different story... So it's good to know since I use your plugins almost exclusively, therefore, I can just leave my Cubase set to the 32-bit engine. Thanks for the clarification!
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
My pleasure . And don't worry, you really don't miss anything .
-
- KVRAF
- 1671 posts since 11 Nov, 2009 from Northern CA
OK, question from the peanut gallery ...MeldaProduction wrote:Btw. the conversion 32<->64 is very very cheap compared to cache misses triggered by 2x as large data blocks 64-bit processing would require.
If the DAW is already forcing the signal to be 64-bit, how is it you will introduce additional cache misses by avoiding a conversion at every plug-in interface boundary? The doubles are already there in memory because that's what the DAW had decided it's what is best.
Noel Borthwick, the head tech guru of Cakewalk (RIP) wrote a very informative paper a few years back about the advantages of a 64-bit transport (data-depth, not address size). SONAR was the first, I believe, to venture into these waters. I looked for it the other day and think it may no longer be available. To bad ... it would really be of use to folks trying to understand what the Cubase move will mean to them.
-
MeldaProduction MeldaProduction https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=176122
- KVRAF
- 14019 posts since 15 Mar, 2008 from Czech republic
Not really. It's rarely as simple as "host sending a buffer and the plugin processes it into another buffer also supplied". There's usually lots of weird transformations, temporary buffers etc. So having everything in 32-bit it's definitely advantageous.