Bye bye VST2

[0degree]

Guys, imho the problem here (at least for us developers) is not that Steinberg has deprecated a format per se or that they announced it ages ago.. but that's the WAY they decided to enforce that. Forbidding something by contract and retroactively is bad. To be honest, I don't even know if that's entirely legal but as a one-man-band I can't take the risk against a huge company like that one. The only sure thing to me, at the moment, is that CLAP will have more space in my development framework.

I think this is the best gift Steinborg could ever give for the whole CLAP initiative. It's perfect incentive for devs to switch to the open audio format and hopefully there won't be VST4 because nobody will care anymore

[Chicken Drummy]

(nevermind)

[jamcat]

It's weird how some people get shitty about this as if they're somehow personally affected by fair, legitimate complaints on VST2 vs 3 and how the transition is being handled. Do you work for Steinberg?

It doesn't affect you so it isn't a concern for you, right? Cool, congrats on that. But why the attitude toward those of us who speak out that are affected?

The people who say there is a problem with VST3 and the people who don’t use VST3 are the same people.

So why should anyone listen to the people with the least experience on the subject over those with the most?

[Urs]

§1.6 can be understood to exclude VST2 from the scope of the agreement as well.

The Agreement is very clear:

§1.6 This Agreement neither applies to the development nor the hosting of VST 2 Plug-Ins.

Yes, it does not include a license to develop or host VST2 plug-ins. That is the only thing that is clear about it.

This is a change from prior versions of the VST3 SDK license btw, which did include the VST2 SDK.

When we (well, our lawyer) inquired about it, Steinberg (well, their lawyer) confirmed that indeed §9 still terminates any prior VST2 SDK agreements. This is also not new, it's been in the very first VST3 SDK agreement we signed, which was maybe a decade ago.

It's even more obvious in the version from March 2021 btw. The intent has not changed, like I mentioned before, only the wording has become less obvious to laymen.

[AtomOfScent]

I've never really cared whether I was using a 64-bit VST3 plugin, or 32-bit DirectX plugin from last century (Reaper). For years, VST3 wasn't very compelling (many of it's new features were already DAW native) so I usually stuck with VST2 to avoid double hard drive space/clutter.

Now I install VST3 only unless I'd used VST2 in the past, but automatic VST2/VST3 migration seems like something that needs to be enabled by the plugin so it's quite annoying when developers release a minor version update where the main/only change is just dropping VST2 and deleting it from your HD during installation.

Unless the developer has fully tested migration with all DAWs they should leave VST2 versions alone without explicit permission. It's far easier to to manually match settings than deal with missing plugins.

[gaggle of hermits]

Unless the developer has fully tested migration with all DAWs they should leave VST2 versions alone without explicit permission. It's far easier to to manually match settings than deal with missing plugins.

I don't know how someone can read an entire thread like this and conclude "yeah, those pesky plugin devs, screwing with me for no reason".

Steinberg says no. lay your blame there.

[Audiority]

I've never really cared whether I was using a 64-bit VST3 plugin, or 32-bit DirectX plugin from last century (Reaper). For years, VST3 wasn't very compelling (many of it's new features were already DAW native) so I usually stuck with VST2 to avoid double hard drive space/clutter.

Now I install VST3 only unless I'd used VST2 in the past, but automatic VST2/VST3 migration seems like something that needs to be enabled by the plugin so it's quite annoying when developers release a minor version update where the main/only change is just dropping VST2 and deleting it from your HD during installation.

Unless the developer has fully tested migration with all DAWs they should leave VST2 versions alone without explicit permission. It's far easier to to manually match settings than deal with missing plugins.

The VST2/3 plugin formats are proprietary and the right to develop and redistribute products in these formats are tied to a licensing agreement we have to sign. If the owner of these formats say NO to something, we have to comply in order to keep doing business.

[Urs]

automatic VST2/VST3 migration seems like something that needs to be enabled by the plugin

It needs to be enabled by both the plug-in and the host.

VST3 offers 4 different ways to do that, but only the latest two are really good options, because the former two never really worked except for few plug-ins (one of those requires the VST2 plug-in to be installed, which is not an option when the license to publish VST2 plug-ins is terminated).

We have recently implemented what we think is the best option, which is called "IPluginCompatibility". It's a feature of VST3 that's been around for a while, but so far we have found only 2 host developers who support this.

[gaggle of hermits]

The people who say there is a problem with VST3 and the people who don’t use VST3 are the same people.

laydeez and gentlesirs, presenting today's random factoid pulled freshly from jamcat's behind

I'd ask for numbers but it was crickets on the previous two instances so I'm not exactly optimistic.

[mothra]

Awesome news. One less format I have to uncheck when I install a plugin now!

[urosh]

It needs to be enabled by both the plug-in and the host.
...

It seems to me that another and very shitty workaround could be to keep distributing last (published & legally publishable) VST2 version for some time (and I can't emphasis enough "shitty").

But one way or another, it seems that a lot of people (likely myself included, although I'm pinning my hopes on Reaper crew) will encounter lot of pain with management of old DAW projects.

Maybe thread/database on migratable plugins and hosts would be smart thing right now.

[gaggle of hermits]

I think the only thing you can do with any reliability is snapshot a setup in a virtual machine and have that to hand if you need to work out what settings or presets were used or maintain a dinosaur machine with an OS locked to an older version. the dinosaur option at least has the advantage of acting as a synth module for plugins that wind up dying out for any other reason.

[machinesworking]

The people who say there is a problem with VST3 and the people who don’t use VST3 are the same people.

So why should anyone listen to the people with the least experience on the subject over those with the most?

I use all three formats in DP11, and Live 12. VST3 is by far is the most problematic, in every way, the most prone to crashing or failing evaluation. I'm trying to use it more and more, because this day was coming, but 15 years later it's still "fun" for hosts to support it.

So plainly as someone else mentioned, you pulled this statement out of your ass.

[jens]

Quote instead of edit

[jens]

We have recently implemented what we think is the best option, which is called "IPluginCompatibility". It's a feature of VST3 that's been around for a while, but so far we have found only 2 host developers who support this.

One of them being Cockos, right?