plugin actions extension

[Trinitou]

What if a plugin could register actions to the host?

The host could then:

• list the actions in a right click menu of the plugin
• map a hardware controller to those actions
• let the user put trigger buttons on remote control pages (Bitwig-specific)

Use case examples would be

• randomize actions (e.g. for step-sequencer step values)
• learn actions for adaptive audio algoriths (e.g. plugins that listen and adapt to the loudness or spectral content of incoming audio)
• shake action for a spring reverb
• panic action for FX involving audio feedback loops

More a rough idea but I imagine this would be a very nice feature for CLAP Something similar was already mentioned in #32 but I think putting it into a separate issue might help to bring on the discussion.

[nakst]

I second this. It's also an easy way for improving plugin accessibility, if the host has implemented the OS's automation APIs.

[robbert-vdh]

What's the difference between this and the proposed context menu extensions? #221 is a new draft based on the earlier discussions.

[Trinitou]

What's the difference between this and the proposed context menu extensions? #221 is a new draft based on the earlier discussions.

Oops, didn't see that. But I think #221 is more about context menus for individual parameters. Correct me if I'm wrong, @abique ! This one is about actions that are available for a whole plugin instance. I'm not sure whether actions like I mentioned as examples should rather be parameters themselves with a parameter id (so that there are "trigger action parameters") or if these actions are some kind of extra type. I suppose something like "randomizing a step sequencer" might be a bit more CPU intensive so at least it shouldn't be modulatable nor automatable. Also this proposal would be independent from any context menu handling as the host could decide by itself whether to put plugin actions into a context menu, have them midi-learnable, and/or map them to a hardware controller automatically.

[abique]

@Trinitou that'd be nice to have trigger port/events for the plugin. Those controls could indeed be mapped to hw controller. I think that would do what you're asking for?

[Trinitou]

@Trinitou that'd be nice to have trigger port/events for the plugin. Those controls could indeed be mapped to hw controller. I think that would do what you're asking for?

Yes, I think that would do the job. To have the triggers as parameters would help so that they could be put into remote control pages but maybe that would confuse things (?)

[nakst]

I think the context menu API draft could work as-is for this purpose. When the host wants to query the plugin's 'actions', it can call clap_plugin_context_menu_t.populate with some special reserved value for the param_id indicating the 'global actions list'. Whether it actually displays the populated items in a menu or in some sort of list for assigning to controllers is up to the host.

[nakst]

Additionally, some action clap_ids could possibly be standardized, such as 'initialize current patch' or 'disable all effect units' (for a synthesizer). (Unless the CLAP API already has a way to do this?)

[abique]

Yes, I think that would do the job. To have the triggers as parameters would help so that they could be put into remote control pages but maybe that would confuse things (?)

Unlike parameters, triggers are state less. So they'd need their own thing.

[Trinitou]

Other thoughts:

• each action might be temporarily unavailable so there should be some enabled/disabled state for each action
  • if the host provides menu entries or action buttons for plugin actions they should appear enabled/disabled accordingly
• Perhaps the set of available actions might change during runtime so there could be a mechanism for rebuilding all plugin actions. That might be a point for later versions of a plugin action extension. Initially it might be sufficient to only support a fixed set of actions per plugin

[Trinitou]

I think it still would be nice to have a separate plugin actions/commands extension. But as I don't find the time for a pull request ATM, I'll close the issue for now.