Add the ability for plugins to opt-in to asyncronous state calls

russellmcc commented 1 year ago

This adds a new function on state-context that allows the plugin to opt in to receiving save and load calls on a new "state-thread" symbolic thread. Hosts could use this to parallelize loading and saving session state, which can greatly reduce the time it takes to load or save a large session.

This came out of discussion on #255, and is opened as a PR in the hopes that looking at a concrete change proposal is more productive than discussing in the abstract. I'm happy to reject this and continue the discussion somewhere else if that's more appropriate.

Currently left unaddressed is the idea of activating also on a background thread, raised in this comment. I could use ideas on how to allow this. Perhaps state-thread is not a good idea and it should be called bg-thread or something like that?

abique commented 11 months ago

I will propose a different approach which will cover both loading a state or activating the plugin.

abique commented 11 months ago

Here is my proposal: https://github.com/free-audio/clap/pull/343

defiantnerd commented 11 months ago

We still need to extend the enum:

enum clap_plugin_state_context_type {
   // suitable for duplicating a plugin instance
   CLAP_STATE_CONTEXT_FOR_DUPLICATE = 1,

   // suitable for loading a state as a preset
   CLAP_STATE_CONTEXT_FOR_PRESET = 2,
};

with a CLAP_STATE_CONTEXT_FOR_PROJECT constant, except that this would be the default?

Resource allocations during a project load linked with enumerated unique resources (hardware!) can only safely be restored properly when properly signalled.

free-audio / clap

Add the ability for plugins to opt-in to asyncronous state calls #310