Clarify whether clap_param_info_t.min_value and max_value can change

[nakst]

I think that for the fields min_value and max_value of clap_param_info_t, the documentation should make it clear that a plugin is allowed to increase the range of allowable values for a specific parameter in a version update to the plugin.

(Otherwise, a host might try saving normalized values in the range 0..1 for e.g. automation, which would then break.)

[abique]

In theory yes, in practice no. Some host store normalized parameter values in their automation, in other words the "knob position". In such case, if you change the range then you'll end up with a different sound.

[baconpaul]

Oooh I don’t love that answer. Doesn’t it mean defacto you should never use anything other than 0..1 values and manage schemas yourself?

[nakst]

At the very least I think it should be guaranteed for stepped parameters, since they often represent enumerated values, and the number of possible values in the enumeration may increase with version updates (e.g. adding new filter algorithms, or modulation destinations).

[abique]

The data model allows for changing the range. But you'll always find hosts, which are storing normalized value in their project files. If you want a hard guarantee that the sound won't break, then never change the range. If the sound change you can still tell your customers that it is because of the host, and the host can tell its customers it is because of the plugin. Also if you plan on using adapters (vst3, vst2, au, ...) then having constant range is maybe even more important.

[abique]

Also if you extend the range, you might break the sound anyway. Just add an modulation signal on top of an automation, and given that the clipping level suddenly changes then the sound changes too.

[defiantnerd]

It is an inherent problem of parameters in the usual case. In a pure CLAP world this could work, but I doubt that hosts would not choose a "common" format for all the plugin standards they support, as @abique noted.

For sure, the host will not store the minimum/maximum of those parameters to adapt its automation lane, so it can't even detect such a range change. The only way I could imagine where such an update might work without sound change is when the state contains the previous version and this switches to the "old" range (also something where you might want to know the context of state restore: from a song load: adapt the range, from a preset load: update the parameter to the new range).

Additionally, the problem is two fold: 1) a range of a continuous parameter is changing -> adapt the automation value (so the value fits the new range) 2) a range of a stepped parameter is changing -> keep the automation value (so the "mode" does not change)

And where this might be okay for 99% of the plugins, you can't guarantee this.

Actually, for such a thing we could introduce an extensions that provides functions to update parameter values for automation lanes upon loading an "old" project.

Also, who will be responsible for such an update: host or plugin?