Why is Steinberg working so hard to kill off VST2 when it works so well?

[mystran]

VST2.4 SDK is exactly 9 files.
VST3 SDK is a bloated monstrosity with over 700 files ! . There is absolutely no justification why a SDK for writing plugins, should force down my throat its own implementation of smart pointers, vectors, list, hash map containers, string classes, ....

This is actually the main reason I personally haven't even bothered downloading the VST3 SDK. Just briefly looking at the directory listing on Github has so far managed to convince me that it's just not worth it.

[BlueprintInc]

2/3 of the SDK you'll not even touch... It also defines classes in separate files which have been structs in a single file in VST2. Out VST3 adapter actually uses only the single component processor interface and the editor interface. Pretty similar to VST2.

[Big Tick]

How do you know it ever really existed then? It could be unfinished experiment that didn't work well.

Oh it would have worked just fine - it was a flag allowing you to define certain events as automation (as opposed to midi) events. These were timestamped just like midi events. Since plugins already need to split their processing loop across midi events boundaries (and implement smoothing if required), there you had it - sample-accurate automation, for free.

2/3 of the SDK you'll not even touch... It also defines classes in separate files which have been structs in a single file in VST2. Out VST3 adapter actually uses only the single component processor interface and the editor interface. Pretty similar to VST2.

Here's a more relevant metric then:
VST2 - 3.867 lines
VST3 - 162.877 lines

Please don't tell me that this is because VST3 has more comments.

[Holy_City]

>These were timestamped just like midi events. Since plugins already need to split their processing loop across midi events boundaries (and implement smoothing if required), there you had it - sample-accurate automation, for free

Forgive me if I'm not understanding you, but time stamped events are not sample accurate? Sample accuracy guarantees that all events arrive on the audio thread at the same moment (as far as the plugin can tell), which guarantees that the same sequence of inputs creates the same sequence of outputs at the same moments in time - the threading/timing model of the OS/DAW/plugin (ideally) wouldn't come into play.

One could argue that _all_ state changes (parameters, events, whatever) should arrive to the processor in the audio callback. VST3 allows for much better encapsulation, and if hosts implemented that properly, thread safety concerns would evaporate.

But that doesn't even touch on the real problems with VST2. The API is fundamentally unsound and provides no encapsulation or protection from data races. Support for complex/arbitrary channel configurations is virtually nonexistent (and what does exist is unsupported), meaning VST2 is worthless for anything but trivial stereo workflows.

That's not to say VST3 is perfect. It's bloated, it's complicated, it's difficult to even build without the massive 500MB SDK, it's poorly documented, the concepts are ill-defined (if at all), it tries its best to make you use the monstrosity that is VSTGUI, every minor version update contains breaking changes, it lacked fundamental features like MIDI CC for a decade, it's written in dense C++ and doesn't expose a C API/ABI making it impossible to access through any other language.

But none of that changes the fact that VST2 is 100% obsolete, and supporting its model forces design constraints on Steinberg that they probably don't want. It's time for a new plugin API, be it VST3 or whatever someone else comes up with.

[Big Tick]

Forgive me if I'm not understanding you, but time stamped events are not sample accurate? Sample accuracy guarantees that all events arrive on the audio thread at the same moment (as far as the plugin can tell), which guarantees that the same sequence of inputs creates the same sequence of outputs at the same moments in time - the threading/timing model of the OS/DAW/plugin (ideally) wouldn't come into play.

The timestamp is actually a frame stamp relative to the current processing frame. It defines exactly at which sample location the event should be processed by the plugin. It is sample accurate by definition.

But that doesn't even touch on the real problems with VST2. The API is fundamentally unsound and provides no encapsulation or protection from data races

This is something that could have been resolved by a clear documentation - "This method must only be called on the audio thread". Then any plugin / host that does differently is not compliant.

A plugin SDK defines a contract between the host and the plugin. It doesn't have to attempt to enforce the contract with hundreds of thousands of lines of code.

. Support for complex/arbitrary channel configurations is virtually nonexistent (and what does exist is unsupported), meaning VST2 is worthless for anything but trivial stereo workflows.

Again, it's more a documentation problem than anything. There was everything in 2.4 to implement it.

That's not to say VST3 is perfect. It's bloated, it's complicated, it's difficult to even build without the massive 500MB SDK, it's poorly documented, the concepts are ill-defined (if at all), it tries its best to make you use the monstrosity that is VSTGUI, every minor version update contains breaking changes, it lacked fundamental features like MIDI CC for a decade, it's written in dense C++ and doesn't expose a C API/ABI making it impossible to access through any other language.

At last we agree

[Fender19]

That's not to say VST3 is perfect. It's bloated, it's complicated, it's difficult to even build without the massive 500MB SDK, it's poorly documented, the concepts are ill-defined (if at all), it tries its best to make you use the monstrosity that is VSTGUI, every minor version update contains breaking changes, it lacked fundamental features like MIDI CC for a decade, it's written in dense C++ and doesn't expose a C API/ABI making it impossible to access through any other language.

Wow. And this is "better"?

[Vokbuz]

Oh it would have worked just fine - it was a flag allowing you to define certain events as automation (as opposed to midi) events. These were timestamped just like midi events. Since plugins already need to split their processing loop across midi events boundaries (and implement smoothing if required), there you had it - sample-accurate automation, for free.

How do you know it would have worked just fine if nobody used it? Guessing is not an argument. Also as I alredy wrote there is no point in sample accurate automation if it does not support ramping.

[EvilDragon]

Big Tick being a very good programmer is a good enough argument for me. That's not a guess he did there

Ramping is something that plugin can do itself, doesn't have to depend on the SDK at all.

[Vokbuz]

it's difficult to even build without the massive 500MB SDK

it tries its best to make you use the monstrosity that is VSTGUI

All of this is not true. All you need is pluginterfaces. Everything else is optional in SDK.

it's poorly documented, the concepts are ill-defined (if at all)

Same as VST2. How VST2 is not poorly documented?

every minor version update contains breaking changes

How is that possible?

it lacked fundamental features like MIDI CC for a decade

It still does not support MIDI. But this is not an issue anymore.

[Vokbuz]

Big Tick being a very good programmer is a good enough argument for me. That's not a guess he did there

Argumentum ad verecundiam?

Ramping is something that plugin can do itself, doesn't have to depend on the SDK at all.

1) plugin can’t do ramping itself on cross process boundaries
2) to do it itself plugin need to guess what change is instant and which is not

So no, plugin can’t do ramping itself. It can ramp inside but this is not the same as sample accurate automation with ramping.

[wrl]

Oh it would have worked just fine - it was a flag allowing you to define certain events as automation (as opposed to midi) events. These were timestamped just like midi events. Since plugins already need to split their processing loop across midi events boundaries (and implement smoothing if required), there you had it - sample-accurate automation, for free.

How do you know it would have worked just fine if nobody used it? Guessing is not an argument. Also as I alredy wrote there is no point in sample accurate automation if it does not support ramping.

You're also guessing here, as evidenced by the fact that you're not sourcing any of the points you're making. Let's establish some facts here so that we can all get on the same page.

In VST2.3, Steinberg added a constant to the VstEventTypes enum, kVstParameterType, ostensibly for transmitting sample-accurate parameter changes to a plugin. They deprecated it as of VST2.4, and the 2.4 SDK I have does not define a corresponding structure for what a VstParameterEvent would look like. Hence, we don't actually have any idea how sample accurate parameter changes would have looked in VST2 because Steinberg never actually implemented it.

That said, there was nothing preventing them from implementing it. The scaffolding is all there. They could even have done parameter ramping! There's nothing preventing it, they just didn't do it. Supporting parameter automation events certainly doesn't require throwing out all of the rest of the plugin standard.

Also, just as a note – for parameter ramping being such a killer feature, I can't find an implementation of the plugin-side behaviour anywhere. JUCE treats VST3 parameter events as discrete points, and so does iPlug2. Same case for both frameworks' AUv2 layers, and AUv2 explicitly supports ramped parameters with kParameterEvent_Ramped. For a little chuckle, also note this VST3 implementation from the recently-open-sourced Vember Audio Surge (the "Unclear what to do here" comment is where the ramped param handling would go).

I suspect the reason for this is that plugs should be smoothing/ramping their input params anyway, and good plugs have been for quite some time already. Having sample-accurate parameter ramps feeding into existing param smoothing makes the ramps fairly useless unless we're talking about huge block sizes (and even then I suspect it'd require some listening tests).

If anybody has implemented ramped param handling (or specifically decided not to), it would be really interesting to hear about it.

Nonetheless, not a very strong argument, and certainly not one that necessitates throwing out an entire industry standard API/ABI.

[Vokbuz]

You're also guessing here, as evidenced by the fact that you're not sourcing any of the points you're making.

Yes, I'm guessing. Not about possibility, but about the reason why this feature was removed. I do not know if it worked or would work.

That said, there was nothing preventing them from implementing it.

This is exactly a guess. You can't say whatever it is possible or not unless you really implemented it. All you can do is guessing whatever it is possible or not.

Also, just as a note – for parameter ramping being such a killer feature, I can't find an implementation of the plugin-side behaviour anywhere.

It is not the only reason why VST2 is old.

I suspect the reason for this is that plugs should be smoothing/ramping their input params anyway, and good plugs have been for quite some time already. Having sample-accurate parameter ramps feeding into existing param smoothing makes the ramps fairly useless unless we're talking about huge block sizes (and even then I suspect it'd require some listening tests).

If anybody has implemented ramped param handling (or specifically decided not to), it would be really interesting to hear about it.

There are plenty of reasons for that.

One of the reasons is the main audience of those libs - newbie developers. For them sample accurate parameter with ramping is too complex to get started (By the way this is one of the reasons I don't want to use JUCE, IPlug or any other existing lib). Sample accurate ramping parameters is too complex even for some experienced devs, this strikes me every time. In my plugin lib (it is not public) sample accurate automation with ramping is supported. When you have means to support it, it is not that complex.

Actually, Audio Units have to implement sample accurate parameter scheduling. auval checks for it. But even Apple gave up and don't use this in its DAWs because devs don't implement it properly or implement at all. In the end, this is a chicken and egg problem. DAW won't support it properly until some amount of devs support it and vice versa. New API solves it by providing single automation mechanism. For DAW all automation is sample or time accurate with ramping anyway.

Just to make it clear. I do not say that sample accurate parameter automation is good or bad. I just say that if it does not support ramping it does not make sense at all. Most of the time an automation is a smooth curve, not a set of instant changes. So host need to decide how to cut this smooth automation into a set of instant changes. The same can be achieved by using shorter audio buffers and you don't need to worry about whatever plugin support sample accurate automation or not. Because automation will be far from precise anyway.

Nonetheless, not a very strong argument, and certainly not one that necessitates throwing out an entire industry standard API/ABI.

Again, this only one of the features that VST2 doesn't have.

It is almost always possible to extend existing API. But if you do it constantly, API will become a trash in the end. I can't imagine what a mess it would be if all features from VST3 will be implemented in VST2 and what a nightmare for host it become to behave backward compatible.

[Vokbuz]

...

[bungle15]

Same flamin' way that Native killed off the pro 53
PROFIT!!!
For people who play music they try to destroy us
All they are interested now is selling samples and units with flashing lights which produce repetitive kids wind up toy music. The robot generation that one day will realise that life exists in the real world when it is too late.

[whyterabbyt]

Same flamin' way that Native killed off the pro 53
PROFIT!!!
For people who play music they try to destroy us
All they are interested now is selling samples and units with flashing lights which produce repetitive kids wind up toy music. The robot generation that one day will realise that life exists in the real world when it is too late.

Your hat needs more tinfoil.