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

[Deep Purple]

The headline is much more about sensationalism than reporting fact though. They didn't elaborate on why her account was banned other than she was violating the forum terms she agreed to when she signed up (as would happen to anyone here).

It doesn't take away from the fact that Apple is giving advice that turns out to not be correct, but when third-party repairs invalidate the warranty on a phone, I can see why they would not direct people to her service.

[Vertion]

This world is first and foremost made of people. People can only relate with some form of relationship and trust to each other.

Companies are made of people, and so are their customers, employees, and vendors. Companies seek trade units called currency from people.

If the company hurts its relationship with it's customers, employees, supporters, or vendors, it will suffer loss of trade units. Companies that lie, steal, cheat, or use and abuse their customers and then try to hide behind frivolous technicalities or cite some arbitrary or chalked up agreement will not survive for long. You don't keep your customers, or supporting developers by attacking and threatening them. A short term game at best.

The VST standard was adopted upon the trust of good hearted developers that trusted that standard would remain intact. Steinberg has violated that trust, and it is felt most deeply by many developers. Steinberg is not only damaging themselves, but the entire VST industry with their superfluous ambitions.

Steinberg has been blind and callous, and attacked those that gave VST a market in the first place. We will not forget.

[Vokbuz]

OK, let's accept the premise VST2 was obsoleted by Steinberg.

All I'm saying is that VST2 is old regardless of Steinberg's actions. It was a matter of time when this will happen.

But for me, the whole point is not letting a single company like Steinberg dictate what is obsolete or not, not to let a single company arbitrarily obsolete a industry standard pretty much every one not associated with Steinberg was happy with.

By obsoleting VST2, Steinberg created a advantage for themselves, and disadvantaged direct competitors, as Steinberg sells exactly VST2 plugins and VST2 hosts.

I don't want to say Steinberg's action are good for everyone. But they do what they can and what they think is good. If community failed to provide and accept free and open standard, this situation is no surprise.

There is a famous quote: If you want to make enemies, try to change something. I'm pretty sure if VST3 were flawless and perfect in every aspect there would still be unsatisfied people. Just don't let yourself become luddites.

[Skupje]

Sample accurate automation sounds pretty cool.

But how outdated is it still? These features are ok like having function calls for UI parts. But I'm much more aligned with having two procs doodled on a napkin. I'm totally fine using threaded software, so I found ways of having constructions limitting thread usage "redraw limiters" so even sample accurate is not really cutting it.

[Benutzername]

If you want to a build a decent USB keyboard in this day and age then it would be hard to sell if it doesn't have CV, gate and sync outputs and maybe even the same set as inputs. Of course it needs to have at least one MIDI in and one MIDI out port and analog inputs for dampers and expression pedals.

The keyboard layout has to have the same layout as the first pianos and the drum buttons must use the same pad style as the first drum machines or it won't sell. The control wheels have to work like old synth control wheels and the DAW controls will have to look like ancient tape recorder buttons or it won't sell.

At the end the keyboard will most likely run over a class compliant USB 2 connection (while technically even a USB 1 connection would be enough) and all physical controls will communicate with the DAW by using simple MIDI messages from the 80s. At the lowest USB level it will even use plain serial communication exactly like the computers did 60 years ago.

Why all this old and obsolete shebang from the last millennium if USB C, wireless expression pedals, speech and gesture control, specialized proprietary drivers, note expression, OSC and so on are much more modern and thus so much better in every regard?

Because it just works.

Maybe I'm old fashioned but something like "Siri, play a wide Csus4 chord around C3 on channel 7 for 317ms with a velocity of 73 percent and damper half way down" still doesn't feel right to me (at least it's still hard for me to get the timing right). But ok, this seems to be the way to go when all the old and obsolete things are removed from our studios.

Back to VST. For me it is simple: If VST3 is really so much better than VST2 then all developers would have switched to VST3 many years ago. Developers don't have a problem to throw old things away if the new thing performs significantly better. They never had. Back in the day they just had to add VST3 as another option among others (AAX, AU, RTAS etc). As a result VST2 most likely would have been gone by now just like VST1 did shortly after VST2 was released.

This didn't happen for a reason. Letters from lawyers will not suddenly make VST3 the better standard in any way. The only use theses letters would currently have is to hurt Steinberg's reputation a lot. Threatening partners and customers is never a good thing in the long run and it will hit them back at some point sooner or later.

[Deep Purple]

The VST standard was adopted upon the trust of good hearted developers that trusted that standard would remain intact. Steinberg has violated that trust

Was there some kind of legal agreement or terms of service that outlined that upon adoption the standard would remain intact?

If Steinberg has violated an agreement with developers then there is a case for legal action.

[Vokbuz]

If VST3 is really so much better than VST2 then all developers would have switched to VST3 many years ago. Developers don't have a problem to throw old things away if the new thing performs significantly better.

This statement needs some kind of prove. For me it is false. I do not know any API change where developers adopted it without resistance and with good will. Every time the update is forced by an old API deprecation by the vendor. Nobody wants to throw away the code in which they invested lots of time and money.

They never had. Back in the day they just had to add VST3 as another option among others (AAX, AU, RTAS etc). As a result VST2 most likely would have been gone by now just like VST1 did shortly after VST2 was released.

Are you saying there is no real problem implementing VST3? Just add this option and stop supporting VST2 option. The reality is: adding new API is a necessity not an option. Nobody would do it if it won't expand plugin audience. There are plenty of plugins that support only limited API set.

VST2 most likely would have been gone by now just like VST1 did shortly after VST2 was released.

VST1 and VST2 are basically the same APIs. VST2 just introduced new opcodes. Most of VST1 opcodes remain in VST2.

[Big Tick]

VST3 is the future, thank God for Steinberg developing this - and now is open source! Check this out...

https://www.steinberg.net/en/newsandeve ... -4165.html

We have released version 3.6.7 of our software development kit (SDK) for VST. This update comprises several new additions that will improve the overall experience when using and developing VST instruments and processors.

The SDK update includes a preview version for Linux as well as a new license model, which allows developers to create open-source VST 3 plug-ins and distribute them with VST 3 source files. CMake has been implemented to control the compilation process and the VST 3 SDK is now also available through GitHub.

About VST 3

VST 3 is a general rework of the long-serving VST Plug-in interface. It is not compatible with the older VST versions, but it includes some new features and possibilities. We have redesigned the API to make it not only far easier and more reliable for developers to work with, but have also provided completely new possibilities for Plug-ins. These include:

1. Improved Performance with the Silence Flag

Processing can optionally be applied to Plug-ins only when audio signals are present on their respective inputs, so VST 3 Plug-ins can apply their processing economically and only when it is needed.

2. Multiple Dynamic I/Os

VST 3 Plug-ins are no longer limited to a fixed number of inputs and outputs, and their I/O configuration can dynamically adapt to the channel configuration. Side-chains are also very easily realizable. This includes the possibility to deactivate unused buses after loading and even reactivate those when needed. This cleans up the mixer and further helps to reduce CPU load.

3. Sample-accurate Automation

VST 3 also features vastly improved parameter automation with sample accuracy and support for ramped automation data, allowing completely accurate and rapid parameter automation changes.
4. Logical Parameter Organization

The VST 3 Plug-in parameters are displayed in a tree structure. Parameters are grouped into sections which represent the structure of the Plug-in. Plug-ins can communicate their internal structure for the purpose of overview, but also for some associated functionality (eg. program-lists).

5. Resizeable UI Editor

VST 3 defines a way to allow resizing of the Plug-in editor by a user.

6. Mouse Over Support

The Host could ask the Plug-in which parameter is under the mouse.

7. Context Menu Support

VST 3 defines a way to allow the host to add its own entries in the Plug-in context menu of a specific parameter.

8. Channel Context Information

A VST 3 Plug-in could access some channel information where it is instantiated: name, color,...

9. Note Expression

VST 3 defines with Note Expression a new way of event controller editing. The Plug-in is able to break free from the limitations of MIDI controller events by providing access to new VST 3 controller events that circumvent the laws of MIDI and provide articulation information for each individual note (event) in a polyphonic arrangement according to its noteId.

10. 3D Support

VST 3 supports new speaker configurations like Ambisonic, Atmos, Auro 3D or 22.2.

11. Factory Concept

VST 3 Plug-in library could export multiple Plug-ins and in this way replaces the shell concept of VST 2 (kPlugCategShell).

12. Support Remote control Representation

VST 3 Plug-in can deliver a specific parameter mapping for remote controls like Nuage.

13. Others

While designing VST 3, we performed a careful analysis of the existing functionality of VST and rewrote the interfaces from scratch. In doing so, we focused a lot on providing clear interfaces and their documentation in order to avoid usage errors from the deepest possible layer. Some more features implemented specifically for developers include:

More stable technical Host/Plug-in environment
Advanced technical definition of the standard
Modular approach
Separation of UI and processing
Advanced Preset System
Multiple Plug-ins per Library
Test Host included
Automated Testing Environment
Validator (small command line Test Host) and Plug-in examples code included

Some of these ("More stable technical Host/Plug-in environment",
"Advanced technical definition of the standard",
"Modular approach", ...) are just marketing BS.

Pretty much all of the actual technical enhancements could have been done as extensions to VST2. Not as that complete mess of a pseudo-standard called VST3.

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, ....

[EvilDragon]

Sample accurate automation sounds pretty cool.

Except not all VST3 plugins even implement it!

[Big Tick]

Sample accurate automation sounds pretty cool.

Except not all VST3 plugins even implement it!

Sample accurate automation was in VST2.3 (using the kVstParameterType type in VstEventTypes).
Steinberg deprecated it in VST2.4, and never replaced it.

Saying that VST3 was the only way to provide sample accurate automation is complete BS.

[EvilDragon]

Maybe it was broken? Or could it be more CPU intensive than regular automation (which might've mattered back in the day)?

[Distorted Horizon]

Funny.. I had to reinstall everything so I decided install them as VST3. They all work flawlessly in BWS.

[Vokbuz]

Sample accurate automation was in VST2.3 (using the kVstParameterType type in VstEventTypes).
Steinberg deprecated it in VST2.4, and never replaced it.

Saying that VST3 was the only way to provide sample accurate automation is complete BS.

Did it support ramping? There is no real point in sample accurate automation if all changes are instant.

Also I believe it was deprecated because nobody uses it and host has no real way to detect if plugin supports it. In VST3 it is the only way to get parameter automation.

[Big Tick]

Did it support ramping? There is no real point in sample accurate automation if all changes are instant.

Also I believe it was deprecated because nobody uses it and host has no real way to detect if plugin supports it. In VST3 it is the only way to get parameter automation.

It was undocumented so obviously nobody used it.
My point is, it could have been used, with the proper canDo() calls, to implement the same features as in VST3. Steinberg didn't have to throw VST2 away.

[Vokbuz]

It was undocumented so obviously nobody used it.

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