Thoughts on Steinberg's VST SDK

I have looked through the VST SDK and all I can say is that it is a convoluted mess. There are like 100 C++ classes but a base API specification of nowhere to be found. Has anybody had any experience with using the SDK? I think that Steinberg approached this from the wrong angle. Instead of focusing on defining the API, they “coded” a bunch of utility code.

1 Like

Thank you for your thoughts. You may like to read the documentation here:
https://developer.steinberg.help/display/VST/VST+3+API+Documentation

1 Like

Have you looked in the “pluginterfaces/” directory? That’s the actual API, and I know a couple of people who have just implemented those interfaces and bypassed all the “public.sdk” stuff .

Although the wording of the original post might be a bit harsh, I would tend to argue that the VST3 SDK is a bit intimidating for newcomers.

As pointed out by @signalsmith the true API is the folder pluginterfaces which is actually a repository on its own: GitHub - steinbergmedia/vst3_pluginterfaces: VST 3 API (as you can see the description of this repo is VST 3 API)

But because it is bundled with the SDK which is a rather large collection of “a possible implementation of the API”, and it is not clearly separated, it is hard to see where the boundary is. The true API also contains some conventions (like the bundle format, the location where hosts can find plugins, etc…)

I also wished that the API was truly promoted and distributed as such and the VST3 SDK was clearly promoted as an “implementation of the API which happens to bundle the API”.

The fact that the SDK and the API are even having the same version number is somewhat on an issue. For example when a new version of the VST3 SDK is released, it contains many changes in the SDK itself (including VSTGUI, etc…) and hardly any to potentially none in the API itself but since it is bundled, technically it is also a new version of the API…

I think as a simple measure, it would help tremendously if, in the release notes for the version, there was a clear separation between what has changed in the API vs what has changed in the rest of the SDK.

And BTW, the API (pluginterfaces) depends on the SDK which is definitely wrong: vst3_pluginterfaces/CMakeLists.txt at master · steinbergmedia/vst3_pluginterfaces · GitHub

smtg_target_setup_universal_binary(pluginterfaces)

# ...

if(SMTG_MAC AND XCODE AND SMTG_IOS_DEVELOPMENT_TEAM)
	get_target_property(PLUGINTERFACES_SOURCES pluginterfaces SOURCES)
	add_library(pluginterfaces_ios STATIC ${PLUGINTERFACES_SOURCES})
	smtg_target_set_platform_ios(pluginterfaces_ios)
endif()

both smtg_target_setup_universal_binary and smtg_target_set_platform_ios are used in the API CMakeLists.txt but are defined in the SDK…

1 Like

Thanks for the detailed description. We will take this into account in our discussions here.

Cheers,
Arne

Hello Arne,

I’m facing the exact same issue that Alex and pongasoft described.
“Unknown CMake command “smtg_target_setup_universal_binary”.” when using cmake on the pluginterfaces code only.

More over, the pluginterfaces include its own files using "include <pluginterfaces/…>.
But the root “pluginterfaces” folder is not available in the repository.
This means that when using cmake, we need to add an extra step to copy files in a “pluginterfaces” directory instead of using the default one. Something like this:

Because VST SDK as “pluginterfaces” hardcoded, we need to move sources a folder named “pluginterfaces”…
set(VST_H_PATH ${PROJECT_BINARY_DIR}/vst_sdk)
file(MAKE_DIRECTORY ${VST_H_PATH}/pluginterfaces)
file(COPY ${vst_sdk_SOURCE_DIR}/ DESTINATION ${VST_H_PATH}/pluginterfaces))

Once done, the pluginterfaces can include its own files.

I agree with the other comments too. Personnaly I would have prefered a clear API description rather than a documentation based on SDK. Because to implement interfaces I had to read code from the sdk to understand what methods have to do. (I would like to congratulate on this, the code is pretty clear, and reading the code helped me much more than reading documentation).
Probably most of your customers uses the sdk and it explains why it is much more documented, but I think you should also think of peoples using only the API.

Best regards,

Thanks for the comment. We will add a bit of documentation about how to use the API without the SDK helper classes. But if you look at this online documentation it talks mainly only about the API and not the SDK helper classes. Maybe you haven’t seen it?

1 Like

Hello Arne,
You’re right, I didn’t see it. It would have helped me a lot :wink:
So, you can mitigate my comment on documentation.

Best regards,