steinbergmedia / vst3sdk

VST 3 Plug-In SDK
Other
1.65k stars 162 forks source link

Should bus activation persist over terminate and initialize? #128

Closed sdangelo closed 4 months ago

sdangelo commented 5 months ago

Using VST3's interfaces directly (hence bypassing all the rest of the SDK) and running the validator tool I have a fail in the "Valid State Transition" test as it does, in order: terminate, initialize, and finally setActive without re-activating buses, even if flagged as kDefaultActive, after initialize.

Now I'm wondering what is the intended behavior on the plugin side w.r.t. bus (re)activation. From the docs (https://steinbergmedia.github.io/vst3_doc/vstinterfaces/structSteinberg_1_1Vst_1_1BusInfo.html) I see that kDefaultActive's description is "The bus should be activated by the host per default on instantiation (activateBus call is requested)", so I'd normally expect the host to re-activate buses after initialize, but that's clearly not the case with the test. Otherwise the plugin should internally assume that bus (de)activation persists across terminate and initialize, which seems rather odd honestly.

In normal hosts I don't have issues, yet I don't know if this execution path was ever executed in practice.

ygrabit commented 4 months ago

Hi I will adapt the test to activate again the busses, but the host could decide (which could be seen as strange) to not enable the busses, see the doc comment

sdangelo commented 4 months ago

Great, thank you!

Just for the sake of completeness, I suppose it's ok that setActive returns kResultFalse because a "necessary" buffer was not activated, right?

ygrabit commented 4 months ago

no the plugin should be able to process without buffer (flush parameters), setActive should return kResultTrue.

sdangelo commented 4 months ago

Ok, thanks