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()
:
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