VST3 SDK C++ ABI vs Java, Rust, .Net, etc. libraries still rely on VST 2 API: solution?

Hi everyone!

The fact that exist many libraries and frameworks for different programming languages to develop VST plugins suggests that there is an underlying need from developers: the possibility to use their preferred languages for the task.

On the other hand, the VST3 SDK is strongly based on a C++ ABI and even though it’s loosely based on COM, the way it’s used is different from the common usage.
The documentation states: “VST-MA currently is provided in C++ only. Interfaces in C++ are expressed as pure virtual class (which is a class with nothing but abstract methods). Unlike COM there is no support for C or other languages yet - simply because there has been no need for this so far. But all VST-MA interfaces can be transformed into different representations in case this should be inevitable some day.”

Well, the need is here and those libraries and frameworks are proof of it. There are many programming languages as performant as C++ or close, so stating that only C++ should be used for audio development is a weak argument (opinion of some developers, not suggesting that this is Steinberg’s specific opinion). Developers should have some freedom of choice.

VST2 has been removed by force from everywhere to push VST3, so please, give developers some way to better integrate different programming languages to the VST3 protocol because right now there aren’t many possibilities and there are even licensing issues to consider when using these libraries.

Thank you

I completely agree with you!
I just recently graduated from java programming course , and I understand that at the moment there is no way to use my existing knowledge for audio development.
C++ is already outdated programming language, it is necessary to develop support and the ability to program in other languages too.

C++ isn’t outdated by any measure, there just have not been alternatives to it for use cases like real time audio processing until very recently (and none have been adopted in industry). The issue is not aggregate performance (where Java, .NET - even Javascript and Python on occasion - can be neck and neck with C/C++!) but the fact that these languages rely on “stop-the-world” garbage collection (often, but not exclusively). This is unacceptable in a real time audio process, where a GC pause can create an audible drop out.

Only very recently did JS VMs incorporate “audio worklets” which are designed specifically to solve this problem. I don’t know if there’s an equivalent for the JVM or other popular VMs for various languages like Graal or BEAM.

That said - nothing prevents VST3 bindings in other languages - there are bindings in Rust, D, and .NET already.

We have adapted the VST3 license in order to cover the case of porting to other languages.
Check § 2 - section 4 to section 8
What are the licensing options for VST 3? - VST - Steinberg Developer Help
You will need a written agreement from Steinberg (§ 2 section 4) and the developers using these porting have sign the VST 3 Plug-In SDK Licensing Agreement (§ 2 section 7).

Thank you for the info Yvan! Can you expand on this a little bit? My reading of section 3 is that it effectively prohibits the creation of language bindings under the proprietary license:

The Licensee has no permission to sell, license, give-away and/or distribute the Licensed Software Developer Kit or parts of it for the use as software developer kit in any way. […] This includes reworking this specification (VST API, API calling sequences, bundle definition per platform, preset format, etc.) or reverse-engineering any products based upon this specification

In order to port VST3 to a new language one must rework the VST API and API calling sequences. Section 4 calls out “porting to another programming language” but that isn’t a modification of the SDK, and its quite difficult to do and abide by section 3.

For example, the Rust bindings (which I worked on) are under GPLv3 largely because of this confusion - they don’t use the SDK at all (you don’t need the header files or even a C++ compiler). The COM interfaces and vtables are generated at compile time from Rust source. Since the proprietary license forbids this approach explicitly, it had to be GPL.

I also think that the latest ruling by the US supreme court in the case of Oracle vs Google for the Java APIs, sets a precedent that APIs cannot be protected. When you say that you don’t even use the SDK and essentially you are simply implementing the APIs (even if you were doing it in C++) that would be fair use according to the ruling.

As a side note, I also think that because of this ruling, VST2 (which is essentially 2 header files) can be implemented by anybody who wants to. An API is an API…

Or in other words it doesn’t matter what the license says when it comes to the API (of course the implementation is a different ball game), but from what you describe with Rust I just don’t see how that can be restricted, even with a license.

Of course I am no lawyer and that wouldn’t prevent Steinberg to go after you even if, due to the precedent set by the ruling, it wouldn’t stand in court…

I understand your point, mhilgendorf. From what I understand is that:

  • you have to ask Steinberg for the permission to port the API to Rust, this will be an agreement between you and Steinberg (we have no interest to stop you and maybe Steinberg may decide to integrate your work inside the SDK, could be part of the agreement). §2 (4)
  • the users (plugin developers) using your variant of the SDK have to sign the VST3 SDK license agreement like any other developers (if GLPv3 is not used) §2 (7 and 8).

Best Regards