DISTRHO/DPF

travesty: set_io_mode asserts incorrect initialization state

Closed this issue · 3 comments

I'm trying to build my VST3 hosting stuff using travesty, and I noticed that set_io_mode() ensures that the IComponent instance (equivalent) is already instantiated:

DISTRHO_SAFE_ASSERT_RETURN(vst3 != nullptr, V3_NOT_INITIALIZED);

However, the VST3 API is messed here and you have to call it before initialize():

https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/API+Documentation/Index.html#initialization

The context parameter passed to Steinberg::IPluginBase::initialize should implement the interface Steinberg::Vst::IHostApplication. Hosts should not call other functions before initialize is called, with the sole exception of Steinberg::Vst::IComponent::setIoMode which must be called before initialize. Steinberg::Vst::IComponent::getControllerClassId can also be called before (See VST 3 Workflow Diagrams).

My VST3 host is implemented to do so, and then plugins like AIDA-X fails to load because of this (on debug builds; release builds would just ignore the failure) . This seems unexpected behavior, at least by Steinberg (probably Cubase).

I have a one liner fix for this (a PR would follow).

Good catch! I never had a need for that call even if I also do my hosting in Carla through travesty.

From your PR I now see the possible values for it https://steinbergmedia.github.io/vst3_doc/vstinterfaces/namespaceSteinberg_1_1Vst.html#aec143ffe42b4aa77d9b2cf27183a554e
But still dont quite understand how and why to use these..

TBH I'm not familiar with this feature either. I had been attempting various options to instantiate a VST3 plugin, and this was just what I tried to use before initializing IComponent. I don't know any plugin or host that makes use of this feature.

The documentation for setIoMode() gives some hints though https://steinbergmedia.github.io/vst3_doc/vstinterfaces/classSteinberg_1_1Vst_1_1IComponent.html#a4618e7358890d549f990010bea4a4137 :

Implemented in Component, and SingleComponentEffect.

SingleComponentEffect seems like:

Default implementation for a non-distributable Plug-in that combines processor and edit controller in one component. More...

Here (non-)"distributable" seems equivalent to (non-)"advanced" i.e. n:m I/O mappings.

That still doesn't explain why a plugin wants to receive that I/O mode though. My current idea is that this function might be added before VST3 got proper audio buses support, but that's just a guess.

In any case, I guess this issue can be closed...?

In any case, I guess this issue can be closed...?

Yes, thanks!

And yeah I stopped trying to make sense of VST3 by now