What pros/cons are there in using the VST3 Serum over the x64 version, in Cubase?
I ask as I have many presets converted then saved in VST3 for both versions, it’s causing some weird muddles when trying to use the preset browsers and sound-browser.
Could appreciate some help on this.
Do you mean “VST2” version? “x64” refers to the CPU architecture, in this case 64bit as opposed to the older 32bit.
The pro of the VST3 version would be that it will still run with the next versions of Cubase, whereas VST2 has been obsoleted and probably won’t run with the next Cubase release anymore.
Thanks, I thought there would be more defined pros for VST3 TBH (I have looked).
I really hope they don’t phase out x64 plugins.
VST3 allows sidechaining
As was already said, “x64” has absolutely nothing to do with the VST version of a plugin. Eventually everyone WILL phase out x64 plugins, as soon as we move to 128-bit CPU’s.
Granted I was meaning x64 as in VST2, but aren’t VST3 plugins 64bit?
I don’t know what you are doing with your presets, you didn’t need to touch anything. When you installed the update serum would use the same preset folder.
Apples and oranges. x64 refers to the CPU architecture. x64 = 64 bit processor.
VST2.x plugins can be either 32-bit (which is now obsolete in Cubase) or 64-bit (still supported in Cubase 12).
You’ve misunderstood. This was about the conversion issues from .fxp to .vstpreset formats. MediaBay won’t allow me to open Serum presets except in the explicit Serum version they were converted in (either VST2 or VST3).
It has made a hard distinction between the VSTs versions of the same app. Notwithstanding that may be reasonable, it still though means I have near half of my presets that cannot fully work with the extract sound from preset feature/browser.
That’s because the VST2 and VST3 version of Serum were apparently build to be different versions of the same plugin with a different internal ID, for reasons only known to the developer. So for Cubase that means those are different plugins.
The best advice is to just don’t use vstpresets but only the internal preset mechanism of the plugin. Also helps if the developer decides to release a new plugin version that is session incompatible with the old one (i.e. new ID), them you’ll have the same problem.
This makes sense thanks.
Thing is I really struggle with Serum’s preset management, (it’s not a gripe post so I won’t list here but it’s pretty bad IMO). MediaBay, though not perfect, does have some flexible tagging options.
BTW I tried to edit the vstpresets flags/tags in SQLite, but nothing doing, they continue to open up one or the other versions of Serum. It’s probably related to a field I don’t have access to, unless someone wants to chime in and advise me how to circumvent this?
Maybe the confusion here is that, on Macs with ARM CPUs, there is no VST2 support.
So, on MacBooks and the like, you have “x64 == VST2” which can only run on Rosetta, and “ARM == VST3” which can run native.
On Windows, you have “VST2, x86 (32-bit)”, “VST2, x64 (64-bit)” and “VST3, x64 (64-bit)”
And that in turn is different from the 32-bit versus 64-bit processing actually done by the plugin. A VST2, x86 (32-bit) plugin can still do 64-bit sample processing.
Totally makes sense and no risk of confusion at all, right? 
Also, a lot of plugins do have “x64” in their filename to differentiate it from the old 32bit version. With VST2, that filename gets displayed as is in Cubase, with VST3, Cubase doesn’t care about the filename but uses some name property of the vst3 component.
You know right 
seriously though what can one say, I might get some joy reaching out to Xfer
Agreed. As has been inferred elsewhere, this can potentially lead to all kinds of confusion with project loads.
This alone is a significant reason to prefer VST3 (if possible) when choosing a plug-in. I am impressed nobody else mentioned it as the first reason.