Steinberg Discontinuing VST2 Support in its products

[SparkySpark]

I'm not going to pretend I am smart enough to understand half of this conversation, but can anyone explain why steinberg is so dead-set on killing a stable and universally accepted format in exchange for a format that hadn't been able to become the industry standard despite existing for well over a decade now. I am struggling to understand what they have to GAIN in this situation. Especially as I see a shockingly large amount of people threatening to leave Cubase.

Yes it may seem quite weird. I think you will understand the situation better by reading my post and Dewdman42's reply on page 23. What I was assuming, Dewdman42 confirmed.

[anttimaatteri]

steinberg does have support?

Yes, as long as you’re not a troll.

metatroll,
please! ^^

[Music Engineer]

Except, support for replacing VST2 needs to be in the initial version of your VST3 plugin. This isn't something you can implement later. So, since I never implemented it in the first version of my VST3 plugin, my VST2 users will never be able to upgrade their projects to VST3.

So my options are:

Enable VST2 to VST3 replacement. Now my VST3 plugin will be a 'different' plugin to hosts and all existing projects will be broken.

Not enable VST2 to VST3 replacement. Everybody with a VST2 project will be broken.

Any developer who got into VST3 early when it was still buggy and didn't want users automatically upgraded will be in the same situation. What a mess, for no good reason.

steinberg could actually fix this situation by introducing a way of asking a vst3 plugin what its old vst2 id was (defaulting to "same as vst3 id", if the plugin doesn't implement the feature). perhaps it should also be able to inquire a bit more than the old vst2 id...maybe old filename, plugin-name, vendor-name, etc. just in case some host wants to use these also for plugin identification. yes, it may fatten up the vst3 API with a little bit of historical baggage but this is what happens to APIs when they have a history. perhaps single new callback like getVst2LegacyInfo() in the vst3 API would be sufficient

[Music Engineer]

Believing Clap as a format will usurp it is almost like believing Linux will one day surpass Windows in the number of users.

actually, linux already is the dominating os in the worlds of servers, embedded systems and mobile devices (android is a linux derivate). nasa's mars rover runs linux, too. not that it matters in this context, but it's cool anyway linux is just struggling in the desktop/laptop market. i think it's mainly because of inavailability of some essential software and some user experience issues (mostly its reliance on command-line interfacing). at least, these are the two main reasons, why i'm myself still on windows. these things are improving slowly but constantly.

edit: oh: and windows has far superior font-rendering compared to both linux and macos. i'm not sure, if that will ever change. probably not. but when i finally get a hiDPI display, it probably won't matter anymore

[syntonica]

edit: oh: and windows has far superior font-rendering compared to both linux and macos. i'm not sure, if that will ever change. probably not. but when i finally get a hiDPI display, it probably won't matter anymore

Hmm, not that I've ever seen. You have perhaps pix of the same TTF rendered on the same hi-def screen? Nudge, nudge, wink, wink, say no more! Say no more!

[Sahul]

steinberg could actually fix this situation by introducing a way of asking a vst3 plugin what its old vst2 id was (defaulting to "same as vst3 id", if the plugin doesn't implement the feature). perhaps it should also be able to inquire a bit more than the old vst2 id...maybe old filename, plugin-name, vendor-name, etc. just in case some host wants to use these also for plugin identification. yes, it may fatten up the vst3 API with a little bit of historical baggage but this is what happens to APIs when they have a history. perhaps single new callback like getVst2LegacyInfo() in the vst3 API would be sufficient

As an user suffering from this issue, this is actually a great idea Steinberg should implement ASAP. This would make the VST2>VST3 transition much easier.

[chk071]

This is going to break a lot of peoples projects once Cubase can't load VST2 plugins. Steinberg's stance is that VST3 plugins can replace VST2 plugins, so users just need to upgrade to the latest version of the plugin that has a VST3 version and everything will be ok.

Except, support for replacing VST2 needs to be in the initial version of your VST3 plugin. This isn't something you can implement later. So, since I never implemented it in the first version of my VST3 plugin, my VST2 users will never be able to upgrade their projects to VST3.

So my options are:

Enable VST2 to VST3 replacement. Now my VST3 plugin will be a 'different' plugin to hosts and all existing projects will be broken.

Not enable VST2 to VST3 replacement. Everybody with a VST2 project will be broken.

Any developer who got into VST3 early when it was still buggy and didn't want users automatically upgraded will be in the same situation. What a mess, for no good reason.

Thére's no need for this kind of angst. So far, the only DAW which is officially known to drop VST2 at some point (and it's not even clear with which future version) is Cubase. If you own a Cubase license, and upgrade to a VST2-less version, you still have access to former versions, and you can install those versions side by side for older projects. Same with Studio One. I'm not sure about other DAW's, but, that's really distant future talk.

[Dewdman42]

steinberg could actually fix this situation by introducing a way of asking a vst3 plugin what its old vst2 id was (defaulting to "same as vst3 id", if the plugin doesn't implement the feature).

Supposedly it does this already. But not all plugins use the same id... and not all VST2 plugins are even available in VST3 with or without matching id....so..it will be hit or miss. I suspect there will be a lot of complaining about this when Cubase13 drops. After a while the noise will stop.

And even the way VST3's respond to some forms of midi automation, for example, is likely to be not quite exactly the same..resulting in different playback. Its not going to be a perfect translation to the VST3 version of each plugin...even if the id's do match.

The best option will be for people to keep their old version of Cubase and the plugins around just in case.

[zvenx]

.....

The best option will be for people to keep their old version of Cubase and the plugins around just in case.

Yep.. I still have Nuendo 6.5 32 bit on my PC and Cubase 10 (the last one to be able to use Alchemy on mac without a black GUI) on mac installed for this reason.


(edit: just realised Cubase 10 does allow me to use Alchemy and Cubase 9.5 does has graphic glitches with Big Sur, off it goes)
rsp

[Widowsky]

.....

The best option will be for people to keep their old version of Cubase and the plugins around just in case.

Yep.. I still have Nuendo 6.5 32 bit on my PC and Cubase 9.5 (the last one to be able to use Alchemy on mac without a black GUI) on mac installed for this reason.

rsp

This is not a permanent solution. Sooner rather than later, Steinberg will turn off the servers that run their dongle-based authorisation system.

[andypryce]

Maybe after 24 months VST4 is coming

[zvenx]

.....

The best option will be for people to keep their old version of Cubase and the plugins around just in case.

Yep.. I still have Nuendo 6.5 32 bit on my PC and Cubase 9.5 (the last one to be able to use Alchemy on mac without a black GUI) on mac installed for this reason.

rsp

This is not a permanent solution. Sooner rather than later, Steinberg will turn off the servers that run their dongle-based authorisation system.

The dongle doesn't call home though....what will probably more likely happen is an OS update (more likely mac) that will break it.

rsp