For context, I'm making a plugin which has a parameter that controls the generator type. For each generator type is a different set of parameters with different names, default values, and ranges. This is done with a constant number of allocated parameters by adding the hidden flag to unused parameter slots.
The CLAP specification requires that clap_host_params::rescan be called from the main thread, and suggests that to call this function while the plugin is active, the plugin should first call clap_host::request_restart, and then call the rescan function on the clap_plugin::activate callback.
VI. Adding or removing parameters
- if the plugin is activated call
clap_host->restart()
- once the plugin isn't active:
- apply the new state
- if a parameter is gone or is created with an id that may have been used before, call
clap_host_params.clear(host, param_id, CLAP_PARAM_CLEAR_ALL)
- call
clap_host_params->rescan(CLAP_PARAM_RESCAN_ALL)
But the way these two host callbacks are implemented makes this method make VST3 API calls with incorrect/erroneous conditions:
clap_host::request_restart is classified as thread-safe, but in the VST3 implementation it directly calls IComponentHandler::restartComponent, which can only be called from the main thread. This can be easily fixed though.clap_host_params::rescan calls IComponentHandler::restartComponent to make the VST3 host rescan parameters, but this prevents it from being called within clap_plugin::activate if called from a restart, lest Unforeseen Consequences happen. On the JUCE audio plugin-in host demo, an indefinite freeze happens on the call to restartComponent.
It seems then that to make parameter rescan work with VST3, the plugin must call clap_host::request_callback to then trigger the host parameter rescan in the callback. This works correctly, once you either fix clap_host::request_restart or do everything in a callback instead of restarting, but it seems like an extra step compared to what the CLAP specification suggests, and also when considering that (at least on Bitwig) the suggested method works perfectly when running the unwrapped CLAP plugin.
For context, I'm making a plugin which has a parameter that controls the generator type. For each generator type is a different set of parameters with different names, default values, and ranges. This is done with a constant number of allocated parameters by adding the hidden flag to unused parameter slots.
The CLAP specification requires that
clap_host_params::rescanbe called from the main thread, and suggests that to call this function while the plugin is active, the plugin should first callclap_host::request_restart, and then call the rescan function on theclap_plugin::activatecallback.But the way these two host callbacks are implemented makes this method make VST3 API calls with incorrect/erroneous conditions:
clap_host::request_restartis classified as thread-safe, but in the VST3 implementation it directly callsIComponentHandler::restartComponent, which can only be called from the main thread. This can be easily fixed though.clap_host_params::rescancallsIComponentHandler::restartComponentto make the VST3 host rescan parameters, but this prevents it from being called withinclap_plugin::activateif called from a restart, lest Unforeseen Consequences happen. On the JUCE audio plugin-in host demo, an indefinite freeze happens on the call to restartComponent.It seems then that to make parameter rescan work with VST3, the plugin must call
clap_host::request_callbackto then trigger the host parameter rescan in the callback. This works correctly, once you either fixclap_host::request_restartor do everything in a callback instead of restarting, but it seems like an extra step compared to what the CLAP specification suggests, and also when considering that (at least on Bitwig) the suggested method works perfectly when running the unwrapped CLAP plugin.