Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

travesty: set_io_mode asserts incorrect initialization state #466

Closed
atsushieno opened this issue Sep 29, 2024 · 3 comments
Closed

travesty: set_io_mode asserts incorrect initialization state #466

atsushieno opened this issue Sep 29, 2024 · 3 comments

Comments

@atsushieno
Copy link

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).

@falkTX
Copy link
Contributor

falkTX commented Sep 29, 2024

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..

@atsushieno
Copy link
Author

atsushieno commented Sep 29, 2024

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...?

@falkTX
Copy link
Contributor

falkTX commented Sep 29, 2024

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

Yes, thanks!

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

@falkTX falkTX closed this as completed Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants