Parameter visibility, range, trigger

[jpcima]

Some misc requests related to parameters. These are use cases mostly related to wrapper plugins of other formats, which have their own parameter mappings (sfz, jsfx).

• [x] changing the parameter visibility When visibility is switched off, the parameter should no longer appear from host's generic UI. It's a feature present in Reaper's jsfx, possibly also in vst3 with some subtleties.

• [x] loose range constraints Perhaps a flag which tells the host explicitly to not clamp value to min/max, let value be how it is. For example, Reaper allows a plugin to automate a parameter outside of the nominal range, in jsfx min&max both to 0 is valid and working. IIRC LV2 has it the other way around, a flag requires host to force values into range. Either way, the objective is to make explicit the host's clamping behavior.

• [ ] trigger parameter A trigger parameter works no different than a boolean, but can allow the host represent it as a non-checkable push button. Present on Reaper jsfx generic UI.

[abique]

Hi,

Visibility: https://github.com/free-audio/clap/blob/main/include/clap/ext/params.h#L104

Range: use -Infinity and +Infinity

Trigger: this is interesting, but I don't think that the solution is to create a parameter for it. Because a parameter has a state, and a trigger is stateless. I think the appropriate solution would be to make an extension to declare trigger ports and trigger events.

[jpcima]

Visibility and trigger = sounds fine

Range: use -Infinity and +Infinity

OK but it doesn't really address the problem as it is stated. For context, i'm trying to imagine how a JSFX wrapper plugin would fit into CLAP.

This plugin accepts a code file provided by user; this file describes parameter ranges, and also the user code can change these parameters, including out of their nominal range.

Since it's just running code, I don't know in advance what range of values the code actually will automate. What I know is that ideally, it must not clamp, or this can break the intended logic.

(and it can be a shortcoming in current plugin formats, because hosts tend to treat clamping in arbitrary ways)

Hope it makes sense.

[abique]

1.1.4 did address the trigger thing. I think we can close this issue now.

[baconpaul]

This plugin accepts a code file provided by user; this file describes parameter ranges, and also the user code can change these parameters, including out of their nominal range.

Since it's just running code, I don't know in advance what range of values the code actually will automate. What I know is that ideally, it must not clamp, or this can break the intended logic.

So the user provides a file with valid ranges; why not just set those ranges when they change and force a param rescan? Remember with CLAP you don't need to know anything in advance, you can just reset all the params whenever you want (modulo threading).

Or is it that the user sets the valid range as 13 .. 17 and you want any value to still be allowed in? In that case, what does the range mean?