parameters management

Main idea:

The host sees the plugin as an atomic entity; and acts as a controller on top of its parameters. The plugin is responsible for keeping its audio processor and its GUI in sync.

The host can at any time read parameters' value on the [main-thread] using clap_plugin_params::value().

There are two options to communicate parameter value changes, and they are not concurrent.

send automation points during clap_plugin.process()
send automation points during clap_plugin_params.flush(), for parameter changes without processing audio

When the plugin changes a parameter value, it must inform the host. It will send CLAP_EVENT_PARAM_VALUE event during process() or flush(). If the user is adjusting the value, don't forget to mark the begining and end of the gesture by sending CLAP_EVENT_PARAM_GESTURE_BEGIN and CLAP_EVENT_PARAM_GESTURE_END events.

Note: MIDI CCs are tricky because you may not know when the parameter adjustment ends. Also if the host records incoming MIDI CC and parameter change automation at the same time, there will be a conflict at playback: MIDI CC vs Automation. The parameter automation will always target the same parameter because the param_id is stable. The MIDI CC may have a different mapping in the future and may result in a different playback.

When a MIDI CC changes a parameter's value, set the flag CLAP_EVENT_DONT_RECORD in clap_event_param.header.flags. That way the host may record the MIDI CC automation, but not the parameter change and there won't be conflict at playback.

Scenarios:

I. Loading a preset

load the preset in a temporary state
call clap_host_params.rescan() if anything changed
call clap_host_latency.changed() if latency changed
invalidate any other info that may be cached by the host
if the plugin is activated and the preset will introduce breaking changes (latency, audio ports, new parameters, ...) be sure to wait for the host to deactivate the plugin to apply those changes. If there are no breaking changes, the plugin can apply them them right away. The plugin is resonsible for updating both its audio processor and its gui.

II. Turning a knob on the DAW interface

the host will send an automation event to the plugin via a process() or flush()

III. Turning a knob on the Plugin interface

the plugin is responsible for sending the parameter value to its audio processor
call clap_host_params->request_flush() or clap_host->request_process().
when the host calls either clap_plugin->process() or clap_plugin_params->flush(), send an automation event and don't forget to set begin_adjust, end_adjust and should_record flags

IV. Turning a knob via automation

host sends an automation point during clap_plugin->process() or clap_plugin_params->flush().
the plugin is responsible for updating its GUI

V. Turning a knob via plugin's internal MIDI mapping

the plugin sends a CLAP_EVENT_PARAM_SET output event, set should_record to false
the plugin is responsible to update its GUI

VI. Adding or removing parameters

if the plugin is activated call clap_host->restart()
once the plugin isn't active:
- apply the new state
- if a parameter is gone or is created with an id that may have been used before, call clap_host_params.clear(host, param_id, CLAP_PARAM_CLEAR_ALL)
- call clap_host_params->rescan(CLAP_PARAM_RESCAN_ALL)