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

[mystran]

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.

What developers should do is drop support for Steinberg. Put a run-time check into all plugins to detect if it's running inside a Steinberg host and pop a messagebox informing the user that Steinberg no longer wants have an open VST ecosystem and that your plugin will therefore refuse to load, but can still be used in non-Steinberg hosts normally.

[ghettosynth]

...

[Eduur]

Last year I wrote A VST3 Plugin Interface for Delphi. (Sorry about that).
Because I allready had a lot of plugins created, I made an adapter from VST3 to my own plugin needs. I think, you developers, do something alike everytime, and it is also what e.g. Juce and IPlug do. The adapter class consists of about 20-30 methods. I placed the result on github inclusive adapters for VST2 and FruityPlugs.
As an example I created a small plugin which had some parameters and some DSP code (single osc synth) and had the same codebase for all formats.

Now, why I am you telling this...

Well, I don't want to introduce a new plugin format!

But with all the talk about LV2, I think that could be a good solution. Reaper allready supports it.
I think it allready is also allready build in Juce.
And I now see a few people trying to implement it. And what I miss (and I hope someone will lead me to that) is a simple environment under Windows. So, that would be something like what I created for my Delphi Interface:
1. Just a plugin project, which you can compile and 'run'.
2. Some documentation on how it works and where you can extend the examples.

I am not interested in generated documentation from Classes, because I don't have the overview what they do.
I figured it out from VST3 and it was a PITA, even if the documentation was quite good.
Normally if I need to find out how a function works, I am not interested in lengthy parameter descriptions, I just want some examples)

You will say: It's already there, but as a few of you already mentioned, 'It's very Linux oriented'.

So I will rephrase my wishes:

1. A plugin project, maybe a few more, in a Visual Studio Solution format, which I can compile and immediately run under Reaper. No cmake or whatever other pre-steps.
2. Documentation in PDF format which only address the plugins and not much more.

Is it somewhere? I would be delighted to push the F5 button and run it under Reaper! From there, I will find my own way... And you have one extra person supporting LV2

[Urs]

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

Yay

Would you be open to discuss a port to macOS?

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.

Yes, the annoyance is real:

https://github.com/steinbergmedia/vst3s ... eement.pdf

as of this morning contains this:

"§9.7 Any and all prior VST2 and/or VST3 Plug-In SDK Agreements between Steinberg and the Licensee shall be automatically terminated by signing this Agreement."

[Urs]

(we can't upgrade to this because we have contracts to develop VST2 plug-ins for a long time ahead)

[Eduur]

I know this question has been asked before, but still I am puzzled:
What is so unique about VST2 that Steinberg can force us to not use it.
I mean, you can recall just rename all the functions an there you go.
We developers do this all the time: Just create wrappers around wrappers around wrappers.
Now, offcourse I do not mean to copy everything literelly, but a few persons could get together
and just define the 30 most needed functions 'adapted' from VST2.4 but 'vastly improved to the 2020s'. And, there is no need to look at the rest of the VST2.4 SDK, it's all quite trivial.
No extentions, no discussions about MPE, preset support, Cache lines, just the VST2 spec: MIDI, Parameters, Audio.
And while you're at it, get away with the single function pointer and create a decent DLL interface.
If you have someone who wrote a Host for 2.4 and someone who wrote a Plugin, you could give a working example within a week.
After that, see what you have got (see my previous post).
I could create the Plugin, but I have no 2.4 C++ example (should be small offcourse).
Who wants to join, reply to the post and tell what you could do. Or shoot it :}
Do you think it is a gray area?
I don't think so: Most of this knowledge is available in e.g. Bass (Unseen Developments) and also Mystran proposed something new/alike.

[Urs]

The Talk

That's a good watch.

It would be interesting to know if 2 1/2 years after this, the problems they identified with LV2 have been addressed.

[Urs]

What is so unique about VST2 that Steinberg can force us to not use it.
I mean, you can recall just rename all the functions an there you go.

I guess many developers are afraid that switching too a reverse engineered version of VST2 still exposes them to legal threats or other forms of sanctions from Steinberg.

[Vokbuz]

I mean, you can recall just rename all the functions an there you go.

VST2 API does not have methods or functions.

[Eduur]

I think you know what I mean, and in fact, this is the time to implement a broad interface with functions instead of magic numbers. Ofcourse a C interface and no methods or COMlike stuff

[Eduur]

What is so unique about VST2 that Steinberg can force us to not use it.
I mean, you can recall just rename all the functions an there you go.

I guess many developers are afraid that switching too a reverse engineered version of VST2 still exposes them to legal threats or other forms of sanctions from Steinberg.

I think so too. But it is ridicilous:

Here's my interface a plugin should implement (except creation)
(forgive my bad C, its Pascal, ha ha)
[ BTW. I am doing a lot of embedded programming in c and C++, but just have a lot of legacy Pascal stuff...)

type IXPlugin = interface
procedure SetEditor(form:TForm);
procedure AddParameters;
procedure Process(const Inputs,Outputs: TDAVArrayOfSingleFixedArray; const SampleFrames: Cardinal);
procedure SetSampleRate(rate:single);
procedure OnParameterChanged(Sender: TObject; const Index,Value: Integer);
function ParamCount:integer;
procedure Close;
procedure SetTempo(tempo:single);
procedure ProcessMidi(Sender: TObject; MidiEvent: TMidiEvent);
procedure LoadFromStream(stream: TMemoryStream; index: integer; isPreset: boolean);
procedure SaveToStream(stream: TMemoryStream; index: integer; isPreset: boolean);
function GetFormClass:TFormClass;
end;

and this is what a plugin needs from the host:

type IXPluginHost = interface
procedure SetCurrentProgram(prgm:integer);
procedure updateHostParameter(Index:integer; Value: double);
procedure AddParameter(id:integer;displayname:string;min,max:integer;def:single;units:string;customparameters:string='');
procedure DoMidiOut(midiEvent:TMidiEvent);
end;

Ofcourse, waaay incomplete (now only 20 functions), but closely related to 'VST', and if all are implemented as 'just functions' there's really no connection to VST2 or 3. In fact, it is much better.
I am sure you all have something alike and it has not much to do with re-engineering. Why don't a host writer and plugin writer give it a try?

I'd gladly help, certainly after this kick in the nuts...) (But am also looking forward to LV2...)

[Vokbuz]

I think you know what I mean

TBH, I don't.

[Music Engineer]

But with all the talk about LV2, I think that could be a good solution. Reaper allready supports it. I think it allready is also allready build in Juce.

no, unfortuntaley not and the juce team doesn't seem to be too interested in supporting it anytime soon. see here:

https://forum.juce.com/t/juce-lv2-plugi ... r/14209/90
https://github.com/juce-framework/JUCE/issues/123

apparently, they consider it as just "yet another plugin format to maintain" (no actual quote, just paraphrasing the general vibe of the responses), totally disregarding the (in my humble opinion, very important) fact that it is actually the *only* viable unencumbered, non-proprietary format. one can only hope, that the situation will change soon in light of these recent events. there's a 3rd party add on...well supposed to be - but where is it actually?

https://github.com/DISTRHO/JUCE/tree/ma ... rmat_types

i don't see it there. am i blind? is it in a different folder? also, it's not yet integrated into the projucer.

[Music Engineer]

I think you know what I mean, and in fact, this is the time to implement a broad interface with functions instead of magic numbers. Ofcourse a C interface and no methods or COMlike stuff

we already discussed the pros and cons of dispatcher/opcodes vs specific callbacks here:

viewtopic.php?f=33&t=548620&start=64

in my opinion, the dispatcher approach is clearly preferable due to easy extensibility and lean ABI and less boilerplate on the plugin definition side. "magic numbers" are just set up in some enum or #define once and for all in the interface header. i don't really see any issue with that. plugin- and host implementors don't see or use magic numbers, but descriptively named compile-time constants

[Urs]

the dispatcher approach is clearly preferable due to easy extensibility and lean ABI.

I feel the complete opposite. A dispatcher requires everyone to maintain some kind of big enum that has to be in sync on all sides and thus requires quite a process & committee to get extensions adopted. It also means, the standard constantly grows, whereas the beauty of optional extensions is that the SDK itself remains small & steady. Extensions such as NKS, ARA or ODD MTS could be implemented inside the standard without pushing them onto those who don't need them.