Undo / redo state extension (lightweight state updates)

[sagamusix]

This mostly comes from the perspective of a (at the moment VST2-only) host developer and feature requests for said host that aren't easy (or possible at all) to implement with VST2, but maybe it would be possible with CLAP.

A feature request for my host was to integrate plugins into its existing Undo/Redo system. For the most simple plugins that don't use opaque state chunks and have no custom GUI, this can be somewhat easy to implement because the host is in control of all state changes, so they can simply be recorded to an undo buffer.
However, once a custom plugin GUI is used, things become more difficult - if you receive an automation event from the plugin, you need to know the previous state of that parameter. Or if e.g. toggling one parameter automatically changes three other parameters - optimally you'd want to store that as just one undo / redo step.
Add opaque state chunks and it can get become even more difficult to figure out for a host what has changed - and at least in the case of VST2 it was entirely possible that no change was observable in terms of automatable plugin parameters. In this case, requesting an opaque state chunk on every user interaction is simply not feasible - as some extreme plugins take a second or two to generate that chunk, and it can be huge (several MB).

I see two solutions:

1. For "well-behaved" plugins, a CLAP plugin could declare that all state changes are observable through simple parameter changes, and the host can then just record those parameter changes. This would reduce the work required for plugin authors that don't have complex state changes. This probably needs a possibility to batch parameter changes though, e.g. when changing a preset you don't want 99 individual undo states for all parameters of the plugin.

2. For more complex plugins, I could imagine an extension where the plugin notifies the host of any changes that should be added to the undo buffer. The host could then insert an event into its own Undo/Redo buffer and call a plugin function when this state should be undo/redone.
   The state passed to the host should at least consist of a string describing the change. Maybe also some sort of cookie/ID so that it's guaranteed that the plugin really undoes the change that the host requested to undo/redo. Instead of the host requesting a full opaque state chunk on every change, the plugin itself is responsible for recording whatever parameter changes are required.

Thoughts/ideas/...?

[baconpaul]

So we just implemented full undo in surge and i know u-he has also.

I really like the idea of being able to share my (opaque) events with the DAW undo stack. Would be very powerful.

I would push back on saying 'well behaved' plugins expose every feature through their parameter API. Lets call those something else (like 'parameters fully cover model') but know what you mean there.

So I think this is definitely worth thinking about

My top requirement would be: I can send you an opaque blob and you send it back to me. Just bytes out and bytes in to the undo buffer. And sometimes those blobs can be big. I'll deal with all the semantics myself. So clearly a 'style' flag to distinguish between how much or little the plugin wants to delegate to the DAW will matter.

[defiantnerd]

This could also be a nice hinting in the state-context extension..