Is that a limit of VST2 or is it like how Steinberg chose to cripple VST2 in Cubase compared to other DAWs, like they did with regards to external sidechain functionality for example? (i.e. SC input in all DAWs other than Cubase work as ‘normal’, with standard routing, but Cubase only lets you do that with VST3 versions. For VST2 they force you to use a tedious workaround using multiple tracks.)
I think Steinberg are the last of major DAWs to move to a 64bit audio engine, but is this different since it has the VST3 only aspect, (and only certain plugins at that), which i’ve never heard of being an issue in any other DAW.
From what I can see in that “read”, not all VST3s fully support 64 bit floating technology and none of the VST2s do. In that event, Cubase 9.5 will render them to 32 bit floating automatically. In that event, it seems Steiny is inclusive rather than phasing out VST2.
My guess is that the other DAWs probably have some kind of VST bridging that either allows VST2s into the 64bit environment or not at all. I don’t have experience with other DAWs in this respect so my guesswork is standing on your words.
From past experience with Cubase, the bridging technology sometimes caused problems and that is probably why Steiny now steers clear of it. I would thing that bridging also entails background processing that creates a larger footprint and uses more processing power.
I am open to correction on this.
What’s it doing differently to every other DAWs 64bit audio engine though?
My guess is that the other DAWs probably have some kind of VST bridging that either allows VST2s into the 64bit environment or not at all. I don’t have experience with other DAWs in this respect so my guesswork is standing on your words.
From past experience with Cubase, the bridging technology sometimes caused problems and that is probably why Steiny now steers clear of it. I would thing that bridging also entails background processing that creates a larger footprint and uses more processing power.
I am open to correction on this.
It’s nothing to do with 32bit vs 64bit plugins in terms of coding.
Yes, and maybe I’m using the wrong terminology but the 32bit vs 64 is more of an analogy than a direct point. There has to be some kind of coding for VST2s to function in a 64bit floating engine. Maybe you can suggest a couple names of the other DAWs you speak of so I can be brought up to speed on their architecture.
Thanks barryfell.
As I reread Steiny’s breakdown on this technology, it seems that what is and is not processed in 64bit floating is not related to VST2s or VST3s.
It merely states that whatever is not supported in that environment will be processed by 32bit floating and that included unsupported VST3s.
Now, what it did mention about VST2s is that they will not be supported by the “double” precision floating system which I assume is yet another field of this 64bit floating technology. Don’t know yet what differentiates the two but I’m still learning this curve.
I can see why you came to that conclusion based on the wording, but at the beginning it states 64bit audio processing is double precision, then later that no VST2 plugins can use double precision, (and only those VST3 plugins that support it), so my question is still as it was in the OP regarding what the difference between Cubase’s new 64bit floating point audio engine and the likes of Live’s which can only process VST2 plugins as it doesn’t support VST3.
Anyone else care to chime in? This is all new ground for me.
I also read up on the fact that some people don’t even rely on the 32bit floating technology because in most cases, exports are being dithered to 24 and 16 bit anyway for publishing media. Higher bit rates in the DAW gives bigger headroom for VST instrument and effect stacking and is good for exchanging files from studio to studio. Outside the DAW environment, there’s been little usage for larger than 24 bit files.
I’m sure he does, but his responses don’t clarify much for me:
That sounds like it could lower CPU load, but doesn’t 64-bit processing increase it?
What question is he asking here? Or is there a typo and he’s simply repeating the same thing as earlier? It’s hard for me to tell.
So Steinberg justifies it from a marketing point of view (though I’m surprised to see a Steinberg rep explicitly promote deception as an acceptable marketing tool, see their promo material, “takes your sounds to new heights”, etc.), but really I’m only interested in whether it will adversely or positively affect my system (CPU-wise, and potentially otherwise). As there’s no trial yet, I will try to get a sense of that from the forums.
I see from the vids you can turn off the 64-bit processing and toggle to 32-bit. That makes me wonder if there are circumstances where 64-bit would be worse?
I tried both and so far the 64Bit audio engine is performing at least as good if not a tiny bit better on the projects I have tried.
I did not expect nor do I hear any differences, but that would take a ABX test to verify.
I guess I could render out a few projects in the two audio engines, and compare in their delivery formats (44.100k@16bit).
But I see no reason not just to use the 64Bit engine and forget about it.
I’m reading and seeing no adverse effects by using the 64bit floating technology so it seems we could only benefit to future changes. Like previously mentioned, there is less processing because of no upsampling to double precision and truncation on both sides of the insert process. What’s not to like there.
The only downside of this upgrade that I have seen/read is the problem with gui color personalization.
