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

2 Likes

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.

Hi
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).
Cheers

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
Yvan

You can somewhat easily emulate the C++ class layout and virtual tables in C using structs and function pointers.

Once you’ve done that, you can use the FFI of some other language to translate between C++ and the other language.

You can also use some other tool like SWIG to generate language-independent bindings. Essentially, these tools generate an “almost empty wrapper” in C++, than then calls into whatever the native language interface is supposed to do.

This is all probably easier to do for “writing a plugin in Rust,” than it would for for “writing a host in Python,” though – how closely the FFI matches the runtime expectations, matters!

In addition to what @jwatte mentioned, I have been told that the VST3 COM-like interface is actually binary-compatible with COM.

If you look at the .NET implementation of VST3, this appears to be the case. Here’s an example:
https://github.com/obiwanjacobi/vst.net/blob/master/Source3/Code/Jacobi.Vst3.Core/IHostApplication.cs

// Interfaces.IHostApplication here is the FUID in Microsoft OLE format
// given by calling FUID::toRegistryString(), "58E595CC-DB2D-4969-8B6A-AF8C36A664E5"
[ComImport]
[Guid(Interfaces.IHostApplication)]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IHostApplication
{
    [PreserveSig]
    [return: MarshalAs(UnmanagedType.Error)]
    Int32 GetName(
        [MarshalAs(UnmanagedType.LPWStr, SizeConst = Constants.Fixed128), In] StringBuilder name);

    [PreserveSig]
    [return: MarshalAs(UnmanagedType.Error)]
    Int32 CreateInstance(
        [In] ref Guid classId,
        [In] ref Guid interfaceId,
        [MarshalAs(UnmanagedType.SysInt, IidParameterIndex = 1), In, Out] ref IntPtr instance);
}

I’ve seen a few kinds of language ports/bindings done:

  • C headers, but the implementation was provided by the host language
  • C ABI that wraps C++ API and needs to be linked, delegates directly to the C++ implementation
  • COM-based
  • Using bindgen tools like SWIG, CppSharp, etc that try to autogenerate a C ABI hooked up to a host language

It’s common understanding that an official C ABI that wraps & integrates the C++ API is the best-case scenario.

@Yvan out of curiosity, if someone were to write & sign an agreement with Steinberg about it, then did the work for tacking on the flattened C ABI into the VST SDK main sources – would there be a possibility/hope for Steinberg accepting that PR and upstreaming it for everyone’s benefit?

By the way, thanks for doing this talk in 2017. There’s not a lot of info online about VST3 architecture/internals. I found this helpful :slightly_smiling_face:

“Yvan Grabit - VST3 history, advantages and best practice (ADC’17) - YouTube”

It could be possible but we will have to involve our lawyer in order to get agreement written and this could take time… :slight_smile:

Ouch, lawyer stuff does not sound fun.

Maybe what I (or anyone) could do to not waste anyone’s time, is: if such a C ABI is created, a PR could be submitted against steinbergmedia/vst3_pluginterfaces for reviewal, and leave contact/legal information in the PR.

Steinberg could of course decline/request or implement changes, but at least then there’s some notion of being seriously interested in it and some grunt work having been done.

Just a thought =)

Appreciate the reply

1 Like

I think Your point was heard ! VST3 C API has been released.

opening up the API for less restrictive licensing would be great!
the Rust audio plugin ecosystem around nih-plug seems to have become easier to learn and use than the alternatives, even JUCE.
It would be truly awesome if Steinberg enabled these alternative language interfaces to VST3 be licensed in a way that enables using them commercially.
I think plugin devs wouldn’t mind signing / abiding by the Steinberg License, despite not using the actual Steinberg SDK, if it meant they could develop a VST3 in other languages.
And an open-source SDK project applying at Steinberg for being able to redistribute it under the Steinberg license would mean Steinberg doesn’t loose control, yet these projects become possible.
The result of this application process could be the “written agreement” the license refers to.
This way these projects could start out as GPLv3, then when they are mature enough apply for the “upgrade” to the GPLv3+Steinberg license.
Then plugin devs could, from these alternative interfaces, either write a foss GPLv3 plug OR sign the Steinberg license and write a proprietary one.
Take vst3-sys for example, it works well, a lot of work has already been done but we can’t use it for commercial VSTs since its GPLv3.

The availability of various libraries and frameworks for different programming languages to develop VST plugins reflects a clear demand among developers to use their preferred languages for the task. While the VST3 SDK primarily relies on a C++ ABI, the growing need for flexibility suggests a call for better integration of different programming languages into the VST3 protocol. By providing developers with more options and reducing licensing constraints, we can foster a more inclusive and innovative audio development ecosystem. Thank you for raising this important issue.