Comment. VST3 - new DAW host, support/integration woes

Developer VST 3 SDK
1

I know nothing about this stuff personally.

But I always seem to read similar stories; you must know about them too.

And now, here’s another, latest appraisal (comparing to CLAP plugin integration):-
:-1: UltraDAW now support VST3 / CLAP plugins - Maksa Net | Boosty

Here’s one quote from in there… "Steinberg’s own documentation system is completely confusing - a bunch of sites, a ton of links. Of the ton of SDK files, you actually need 3 dozen. Very difficult. With CLAP, the situation is completely opposite - everything is simple and clear." (my emphasis).

Any chance of putting some focus into even looking at making this part a heck of a lot easier for 3rd party host developers..?

It’s up to you.

(I do want VST3 to properly succeed by the way - just that I’m seeing ‘barriers’ that could be broken down to help matters…)

2

Hello there. Here the author and developer behind UltraDAW.

I think the problem is that Steinberg focused too much on helpers. And they documented the low-level work extremely poorly. For example, it is much easier for me to use a low-level API, rather than spend a lot of time studying a bunch of helpers. It would be good to have a list of basic operations with plugins and their brief implementation in the context of VST3. And of course, a full-fledged example of a host would also be useful. But in reality, the documentation is essentially a brief (precisely brief) reference book on classes. But it is difficult to understand which class to use where and how. You have to look through a bunch of source codes. Moreover, in the source codes of the Juce or iPlug2 information really needed to write a host is many times more than in VST3 SDK. It is also good that I studied VST2 in detail for 2 years. It helped me understand some things.

It feels like the plugins were written first, and then they decided to document the API :slight_smile: That is, some basic points are described very briefly (this happens to me when I write code for a long time and then decide to document it for myself) because I seem to remember it :slight_smile:

And of course, posting all this as HTML documentation doesn’t seem like the best idea to me. It’s almost impossible to read on a smartphone. It would be much more convenient as PDF. Or as in the case of clap - high-quality documented source files.

3

Thanks for you feedback. Did you read VST - VST 3 Developer Portal or just the doxygen documentation?

4

Yes, of course I followed the link. And the first thing that confused me was that I didn’t find the technical documentation right away. It’s hidden in the 7th link on the left inside the “Technical documentation” item. As a developer, I’m primarily interested in the ability to quickly find documentation, and not “Tutorials”, “Getting started”, “What is the VST3 SDK” (if I came here, I probably already know what the VST3 SDK is :slight_smile: ). Then, after following this link, it suggests going to “SDK site” , i.e. I’m already confused - should I go there or stay and read here? It’s extremely tedious to search for the “VST3 API documentation” item every time. I somehow assumed that it should be the first item in the menu :slight_smile: Actually, it seemed to me one of the few really useful pages (although of course it would be nice to add the Communication between the host and plugin item) for example. I have nothing against the VST3 format. A lot of things are done quite conveniently in it. But I would like to use the VST3 API documentation with the ability to quickly find what I need. And after reading “Getting Started with VST” and seeing “Getting Started” under it - honestly, it’s very confusing. That is, when I read “Getting Started” I expect to read about how to start using the API, but they offer me “How to set up my system for VST 3”. My system is already ready :slight_smile: I’m a programmer. I want to read in the API description about how my code should work, and not about where to download the VST3 SDK from. Sorry for so much text, but the truth is - it’s very difficult to find in the menu exactly what you need here and now.

1 Like
5

Thanks @MaksaNet! That’s super helpful feedback.

1 Like
6

In addition, it is very difficult to understand how the host → plugin feedback is implemented. Unlike vst2, where there was only one feedback function, here a class is created that inherits the necessary interfaces and methods . Unfortunately, this simple idea about the host_callback class is not described anywhere in a simple and understandable way. There is no simple code example where there would be something like

class vst3_HostCallback //inherit only what is needed
: public FObject
, public IHostApplication
, public IComponentHandler
, public IComponentHandler2
, public IUnitHandler
, public IUnitHandler2
, public IPlugFrame
, public Vst::IPlugInterfaceSupport
{
friend class PlugVST3;

PlugVST3* vst3_owner;
public:
OBJ_METHODS(vst3_HostCallback, FObject)
REFCOUNT_METHODS(FObject)
DEFINE_INTERFACES
DEF_INTERFACE(IHostApplication)
DEF_INTERFACE(IComponentHandler)
DEF_INTERFACE(IComponentHandler2)
DEF_INTERFACE(IUnitHandler)
DEF_INTERFACE(IUnitHandler2)
DEF_INTERFACE(IPlugFrame)
END_DEFINE_INTERFACES(FObject)

//methods of class IHostApplication
//methods of class IComponentHandler
…
}
but this would help a lot. That is, as a result, the real ideas of HOW the plugin works or how the host interacts with it are hidden inside helper wrappers (for example, PlugProvider). In essence, there are ideas behind the VST3 API, but the documentation shifts the focus to studying helpers, i.e. wrappers. And it is difficult to understand how it actually works. Even since the time of VST2, the documentation created by doxygen has caused confusion. A lot of circular HTML links and some complex aspects are not described in detail.

For example, I still haven’t figured out to the end whether it is necessary to call _audio_processor->setBusArrangements() during the initialization process (from the host side)? Or how to read/change the name of the current plugin program on the host side

The SDK directory structure itself is of course also confusing. That is, parts of the SDK are essentially scattered across the base, plugininterface, public .sdk directories and it is not obvious where everything is. Of course, all these are the thoughts of the host developer :slight_smile: I do not claim to be objective - but in some places it is very difficult to understand the essence, although at the moment my DAW seems to scan and correctly work with collections of ~1000 VST3 plugins :slight_smile: I am glad if I gave useful information. Perhaps I will post open sources of a simple but full-fledged test host (with loading, unloading, programs, units, support for one-component, two-component plugins, working with parameters, etc.)

1 Like