[polluxsynth]

When DISTRHO_PLUGIN_WANT_STRICT_PARAMETER_RESTORE is set, when loading a preset that does not set all the possible parameters in the plugin, set the unset parameters to their default values rather than leaving them at whatever value they happen to be.

This makes it possible to upgrade a preset to a version which introduces new parameters, while still making it possible to consistently load preset files that have been saved from the older version of the plugin. Otherwise, the resulting set of parameter values would depend on what the new parameters were set to previously.

This affects the loading of VST3, AU and CLAP presets. For LV2, the loading is normally executed directly by the host, so the corresponding change needs to be done to the host instead (for instance, the Zynthian fork of jalv does this when supplied with the appropriate command line argument).

Disclosure: This patch was prepared with the help of AI. A cursory review looks ok to me, but I'm not very well versed on the inner workings of DPF. I have found the patch useful for my MiMi-d plugin, and have it permanently applied when I build the plugin for VST3, AU and CLAP. I should also mention that I have verified the functionality for VST3 and AU (using Reaper) but not for CLAP.

[falkTX]

this is way over-engineered, DPF already knows the parameter default values as provided in initParameter.
if we want to give a chance to fallback to defaults in case some parameters are missing, we can already do that all internally, no need to change any APIs.

PR rejected

[falkTX]

Also DPF targets C++98 as the minimum C++ version, this code is incompatible with it.

[polluxsynth]

this is way over-engineered, DPF already knows the parameter default values as provided in initParameter. if we want to give a chance to fallback to defaults in case some parameters are missing, we can already do that all internally, no need to change any APIs.

That's actually good news; how does one go about it? Do you mean that this could be handled by the plugin itself?

The problem as I've seen it is that the framework calls setParameterValue() for all parameters in the preset file, but there are no actual callbacks where the loading procedure signals that a preset load is commencing and subsequently has been completed, so that the plugin can keep track of which parameters have not been set and set them do their default values.

[falkTX]

you can confusing DPF exposed internal programs, which are already handled by the plugin through the loadProgram and loading preset files externally through the host.

when loading internal programs it is up to the plugin to do the correct thing.

when loading presets (basically a presaved state) through the host we can detect which parameters are missing from said state and just set those to their defaults

[polluxsynth]

you can confusing DPF exposed internal programs, which are already handled by the plugin through the loadProgram and loading preset files externally through the host.

when loading internal programs it is up to the plugin to do the correct thing.

I'm only talking about loading presets through the host (the plugin I'm working with has no internal preset load, it assumes all presets will be loaded by the host).

when loading presets (basically a presaved state) through the host we can detect which parameters are missing from said state and just set those to their defaults

So, is there already a mechanism to do this in DPF then? I couldn't find any way to go about it, hence the patch, but then again it's not unlikely I've missed something.

(EDIT:) To clarify, what I can see from the plugin side is a number of setParameterValue() calls, when the host loads a preset, but there is no call to the plugin indicating that preset loading has started or ended, hence there is no point in time when the plugin can decide "I don't have all the required parameter values, so I'll set the unset ones to their default values". If there are callbacks that can be used for this, please let me know as that would solve the problem elegantly.

[falkTX]

I'm only talking about loading presets through the host (the plugin I'm working with has no internal preset load, it assumes all presets will be loaded by the host).

Then the parts of the code you changed are unrelated and just noise

So, is there already a mechanism to do this in DPF then? I couldn't find any way to go about it, hence the patch, but then again it's not unlikely I've missed something.

There is not, this is the part that would need new code.

(EDIT:) To clarify, what I can see from the plugin side is a number of setParameterValue() calls, when the host loads a preset, but there is no call to the plugin indicating that preset loading has started or ended, hence there is no point in time when the plugin can decide "I don't have all the required parameter values, so I'll set the unset ones to their default values". If there are callbacks that can be used for this, please let me know as that would solve the problem elegantly.

You are assuming the plugin side will do this, that is wrong assumption. the dpf internal code needs to change, nothing on plugin side and no need for new APIs for this.

On CLAP for example this would be in https://github.com/DISTRHO/DPF/blob/develop/distrho/src/DistrhoPluginCLAP.cpp#L1625
We can have an array of bools, false as default for all values, and assign to true if a parameter is found in the state load.
If not found, do setParameterValue at the end, assuming its not output or trigger type.

[polluxsynth]

Actually, this is exactly what the patch does, i.e. keep track of which parameters are set by the state being loaded, and set the unset ones to their defaults afterwards; e.g. for CLAP the block starting here sets unset parameters to their default: https://github.com/polluxsynth/DPF/blob/03c47e15d3563db633079f60ee99a0f9a215558b/distrho/src/DistrhoPluginCLAP.cpp#L1766 .

However, it also attempts to provide the same functionality for loadProgram, which I'm realizing now is in error.

I'll rework the patch, keeping the loadProgram API intact, and also paying attention to C++98 compliance, and resubmit. We seem to be agree on that the basic idea is sound.