Steinberg Discontinuing VST2 Support in its products

[pdxindy]

But then you're saying Steinberg has no reason to be helpful to users of their proprietary format including their own paying customers.

If the evidence presented here is correct and VST3 is inferior to VST2 and other developers can spot that fact then Steinberg should be able to do so as well.

I expect that Steinberg is happy to help plugin developers develop for their DAW's. Doesn't mean they will help them develop for all the other DAW's.

VST3 is inferior for plugin developers cause every DAW is different. From Steinberg's perspective, it is not inferior for their DAW's... which they repeatedly state, but that ignores all the other DAW's and all the work plugin developers have to put in to be compatible with other DAW's.

[pdxindy]

Speaking strictly as an end user I'm not likely to buy a CLAP plugin wrapped in a VST3 wrapper.

Most (if not all) VST3 plugins you currently used are already wrapped. My understanding from various developer posts is that the most common is VST2 plugin wrapped in a VST3 wrapper. Since Steinberg looks to be taking that option away, another option is needed. Thus CLAP.

[Dewdman42]

Given that SB went after someone just because they used "VST" in the name of their website do you not feel that they are going to have an issue with people circumventing their VST3 licensing ?

Well that is certainly an interesting question and I do not think Steinberg will take any of this laying down. But also think they have a financial interest that plugins run in their host products. If people produce plugins using no Steinberg header files, or none of its SDK, then I don't see how they can go after anyone....of course you won't want to call your synth "super VST Synth"... something like that..

I have a particular interest in developing midi plugin solutions that can't work properly in a VST3, regardless of whether its pure VST3 or wrapped-VST3...doesn't matter. I can only deliver it currently as VST2 in a way that will work properly. But I don't have a VST2 license, so I simply can't provide some of these. I can make them as CLAP. If someone figures out a way to use a run time binary VST2 wrapper...maybe similar in concept to what Waves does... perhaps many of us could continue to ship plugins that will run as VST2. This is critical, because for hosts that support VST2...VST2 is a superior format when it comes to instruments and midi plugins. VST3 is fundamentally flawed for those purposes. Any functionality that has to go through VST3 abstractions at any point in the processing will not work properly. So its quite possible my midi plugins will never work properly in Cubase 13+. But at least they can work in other hosts that still support VST2 (assuming they figure out a runtime way to wrap CLAP as VST2), or in hosts that eventually support native CLAP hosting. Which I expect will NEVER be the case from Steinberg...but it is what it is.

A runtime binary wrapper for VST2 only requires the that person developing and distributing that wrapper have the VST2 license. So once we have a readily accessible way to wrap as VST2 at runtime, I don't think there is a damn thing Steinberg could do about it.

Consider that tools such as BlueCatAudio Patchworks and PlugNScript are able to provide VST2 wrapping...at run time...no problem..it all falls through BCA's VST2 license. In the case of PlugNScript you can even "compile" scripts into actual VST2 bundles....that use some binary glue of some kind to create a standalone VST2 plugin....and the script-coder does not actually need their own VST2 license. Its covered by BCA's.

When Steinberg did their VST2 license agreements, they did not put the clause in there to be able to take it away from anyone later, they did add that clause to VST3, which means VST3 adoption even scarier in the future honestly... another reason to avoid signing that agreement and try to find a runtime binary solution where individual CLAP developers will not need either Steinberg license to ship plugins that run as VST in any VST host of choice.

But we shall see how it all plays out and I fully expect Steinberg to try some more shenanigans.

Speaking strictly as an end user I'm not likely to buy a CLAP plugin wrapped in a VST3 wrapper.

you are probably already using a number of VST3 plugins that are wrapped from something else inside. Why wouldn't you be willing to use one that was wrapped from CLAP?

What's the benefit to the end user? Just another fail layer or more overhead?

hey no argument, the wrapper layers do add complexity and particularly differences between different formats do not always translate well, for example VST3's midi abstractions have proven to be a total PITA for just about everyone dealing with it. But that is what we have today... Again, if hosts eventually adopt native CLAP support, then many plugins can run without wrappers...and we can perhaps have one true vendor-neutral format to develop to which can run without any wrappers. (except in Steinberg products that will probably never host CLAP)

JUCE and iPlug are two examples, some developers develop their own in-house abstractions

The difference being those are development tools not plugin formats. No matter how you create the plugin, as it stands right now you're limited to VST (and of course AAX Au LV2 etc but the subject here is VST2/3).

They each have their own SDk...and developers develop to that internal SDK, and distribute essentially wrapped plugins as VST,VST3, AU and AAX. CLAP would be not much different then JUCE, in that regard, just an alternative one that is open source and MIT License. The difference is yes...that it will also be possible for CLAP plugins to be hosted directly

[Dewdman42]

Most (if not all) VST3 plugins you currently used are already wrapped. My understanding from various developer posts is that the most common is VST2 plugin wrapped in a VST3 wrapper. Since Steinberg looks to be taking that option away, another option is needed. Thus CLAP.

definitely! And VST2->CLAP is orders of magnitude easier to convert to then VST2->VST3. Not to mention that it will be undoubtedly much easier to also product AU and AAX from CLAP then it would be by trying to use VST3 as the core development SDK. VST3 is just way too off the reservation..simple as that.

[SparkySpark]

I'm reading this thread with quite some interest. I think everyone here agrees it's unfortunate Steinberg stops supporting VST2, though, as zwenx correctly noted, it's been ten years now...

There are, as I see it, two issues here:
1. the VST3 format is pretty bad
2. the licence agreement is problematic.

However, I don't think Steinberg made their move out of spite. Perhaps there was in fact a business decision made: as soon as Steinberg made VST public in the nineties, they lost a huge advantage, and I couldn't understand at the time why they did it. Perhaps VST2 has been so successful that they want to take charge again, just a little.

With that mumbo-jumbo out of the way, I suspect VST3 was written because of an nitpicky belief in systems architecture neatness. Up until the early 2010's, we web developers lived happily with ASP.NET from Microsoft. It gave us a quite simple way to make entire web sites: using code or drag'n'drop, create a template, and then page snippets that together with the template became the pages of the web site. Create another template, and keep it as the foundation for the admin pages. Easy peasy, and a strong correlation between underlying logic and user expectations (after all, I covered the concepts in two sentences here!).

With time, Microsoft dug deep into models and views, and made web development into a MVVM-ish affair (ASP.NET MVC). Now, page snippets were scattered all over the place, and whatever leverage MS had on the PHP folks (with their rather inferior way of doing web development, built on ASP, not the object-oriented ASP.NET) was sort of lost (at least that is how I see it).

So, we ended up with a difficult to understand and rather slow elitist paradigm , where we used to have a paradigm so simple I could teach it to my students in two lectures.

The reason why I bring this up is that, from reading this thread, I suspect the same has happened to VST. Perhaps the Steinberg devs knew VST2 wasn't neat enough, in terms of model/view, encapsulation, abstraction and all that (which were à la mode at the time, hence the parallel with ASP.NET). As soon as one starts to "fix" old code beyond basic inheritance (as the template pages in ASP.NET), one gets into this mess. I would assume this is why other devs find the VST3 toolkit difficult to work with, or at least it can be one explanation. If so, then in a way, VST3 is better structured than VST2, but in reality, it's much harder to use due to its lack of overview (and even though it may be "better" structured, all that encapsulation brings with it many, many sources for erroneous coding).

Sorry for all this rambling, but I have seen conversations very similar to this one before, concerning web development, where architect purists praise one way of doing things, and others, who just want something to work and to then go on with their day, praise another way.

Ironically, I just bought Cubase Elements as my second DAW, as my DAW de préference doesn't support as many formats (like AAX and - super-duber-ironically, VST3 ). Now, I wish I had gone for an entry-level version of S1 instead (provided they will still support VST2), as I will end up with the same problem again - having a bunch of plugins that I cannot use without wrappers and stuff.

But I will endure.

[Dewdman42]

IMHO, Steinberg designed VST3 the way they did in order to directly support architecture refactoring they were doing in house to their own host products. Its definitely quite possible that the internals of Cuberico are better now, with more OOP design patterns used, etc. compared to older versions of their product. Its possible that they have built layer upon layer of internal infrastructure that is all based on a more OOP paradigm...which is what we see in the drastic change from VST2 to VST3. In other words, Steinberg made VST3 the way they did to support their own internal purposes... They obviously feel it is a superior architecture to use when taken from the point of view of having a suite of complex host products that have a lot of fancy features like NoteExpression, etc.. ...and at this point they must have many thousands of man hours invested in developing numerous products on that paradigm. VST3 is just part of that eco system.

They want third party developers to develop plugins that will run in their host. So they make the VST3 sdk free. The do not care one iota about whether VST/VST3 is used by other hosts. They only care that free access to the sdk will enable third party developers to make plugins that will work in their host products. So they make it free sdk.

As to whether this new solution is over-engineered or not...well its quite possible that for Steinberg's internal purposes its not over engineered at all, it pays for itself in the grand scheme of things because they have a lot of complicated stuff going on in their hosts that are somehow more organized in a way they can develop what they want to develop. But the downside here is that they did incur upon third party developers; a huge overhead to develop VST3 plugins to run in Steinberg's hosts. Third party developers do not reap any benefits from this more sophisticated architecture. In general it has caused more problems for them then it has solved. And most have tried to avoid it one way or another, by using wrappers and other tricks, whatever they have to in order to avoid having to get sucked into the VST3 quagmire.

Sophisticated paradigms are not always over-engineered and wrong, but they are also not always the right thing to do. They incur a lot of development overhead, which must make sense internally for Steinberg, I would hope...but clearly does not make sense for third party developers.

They got all intense with their licensing because of the fact that third parties have found more problems than solutions in VST3, have been reluctant to use it; and so they are trying to force everyone on board with them now. CLAP is arising because of that... 3rd parties will do whatever THEY have to do to meet their own purposes and needs. At some point we all want to have our plugins be runnable in Cubase, but aside from that there are very few, maybe no developers that actually see the benefit of the VST3 sdk and want to use it...it only represents a much more complicated paradigm that doesn't derive any benefit for them, and has some inherent limitations that will will always be the case in a highly abstracted model.

On top of that, non-Steinberg hosts have no incentive whatsoever to put a lot of time into the complicated VST3 paradigm. They often have problematic VST3 support because they are trying to host VST3 with as little work as possible. Their own products are NOT based on Steinberg's big internal architecture... VST3 just ends up being something complicated that conflicts with their own design priorities. I think there is a strong possibility that once enough plugins are distributed in CLAP, 3rd party DAW's may drop VST3 hosting support altogether for the same reason they don't host AAX. It will become unnecessary. Some might continue hosting VST2 only because its very simple and so many VST2 plugins floating around out there.

But what incentive do they have to support Steinberg's architecture other then being able to run as many plugins as possible? On the Mac they can run AU...and soon they will have CLAP as an option.

[syntonica]

Speaking strictly as an end user I'm not likely to buy a CLAP plugin wrapped in a VST3 wrapper.

Most (if not all) VST3 plugins you currently used are already wrapped. My understanding from various developer posts is that the most common is VST2 plugin wrapped in a VST3 wrapper. Since Steinberg looks to be taking that option away, another option is needed. Thus CLAP.

Let me dive in here with a bit of explanation. As to "wrappers", if I compile a plugin using a wrapper, most, if not all of any overhead will be optimized away by the compiler. Their efficiency has increased to amazing levels these days and the enduse will see zero difference in CPU usage, regardless of plugin format.

Where you will see a hit is if you have to use a "mini-host", a separate program that acts as a layer between your plugin and the host. Examples of this would be like Metaplugin or Patchwork, only probably more simple that you would not see the host at all.

The first example, compiled in, MAY require a legit license for the target plugin format. For the host version, that wrapper WILL require a proper license for that part, but not for the plugin itself.

If CLAP starts gaining some traction, you may find various licenses being updated to cover these contingencies, if they do not already.

[Dewdman42]

I think you will see even more of a hit in the "translation" between API's in some cases. Wrapping VST2 around CLAP should be very clean and efficient, but wrapping VST3 around either VST2 or CLAP creates in some cases more signification translation that isn't going to be optimized away off the stack that way. And in some cases the translation can't even be done entirely accurately.

[Dewdman42]

Where you will see a hit is if you have to use a "mini-host", a separate program that acts as a layer between your plugin and the host. Examples of this would be like Metaplugin or Patchwork, only probably more simple that you would not see the host at all.

I like the Waves example better. It doesn't have to be a full on mini-host. it could even be binaries that are somehow linked together without touching any Steinberg header files.

[Super Piano Hater 64]

Thanks for your eloquent and thorough reply.

Y-you too.

For real, thanks for being patient on this. You listen, you clearly explain your position, and you follow logical explanations of what's going on. Really a refreshing attitude considering all the nonsense that's flying around. And you have a good point on the trademark thing, and even though I still get the sense that they're related incidents (how many lawyers do they have, anyway?) I'll back off on that whole line of criticism.

I did intend to expand somewhat on the dangerous implications of the SDK license incident, but Urs more or less said most of what I wanted to say.

[crickey13]

and fiy, im not a steinberg employee, I'm a user and vst dev.

Why hello there, fellow forum user.

[AnX]

Why not go ask or constructively critique where it counts?

KvR is the center of the universe... it is the place that counts...

[crickey13]

That's what I was wearing when I saw the page count on this thread, and that's what I looked like after I read some of the posts.

Well, stick around, you might overtake vurt when it comes to your post-per-day ratio, you're doing pretty good so far.

[AnX]

Why not go ask or constructively critique where it counts?

KvR is the center of the universe... it is the place that counts...

Do you ever click a link and venture out...

Never

[Music Engineer]

i've repeatedly seen the argument that wrappers just introduce another possible source of bugs. well - to that i just want to say: consider the alternative: the plugin dev would natively and directly target all the different plugin APIs. that would mean to write a lot of similar yet different code to cater for all the idiosyncrasies of all the similar yet different plugin APIs, i.e. a lot of code duplication, which is widely recognized as the mother of all evil in software development (well, one of the mothers at least ). i would really worry more about the bugs that could be introduced in the maintenance of a very repetitive codebase than those that could be present in a wrapper that has been written once and for all and is widely used and therefore (hopefully) thoroughly debugged

now of course, some API vendor may want to say that "this is not the right alternative and the right alternative is to instead code only and exclusively natively against *my* API". but let's be realistic...