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.
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.
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).
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"
public interface IHostApplication
[MarshalAs(UnmanagedType.LPWStr, SizeConst = Constants.Fixed128), In] StringBuilder name);
[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
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
“Yvan Grabit - VST3 history, advantages and best practice (ADC’17) - YouTube”
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.