Bye bye VST2

[zvenx]

Screenshot 2024-03-16 at 11.29.15 AM.jpg

https://vi-control.net/community/thread ... st-5467447

rsp

[urosh]

https://vi-control.net/community/thread ... st-5467447

Makes sense, deprecating VST2 without migration path for their own customers would be atrocious. And their latest moves makes some sense in this context, ditching VST2 support without bunch of angry customers by forcing hand of everybody else on the market.

[eLawnMust]

HMMmm... Since I pretty much use VST2 & never VST3 & since there are still a billion VST2 out there no problem. Heck sometimes use sequencers just sample based with internal FX, the stone age is pretty cool>>>

[Funkybot's Evil Twin]

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?

Sounds like no. I threw in an FR here:

https://forum.cockos.com/showthread.php?t=289402

[Urs]

That's cool, thank you. We plan to update our existing VST2 plug-ins maybe one more time within the next year, before we throw them out of the installers. So, plenty of time for host developers to catch up.

On Mac btw. we also support the second option, which is a .json file. That might be supported a bit more IDK. If we wanted to do that on Windows, we had to deploy VST3 in a folder ("bundle"). I don't think many hosts support this, either.

[mi-os]

Things like plugin migration helpers are actually a good reason to move forward. If VST4 comes one day it should be able to automatically replace instances of VST2 and VST3 versions. I guess there is nothing like that in the VST2 SDK. To me it is important to ensure long term compatibility for old projects.

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

Sounds like no. I threw in an FR here:

https://forum.cockos.com/showthread.php?t=289402

Oh, okay.... Whatever method they're using seems to wrok quite well... ?

[jinxtigr]

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.

Well, as also a one-man band I will at least be able to take certain risks. I don't think they're really serious but the result will be of great interest to the industry, so I'm in with both feet.

I'm a legal VST2.4 user with a huge library of them on Mac, Windows and two different Linuxes, and in fact I'm providing code-signed modern Mac VST2.4s alongside more retro ones that also are compiled for PPC. Just the whole range. It's everything that isn't AU, for me.

I've got JUCE semi-working thanks to the 'Pamplejuce' project by Sudara, and that produces VST3s. Assuming I and the smarter people I know are able to get crossplatform VST3s made (possibly directly on GitHub), I'm going to release those… as GPL3 licensed open source. While continuing to support VST2.4, and while NOT signing off on the VST3 contract.

I consider this an effective workaround, as Steinberg presumably thinks GPL3 doesn't matter. My VST2 stuff is MIT licensed and does not include any SDK files, which gets in the way of people using it, plus they're actually not allowed to begin VST2 development if they're new. That's lame.

I will be observing with great interest whether Steinberg sees fit to harass, threaten, or otherwise obstruct me in these choices. Near as I can tell, that won't happen, and I will continue to put out VST2s because it lets me license my regular code under MIT, and will continue to be reasonably vocal about all this. After all, for some years now I've refused to put out VST3 or accept their agreement for it, because 'once they tried to retroactively take away the right to also do VST2 and support legacy users and machines'.

Well, once is today and forever, apparently.

CLAP is going to be the future. For now, I'll let you know if Steinberg hassles me in any way. I don't expect it, because GPL3 is a loophole, near as I can see.

[MrJubbly]

That's cool, thank you. We plan to update our existing VST2 plug-ins maybe one more time within the next year, before we throw them out of the installers. So, plenty of time for host developers to catch up.

On Mac btw. we also support the second option, which is a .json file. That might be supported a bit more IDK. If we wanted to do that on Windows, we had to deploy VST3 in a folder ("bundle"). I don't think many hosts support this, either.

Could you kindly let customers like myself and others know exactly what we might need to be requesting from our DAW developers, in order to help implement a more reliable "automatic migration" solution for plugins from developers such as u-he (and others), whose plugins don't currently migrate?

Ideally, a solution which would facilitate "auto migration" from VST2/VST3 to CLAP (if that is even a possibility). And if not, then at least reliable migration from VST2 to VST3, so that once the VST2 format is as dead as the Dodo, customers would still have the VST3 available. And could then work to manually migrate those VST3 instances over to CLAP ourselves in our existing projects (as and when, CLAP equivalents become available).

Because (with full respect intended), it's all well and good saying that there: "should be plenty of time for host developers to catch up." But, DAW devs are notoriously pre-occupied with their own insular "to do" lists and honestly won't likely pay much attention to this issue, unless many of their customer start demanding additional support for this.

And in order to do that, customers need to be better informed on what may be currently lacking in our DAWs and which alternative methods may need to be added, to facilitate reliable auto migration.

For example, my preferred DAW happens to be FL Studio, which (for several years now) already has one method of VST2 to VST3 automatic migration in place. Which works successfully, but ONLY for certain developers' plugins. Therefore, so as far as Image-Line are concerned, they will likely believe they already have that solution in place, and that it is plugin developers who need to conform to the method they already use ... unless of course, we can advise them otherwise, and ask them to support those alternatives.

Several plugin developers also currently support such "automatic migration" for VST2 to VST3, as is implemented within FL Studio. Developers such as Valhalla DSP, Sonic Academy, Applied Acoustics Systems', etc.

Meanwhile, many other developers' plugins currently don't support that method. Which includes the likes of u-he (albeit, admittedly, they never have claimed that they did). However, another developer who now claim to support migration is FabFilter, but thier plugins do not migrate to VST3 in FL Studio, despite FF recently announcing that they implemented a working VST2 to VST3 migration solution (apparently, their method is only currently working for Steinberg's Cubase, etc.)

Basically, it appears all of the DAW developers and the plugin developers are on completely different pages from one another so far as "migration" features go. And that they are working to implement separate methods for their own plugin migration, instead of all communicating together, or at least informing their customers more clearly on which methods their DAWs / plugins support, so that we can all understand what is going on and why only certain developers' plugins successfully migrate in certain DAWs.

It shouldn't be this complicated. We (the customers) just want our purchased products to work reliably and to remain accessible. To not be at the mercy of arbitrary plugin format discontinuances and subsequent incompatible plugin migration methods, with each of the DAW and Plugin developers apparently on completely different wavelengths to each other and not communicating together effectively for a unified solution.

[breathe...]

As such, it would be beneficial to know what other "automatic migration" methods are available and which customers might need to be requesting from DAW developers. Or perhaps, a helpful link to information/resources to point them towards.

I did receive the following feedback from Valhalla DSP's customer support, whose plugins all DO successfully migrate within FL Studio (under its current migration system).

Valhalla DSP Customer Support:
As far as automatic migration, I think that the Valhalla plugins benefitted from migrating to VST3 fairly late (in late 2020, to be precise). I use the Juce framework for my plugins, which a lot of plugin companies do, so porting to VST3 mostly involved hooking up to the latest VST3 SDK, downloading the latest Juce SDK, and enabling the VST3 build option. Which seems simple, but there are a few problems with this:

- The VST3 SDK is constantly changing. Which is weird, as VST3 is supposed to be a “standard.”
- Juce had their own VST2 implementation for several years, which had an incorrect VST Plugin ID generation (the bytes were out of order). So, if a Juce developer was building a VST2 and VST3, even if they supposedly shared the same ID, the DAW may not recognize it as the same ID. Juce has now pulled their VST2 implementation, so more recent builds might address this.
- VST3 plugin support is a shifting entity in DAWs. VST2s tend to work the same across all DAWs, but it is a crapshoot about whether or not the VST3s will behave the same across DAWs.

So, my guess for what is going on with other developers is that

- they name their VST3 builds something different, which is either intentional or accidental
- the VST Plugin ID has different formatting between VST2 and VST3, which is probably accidental.

I’m not sure how to fix the VST Plugin ID issue. I only have one plugin that was affected by this, a build of VintageVerb from 2018 or so. The latest VintageVerb builds match the older VintageVerb builds as far as VST Plugin ID, and the VST2 and VST3 plugin IDs match each other now.

TL;DR - Please help customers understand why only some developers' plugins successfully migrate within certain DAWs, while others do not. And if there are better solutions which can be implemented to improve this situation, then please also inform us what those solutions are, so that we can request for our DAW developers to offer better support for those specific alternative methods.

Thank you.

[Urs]

Meanwhile, many other developers' plugins currently don't support that method. Which includes the likes of u-he (albeit, admittedly, they never have claimed that they did). However, another developer who now claim to support migration is FabFilter, but thier plugins do not migrate to VST3 in FL Studio, despite FF recently announcing that they implemented a working VST2 to VST3 migration solution (apparently, their method is only currently working for Steinberg's Cubase, etc.)

That's the frustrating thing. We adopted VST3 early, and at the time there was no documented automatic VST2 to VST3 transition path. The one that was there is based on IDs and filenames, and it can't be changed retroactively. Which is why Steinberg added another. And then another. And then another. The last two ones are cool, and those are what I guess Fabfilter use and we do.

The fact that no DAW other than Steinberg's and NI's (for NKS) supports these things even though they have been around for years, is a bit telling, and extremely frustrating for those who actually wish to comply and fade out VST2 support.

The thing that we need all hosts to catch up with is called

IPluginCompatibility

[ampetrosillo]

The way I see it, Steinberg did something arguably illegal, and at the same time they "own" a standard, which will impact DAWs and plugin developers alike, and there is one way out, called CLAP (which is inherently safe from these shenanigans). Since only a few bootlickers (the only way you can define them, since they are literally supporting "a plugin standard" which badly behaves as a standard and has very little value in itself, apart from being by Steinberg) might stick with Steinberg, plugin developers and DAW developers should well unite (apart from Logic, ProTools and Cubendo, I assume) to actually deprecate VST (2 or 3, without actually removing VST support from the DAW but maybe in five years' time making it a little convoluted to install VST plugins, for instance having to add them manually) and support CLAP from now onwards.

[MrJubbly]

The fact that no DAW other than Steinberg's and NI's (for NKS) supports these things even though they have been around for years, is a bit telling, and extremely frustrating for those who actually wish to comply and fade out VST2 support.

The thing that we need all hosts to catch up with is called

IPluginCompatibility

Thank you for that. It is appreciated.

At least that is something tangible, to reference, when requesting the additional migration support from our DAW developers.

Hopefully, we can get a more reliable migration solution in place, for the foreseeable.

Until of course, we inevitably progress towards the eventual "CLAP only" future work environment, where all customers can finally put all of these silly Steinberg shenanigans from these past years, behind us, once and forever.

(well, for all of us who don't still use their own DAW, that is).

[machinesworking]

Have to say it, I wish the response 20 years ago to Audio Units being implemented, and that the only cross platform solution being VST2 that was hard enough to implement that DP and Logic, (owned by Emagic at the time), jumped at the chance to implement a one platform only solution like AU, I wish that is when people had come up with CLAP. Here we are 20 years later and it wasn't AU or VST2 that had people interested, but VST3 and Steinberg's poor mentorship of their own format that caused a valid format to come up.

So probably 20 years from now all my plugins will be CLAP.

[Greenstorm33]

Sorry if this was already discussed, but how does this affect hosts? Are they bound by the same license agreement?

[dayjob]

well, this was a long time coming. hopefully more developers move to CLAP after this.

yes please. end this VST stuff before it becomes even more nonsense.