API to set/get non-automation (string) parameters?

[dbadb]

This may be a noob question, but...

I'm dabbling with a CLAP-plugin testbed and have a question about, eg, string parameters. If my CLAP plugin accepts/requires a file name parameter (string), is there a way short of presets and GUI to set and get its value? This would be helpful in developing automated test rigs, etc. The API for ext/params.h seems constrained to float/int/numbers and is intertwined with automation.

Am I missing an API, extension or draft?

Thanks for any guidance!

[defiantnerd]

You maintain strings within your plugin class and use the state extension (https://github.com/free-audio/clap/blob/main/include/clap/ext/state.h) to store them in presets or in a project.

[dbadb]

That could certainly be made to work, but doesn't appear to support individual, identifiable state members. If I have 10 string parameters, my test rig would like to manipulate each one independently.

[dbadb]

And perhaps I didn't make it clear, but I'd like these string parameters to be discoverable (like params) so my test rig could automate a variety of plugins.

[defiantnerd]

If it is about presets - since you talk about filenames - maybe the preset-discovery extension is a solution for you?

Apart of that, you could introduce a private extension for your test rig and use that to setup your strings for your tests, as Robbert proposed, too.

[dbadb]

Yes indeed this seems like the way to go, especially if there is no broader call for such an interface.

[robbert-vdh]

In most plugin APIs parameters are (numerical) values that can be changed by the host at runtime to affect the plugin's audio processing behavior. As such parameters need to have a clearly defined domain of possible values, and changing them needs to be realtime safe as it will be done from an audio thread. Arbitrary strings don't fit either requirement, and as such they're not suited for parameters in the model these plugin APIs follow.

You could have an extension that exposes these arbitrary strings to the host, but there would need to be a clear use case for why the host would need to be able to modify them directly without the user interacting with a plugin-provided GUI (which, since it's provided by the plugin, can have much better knowledge of the plugin's domain).

[dbadb]

I agree with your points, especially the idea that there are a class of parameters that must not be modified while the audio-engine is active. I note that there are cases, even with numerical parameters with well-defined ranges, that may trigger a request for the host to re-activate the plugin in the main thread.

That said, I do see two clear use cases for such an extension (if it doesn't already exist).

1. for programmatic modification (eg a test rig, plugin exerciser, etc)
2. a system to auto-gen GUIs across a range of plugins.

[defiantnerd]

Instead of having a generic „set the value of an indexed string parameter“ extension I would propose that you better get the way to define the specific use case and then create an appropriate - maybe just private - extension for it. There are already a range of extensions regarding generic UIs and Preset Discovery/Selection that easily fit your requirements and if not, feel free to create one.

[dbadb]

re: There are already a range of extensions regarding generic UIs and Preset Discovery/Selection that easily fit your requirements

In a way this was my original question. I'm not sure I follow, can you point me to an example of an extension that allows me to do this for individual parameters that aren't numerical/automatable?