Closed sdangelo closed 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
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?
no the plugin should be able to process without buffer (flush parameters), setActive should return kResultTrue.
Ok, thanks
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.