Well this is a kick in the nuts: VST2 plug-ins

[lkjb]

When you sign the current version of the agreement, they automatically terminate your existing agreement whenever they decide to update the agreement to something else. If you sign this, you have to sign whatever they put in front of you, or you lose your investment in the format.

From the VST3 SDKs that I have the clause appeared at first in 3.5.2 from 25.09.2012 (date from zip filename) so it probably applies to most developers who signed the agreement after that date. It doesn't exist in 3.5 but than again one might only be allowed to use the VST3.5 SDK. I have no idea what changed afterwards as there doesn't seem to be a changelog or the changelog is well hidden.

[mutools]

A big difference between MIDI and an open plugin format is that most hardware manufacturers had an interest in connecting different devices as there was not much alternative for customers. With DAWs and plugins, users are used to different formats and most commercial devs cover all common formats. So there's no real pressure from the customer side as shown by Logic and Pro Tools, each only supporting one format.

So if we would think about a new format, then we need to make sure it has added value, innovation, something users want. I have some ideas but i'm not sure if it's a good idea to talk about them in public. Maybe it would be interesting if we could talk about this whole topic more privately with people that trust eachother.

[Urs]

A big difference between MIDI and an open plugin format is that most hardware manufacturers had an interest in connecting different devices as there was not much alternative for customers. With DAWs and plugins, users are used to different formats and most commercial devs cover all common formats. So there's no real pressure from the customer side as shown by Logic and Pro Tools, each only supporting one format.

So if we would think about a new format, then we need to make sure it has added value, innovation, something users want. I have some ideas but i'm not sure if it's a good idea to talk about them in public. Maybe it would be interesting if we could talk about this whole topic more privately with people that trust eachother.

I'm thinking the same. Mostly though because discussions about plug-in formats easily get into details that are not really important. Like, some people like dispatchers, some people like C++19, some people want to bind to Rust, but all that isn't really important while designing the API. Instead, what's necessary is having a very small team of people who know both sides (hosting + plug-in) and work out something that fits a vision. All other sorts of things (Does it do JUCE? Will it work with x11?) can be taken from there.

[Hanz Meyzer]

If you design a new plugin format, you also could take care of an useful preset format, for example human readable, content searchable by the daw already, standardized, so not every single vst vendor does their own preset managing and file format. With standards like tagging, categorizing, named by the user. Could be XML or JSON, then you could even store it into a database easily.

The preset managing should happen either in the DAW, or another plugin type, the "preset manager type" (which actually is NOT a plugin host, but can give load commands to the daw), so you could exchange the preset manager, the plugin and the host individually.

Also, what about per-voice fx? Is this a thing? Wouldn't this be interesting in combination with MPE?

[Urs]

Hehehe, sorry, but IMHO putting so much burden on the site of the aspiring and existing plug-in manufacturer is guaranteed to make a new format fail. If existing plug-ins can't be transitioned easily (like, substantial change to align effects instantiation and routing to MIDI channels), adoption rate will be too low to start with.

I think preset management is a big thing nowadays and it can be unified in parallel to existing plug-in APIs.

[ghettosynth]

Furthermore, I think this industry is far beyond where synth manufacturers were in 1982 when they founded the MIDI Manufacturers Association. An industry wide standard should be controlled by a body like that, composed from multiple players, not from a single company or a plain open source project.

After all, maybe, we all can help Steinberg to end VST2.

In some ways, being 'far beyond'. is probably a disadvantage;

I think so. In many ways the opportunity to do this was missed. VST is the midi of plugin formats. That it's not open doesn't change the fact that it provided a way for independents to build instruments and effects that worked with multiple hosts. IOW, VST solved the same problem that midi did. You have to admire Steinberg for having the savvy to keep it closed. The MMA (not to be confused with MMA) was formed from the Steinbergs of their day. It wasn't accepted without resistance though, Oberheim had their own system. I find it a bit interesting that Roland was 850 pound gorilla with vision at the time as they too had their own protocol but felt that proprietary standards were a limitation for the industry.

It seems like an uphill battle. You need larger host devs to get involved in order to gain any traction, but I'm not sure that they see this as the big problem that smaller plugin devs do.

I don't think that time is on your side here. I think that coming up with a spec is the easy part, coming up with a strategy for adoption that will actually succeed is a different story.

[syntonica]

The problem I find is that a lot of this format hand waving, I don't want to deal with. For my part, I just want to fill in a couple of methods and call it done, whether I plug my code into VST 2, 3, or VST X. I spend too much time on tedious implementation details (yawn....) and not enough time on the good stuff (DSP, optimization, architecture, etc.) I would go for something like JUCE or IPlug, but between licensing issues and just plain overkill, I don't find them viable options. Plus, their developers must still work through the pain of harmonizing the plugin formats into a single one. Maybe if I stripped down IPlug to its basic essentials...

One thing I don't believe that's been touched on are the vestigial methods in VST 2 that handle keyboard and mouse content, file handling, etc. Unfortunately, hosts don't seem to support any of these features, at least none that I've tried. (90% Mac dev here.) This brings me to my point: how much of the burden should be placed on the host to implement features vs the plugin?. Having the hosts handle a lot of this obviates the need for massive cross-platform coding that can get hairy.

Finally, for any format, there should be strict definitions of which features are mandatory, which are optional, the exact requirements for data in and data out. When I first started, I used an open source VST as my model and pretty much just replaced the code. Big mistake since this plugin's take on how VST 2 worked was completely wrong!

There's too many different interpretations of VST 2 by hosts by far. Some interpretations are actually malicious, some just seem incompetent, and some seem plain ignorant.

</random thoughts>

[Urs]

Well, thing is, apparently some plug-in developers are already in the situation that they can not continue to publish VST2 plug-ins, and I heard first hand encounters of rather aggressive letters coming from Hamburg. They've built up leverage to say "if you want to continue to support VST3, you have to give up VST2". It's a pretty volatile development of license agreements.

However, I guess next to no-one can do that, drop VST2 in a hurry, some people might even violate other contracts if they did so, and they'd certainly get a harsh reaction from their user base. I personally have no idea how many thousands of our own customers would lose a decade or two of projects that won't open anymore.

A simple solution would be a VST3-to-VST2 adapter. So instead of delivering a VST2 plug-in, those developers could license an adapter which exposes their VST3-plug-ins as VST2 ("Plug-In XY now comes with VST2 adapter by Z, because we don't do VST2 anymore"), much like 32Lives. However, that model is doomed because whoever builds such an adapter will also lose their option to do so soon.

Therefore, a simple and open plug-in format which can be adapted either way (Plug-2-VST2, Plug-2-VST3) is the easiest solution for everyone who wishes to (or has to) continue to support VST2 and VST3. That alone might be incentive enough to adopt such a format, and building such an adapter may be a great business model, removing the burden of volatile licenses from developers.

[S0lo]

I have never seen LV2 specs. From what others tell me, this isn't easily happening, i.e. there seems to be pain involved. I guess the "V2" means there's legacy baggage?

Exactly, its LADSPA Version 2.

i also had only a superficial look at it but that made me a bit like : oh no! 513 kb in 107 files in 24 folders. many of them .ttl files - i don't even know what that is. why can't we just have a simple single .h file with less than 100kb? vst2 proves that this is totally feasible. why all this overengineering?

Yeah, I looked at it yester. it looks very linuxy. Which I'm an idiot at. I wanted to look at the docs but it seams you need to compile some python doxygen thing?

Still I don't want to dismiss it from the face of it. Looking at the reference, they seam to have done some hard work. Is there any one here who used it on Windows ?

After all, maybe, we all can help Steinberg to end VST2.

[Music Engineer]

Yeah, I looked at it yester. it looks very linuxy. Which I'm an idiot at. I wanted to look at the docs but it seams you need to compile some python doxygen thing?

Still I don't want to dismiss it from the face of it. Looking at the reference, they seam to have done some hard work.

indeed. i'm also currently looking at it more closely and more seriously. maybe the apparent complexity is justified by the feature set. and it actually doesn't seem so bad after all. quite to the contrary, actually. all these many files are rather small and contain mostly only #defines and also a lot of comments. and the .ttl files seem to be just metadata. i was a bit scared when seeing things like "DynamicManifestGenerator" in the api documentation. what the hell is that supposed to be and do i really want something like that in a plugin api? but i suppose, these more complex features are strictly optional. i get that static manifest files are used for plugin descriptions - to tell the host about the plugin's I/O configuration, parameters, etc. and that seems to make a lot of sense to me. ...but does that mean that whenever something about the plugin's configuration changes, i have to dynamically generate a new manifest file (not necessarily on disk)?

the docs are available online:

http://lv2plug.in/ns/

you don't need to compile anything. for what its worth, i've started collecting a little textfile (still very incomplete) where i gather the things from the documentation that seem most important to get started:

https://github.com/RobinSchmidt/RS-MET/ ... outLV2.txt

perhaps, lobbying for more widespread adoption of LV2 could indeed be the most realistic way out of this dire situation.

[ghettosynth]

Yeah, I looked at it yester. it looks very linuxy. Which I'm an idiot at. I wanted to look at the docs but it seams you need to compile some python doxygen thing?

Still I don't want to dismiss it from the face of it. Looking at the reference, they seam to have done some hard work.

indeed. i'm also currently looking at it more closely and more seriously. maybe the apparent complexity is justified by the feature set. and it actually doesn't seem so bad after all. quite to the contrary, actually. all these many files are rather small and contain mostly only #defines and also a lot of comments. and the .ttl files seem to be just metadata. i was a bit scared when seeing things like "DynamicManifestGenerator" in the api documentation. what the hell is that supposed to be and do i really want something like that in a plugin api? but i suppose, these more complex features are strictly optional. i get that static manifest files are used for plugin descriptions - to tell the host about the plugin's I/O configuration, parameters, etc. and that seems to make a lot of sense to me. ...but does that mean that whenever something about the plugin's configuration changes, i have to dynamically generate a new manifest file (not necessarily on disk)?

the docs are available online:

http://lv2plug.in/ns/

you don't need to compile anything. for what its worth, i've started collecting a little textfile (still very incomplete) where i gather the things from the documentation that seem most important to get started:

https://github.com/RobinSchmidt/RS-MET/ ... outLV2.txt

perhaps, lobbying for more widespread adoption of LV2 could indeed be the most realistic way out of this dire situation.

I can't speak with much authority, I've only ever written a few LADSPA plugins and they were for an embedded system so much of the distribution issues were irrelevant. However, this is, in part what I'm alluding to above re time not being on the side of a new format. I think, right now, for some cases, LV2 seems like a decent choice in terms of promotion. Unless some of the larger smaller devs really put their weight, read money, behind a new format then it's likely to fizzle on the vine.

One can gripe about the LV2 format, but nobody likes standards, except their own.

[polac]

A simple solution would be a VST3-to-VST2 adapter. So instead of delivering a VST2 plug-in, those developers could license an adapter which exposes their VST3-plug-ins as VST2 ("Plug-In XY now comes with VST2 adapter by Z, because we don't do VST2 anymore"), much like 32Lives. However, that model is doomed because whoever builds such an adapter will also lose their option to do so soon.

This adapter exists since years, I'm currently working on it again, some bugfixing and some new features. I also got requests from VST3 devs to bundle the adapter with their plugins. It's realized as a shell VST.

https://www.xlutop.com/buzz/zip/vst3shell.zip

if you want to continue to support VST3, you have to give up VST2

Didn't read the new license agreement, however we had a license to still do VST2. It's pretty annoying if it is that way now.

[Music Engineer]

One can gripe about the LV2 format, but nobody likes standards, except their own.

yes, i agree. and i'm actually beginning to like it. looks all quite clean and consistent and well documented so far. perhaps the abandonment of vst2 by steinberg is just what it needed to finally catch on.

edit: for example, in one of the readme.txt files, it says:

Parameters are accessed and manipulated using messages sent via a sequence port

that is a really good design decision. no more worrying about receiving parameter changes on a different thread than the audio processing is running in. having to synchronize "process" and "setParameter" was really a quirky thing in vst2

[S0lo]

for what its worth, i've started collecting a little textfile (still very incomplete) where i gather the things from the documentation that seem most important to get started:

https://github.com/RobinSchmidt/RS-MET/ ... outLV2.txt

Thanks. Browsing through it

Finally, for any format, there should be strict definitions of which features are mandatory, which are optional, the exact requirements for data in and data out. When I first started, I used an open source VST as my model and pretty much just replaced the code. Big mistake since this plugin's take on how VST 2 worked was completely wrong!

There's too many different interpretations of VST 2 by hosts by far. Some interpretations are actually malicious, some just seem incompetent, and some seem plain ignorant.

I agree. This is a pitfalls of VST since its start. ie. "No proper documentation", means different interpretations. And leads to nasty type of testing, guessing and trial and error to figure what this DAW does and this one doesn't.

Someone may also say that there can be a conflict of interest from Steinberg's part here since they make their own DAW. It may not be very lucrative for them if all other DAWs knew exactly how the standard works. Hence, "poor documentation". When I say poor, I'm coming from the Microsofty side where each and every function, struct and topic has its own extensive page of description. Tens of 3rd party books available to learn from.

Now to be fair, Steinberg did update and improve on the documentation only very lately.

[ghettosynth]

So here's a talk from Filipe Coelho that was given three days prior to the VST2 license deadline from Steinberg. He gives a shoutout to Uhe re: VST3 and Linux and talks about the good and bad of the various formats. One of the downsides that he mentions is the lack of manpower. With some solid contributions from established small devs, perhaps LV2 could move forward with some of the ideas he presents towards the end. In particular, these ideas revolve around removing cruft and modernizing the metadata.

At the end he also talks about the dearth of examples for Windows and Mac. IMHO, that's an area where established small devs can foster adoption of an open standard.

It's not a very technical talk, so apologies if this is old news.

Filipe's Site
https://falktx.com/

The Talk
https://www.youtube.com/watch?v=1DJ5aEU-JkA