Namespace Problems: VST and M1 compatibility


East West has finally released an M1-compatible version of their plugin “EW Spaces”

Also Kilohearts has recently updated their software and it works really well now with Cubase.

Time to switch over to M1 Native Mode after a year of waiting…or so I thought.

When I try loading older (Rosetta Mode) projects that use the Kilohearts snapin plugins, it gives me an error message, that the plugin was not found. Instead, I have to empty the insert slot and load the plugin once again - the M1 version of it seems to have a different namespace.

The same thing happens with the EW Spaces plugin, unfortunately.

Upon asking East West about the problem, I received the following response:

Update for Case 149277 - “EW Spaces II VST Namespace”

Hey Robert,

The issue with this is that they are two entirely different plugin files.

The Rosetta version of Spaces II that was loading up in Cubase would have been the regular VST, but the M1 native version that loads up in Cubase is the VST3

Unfortunately, this is Cubase’s decision not to allow regular VST plugins to show up in the M1 native functioning Cubase 12, so to load any old projects you would have to run it in rosetta, then new projects going forward could be M1 native (that or entirely re-instantiate and load up spaces plugins in each that are the VST3 version).

Can anyone at Steinberg elaborate why this is such a problem and why can’t we just load up our old projects without issues? Other plugins work fine, including “Phaseplant Synth” and OPUS - by the same software vendors who had to create two different VST files for the M1 compatibility to work properly.

Sounds to me both parties are kinda stuffing this onto each others plates here - is it possible to work together and fix this?

Thanks so much!


Are both the VST2 and the VST3 plugin the same version (i.e. no major version difference?)
The possibility of VST3 plugin transparently replacing their VST2 counterparts in Cubase exists, and as you noticed, it works with several plugins.
Your suspicion that it has to do with “namespaces” is spot on, although in VST speak its the plugin id or “class id”. Cubase has always used those to differentiate between plugins. VST2 ids are 4 bytes long, VST3 32 bytes (iirc), but a plugin developer can convert the VST2 id to a VST3 id to make it compatible. But even if the id isn’t identical, in the newest VST3 sdk there is another way to explicitly configure old ids that are compatible with the new version.

If you have both the VST2 and the VST3 installed, and you see them both in Cubases’ plugin selector dialog (when using Rosetta of course), then that is exactly the problem, and it’s the responsibility of the plugin developer.

Yes you are correct.
I will forward your info to the EW people. Let’s see what they say :stuck_out_tongue:

We have VST, VST3, AAX, and AU Spaces 2.5 plugins available with that version.

Things you made with VST will never magically convert to VST3 - yes, on the developer end, we can edit a VST plugin to become VST3 (and have) but that doesn’t change how Cubase loads each instance of the plugin.

I don’t think this is going well :smiley:

It is just annoying. The developers are basically stepping on each others feet with this nonsense and we, the users have to live with the inconveniences because of it.

All I need is some tool that converts the settings I had and puts them onto a new insert slot with a newly selected plugin of my choosing

Unless there is some specific Mac-related weirdness going on there that I might not know about , I would call bullsh#t… as you also noticed, there are other plugins that seamlessly and transparently handle the VST2/VST3 transition, including full session compatibility.
But as it is, it seems your only option is to load the projects with Rosetta, go through the plugins and save each as a preset in their native preset format (NOT the Cubase one) and then go and open native and load the VST3 versions with the presets.
Very annoying, I had to do that, too, for several plugins I own…

Here is Kilohearts’ reply to the issue:

Hi Robert,

Very sorry about the long wait here. Is it possible it’s the same issue with our plug-ins as the others you mentioned? Do you have the VST2 versions of our plug-ins installed? You can enable/disable plug-in formats at any time from within the Kilohearts Installer by clicking the cog symbol in the top right corner and changing plug-in formats from there.

Best regards / Linus @ Kilohearts

Not sure if they are reading their support emails thoroughly? It looks to me like nobody gives a damn, honestly. Sad reality of platform changes.