VST3 UhhYou plugins not getting scanned

[alex-tee]

$ /usr/lib/carla/carla-discovery-native vst3 /usr/lib/vst3/ParallelDetune.vst3                                                                                                                                                           
"/home/alex/.config/UhhyouPlugins/style/style.json" is not regular file or doesn't exist.
[carla] Carla assertion failure: "v3_cpp_obj(processor)->set_processing(processor, true) == V3_OK" in file carla-discovery.cpp, line 189

I get the above error as of latest commit

[falkTX]

it returns a non-ok value for the processing setup, and thus carla wont load it.

the call in question is https://github.com/ryukau/VSTPlugins/blob/master/ParallelDetune/source/plugprocessor.cpp#L68 which in turn calls https://github.com/steinbergmedia/vst3_public_sdk/blob/master/source/vst/vstaudioeffect.cpp#L184

so the plugin is broken, it shouldnt call the base class function as it does nothing. it should instead directly return kResultOk

related discussion https://forums.steinberg.net/t/iaudioprocessor-setprocessing-fails-in-many-plugins/785558 seems to be a common dev mistake

[alex-tee]

Thanks, I reported it upstream.

related discussion https://forums.steinberg.net/t/iaudioprocessor-setprocessing-fails-in-many-plugins/785558 seems to be a common dev mistake

As it seems that many plugins return kUnimplemented, and a "steinberger" (?) moderator there said to check for kResultFalse instead, wouldn't it be better to check if the result is !kResultFalse so that carla handles more plugins, instead of checking for kResultOk?

EDIT: FWIW, JUCE plugins return kResultTrue when OK and kResultFalse when not OK, so the above would be ok for JUCE plugins: https://github.com/juce-framework/JUCE/blob/d054f0d14dcac387aebda44ce5d792b5e7a625b3/modules/juce_audio_plugin_client/juce_audio_plugin_client_VST3.cpp#L3425

[falkTX]

related discussion https://forums.steinberg.net/t/iaudioprocessor-setprocessing-fails-in-many-plugins/785558 seems to be a common dev mistake

As it seems that many plugins return kUnimplemented, and a "steinberger" (?) moderator there said to check for kResultFalse instead, wouldn't it be better to check if the result is !kResultFalse so that carla handles more plugins, instead of checking for kResultOk?

that is a bad recommendation, it would ignore kInvalidArgument among other error conditions. I think it is best to accept both "ok" and "not implemented" with a comment back to this ticket. any other return error is likely meaningful, so I think it shouldn't be ignored.

[falkTX]

Fixed in dacca3a53df9149b33928525ecdce09b61732bff