New 64-bit Cubase 9.5 engine and Melda

Official support for: meldaproduction.com
Post Reply New Topic
RELATED
PRODUCTS

Post

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!

Post

alexis1 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!
i have been using reaper which has 64 bit mixing engine from long ago
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

Post

Apratim wrote:
alexis1 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!
i have been using reaper which has 64 bit mixing engine from long ago
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
Great, thx, I wasn't even sure whether the plugins were all 64-bit to begin with.

Post

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
DarkStar, ... Interesting, if true
Inspired by ...

Post

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.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

^^^
Yep, that's what I meant, even if I did not explain it clearly.
;)
DarkStar, ... Interesting, if true
Inspired by ...

Post

Aaaaah, damn, if I had read it properly :D, sorry :D.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

MeldaProduction 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.
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 option :wink:

Post

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:

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
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 :D. 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 :D. If you did, you know how that ended up. I unfortunately did that, not willingly :D. The results weren't very useful :D.

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 :D.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

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! :wink:

Post

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.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

Okay, Vojtech, now I got it :wink: 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! :)

Post

My pleasure ;). And don't worry, you really don't miss anything ;).
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post

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.
OK, question from the peanut gallery ...

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.

Post

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.
Vojtech
MeldaProduction MSoundFactory MDrummer MCompleteBundle The best plugins in the world :D

Post Reply

Return to “MeldaProduction”