VST3 rescans param names on params::request_rescan #289
Conversation
request_rescan with CLAP_PARAM_RESCAN_INFO may invalidate the name, module, or several other flags. The wrapper up until now just invalidated the value and re-ran the value to text. Shortcircuit allows users to rename macros easily and the clap correctly calls params_rescan which results in bitwig re-displaying the clap name. The VST3 and AUv2 don't do this. This commit fixes the VST3 with a partial correction and a comment. The partical correction is to re-acquire the parameter name in a RESCAN_INFO case. The comment explains that we do not re-acquire the module and build the entire tree. Would appreciate careful review here. It fixes the shortcircuit bug but this is pretty fundamental code.
| if (flags & CLAP_PARAM_RESCAN_INFO) | ||
| { | ||
| // In this case, the name and module can also change. | ||
| // For now, don't rebuild the unit tree with modules but |
There was a problem hiding this comment.
how about checking for a change in the module name and rebuild in that case.
There was a problem hiding this comment.
I thought about that but do we have the old module name around? Also can you rebuild unit trees in VST3?
Happy to look into both though!
There was a problem hiding this comment.
not yet, we could add it, though. but you can not request that, only a full reload of the component.
You can also remap parameters but only during project loading (kParamIDMappingChanged).. I remember that I decided back then that CLAPs shouldn't do so much weird things 😺
this does not really match the vst3 semantics. It is something that should probably avoided when you write a CLAP to be used with the wrapper.
There was a problem hiding this comment.
documentation on restartflags are here:
https://steinbergmedia.github.io/vst3_doc/vstinterfaces/namespaceSteinberg_1_1Vst.html#a35f71d02b79cbd11942a149e651373e6aad5c03a524a2b60c6e72f3f1b7fa1efa
There was a problem hiding this comment.
yeah my view was 'modules changing is wierd names is common' hence the fix here.
There was a problem hiding this comment.
perhaps this can work...
https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Parameters+Automation/Index.html#informing-the-host-about-changes
maybe hosts try to re-read the whole parameter list?
There was a problem hiding this comment.
So @defiantnerd we already send those param change flags at line 906. This diff is really just rebuilding the internal cache of the params we have when they change.
I propose the following
- lets merge this. The common case of param names change is then taken care of and also we can easily test the unicode thing
- lets open an issue for module changes. That issue would contains
- param has to cache the module name
- param diffs the module name here
- if that module name has diffed we issue a full reload, which is a bummer, and add that to the documentation
wdyt?
request_rescan with CLAP_PARAM_RESCAN_INFO may invalidate the name, module, or several other flags. The wrapper up until now just invalidated the value and re-ran the value to text.
Shortcircuit allows users to rename macros easily and the clap correctly calls params_rescan which results in bitwig re-displaying the clap name. The VST3 and AUv2 don't do this.
This commit fixes the VST3 with a partial correction and a comment. The partical correction is to re-acquire the parameter name in a RESCAN_INFO case. The comment explains that we do not re-acquire the module and build the entire tree.
Would appreciate careful review here. It fixes the shortcircuit bug but this is pretty fundamental code.