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.
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.
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?
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.