[LV2] State restoration while rolling

[David Robillard]

The current revision of the state extension has the rule that the
restore function can not be called simultaneously with any other
function.  Save may happen any time, while rolling.  Neither have
real-time restrictions.

This seemed reasonable when thinking of state only as a "load session"
kind of thing, but the problem is state also gets used for presets, and
not being able to switch presets while rolling is pretty unfortunate.

I see two solutions:

1) Provide a separate LV2_State_Interface under a different URI to mean
both functions are in the audio class (so they are real-time safe if the
plugin is, can be called in the audio thread, and don't have to worry
about concurrency)

2) Separate restoring state from actually *applying* that restored
state.  So, the restore function would restore properties, allocate
stuff, load files, whatever, but store all that state in some struct
(opaque to the host), return that, and the host would apply it in the
audio thread.  Something like (methods on the plugin):

/** Returns loaded state, an opaque struct (non realtime) */
PluginState* load_state(
    LV2_Handle                  instance,
    LV2_State_Retrieve_Function retrieve,
    LV2_State_Handle            handle,
    uint32_t                    flags,
    const LV2_Feature *const *  features);

typedef void (*PluginStateFreeFunc)(PluginState*);

/** Applies state, and returns old state which can be freed with
free_state (realtime) */
PluginState* apply_state(
    LV2_Handle         instance,
    OpaquePluginState* state,
    LV2_State_Handle   handle);

void free_state(PluginState*);

There is also the question of whether the save threading rules need to
change, or what.  It could be complex to implement save while rolling if
state changes in the audio thread.  There is kind of a thread-rules
permutation problem here, but breaking save and restore out in to
separate structs would be a considerable change.

Basically I'm trolling for opinions here.  Option 2 actually seems quite
nice, but lots of big existing systems probably can't implement it.  I'm
pretty sure LinuxSampler can't, for example.  So even if it was done
like this, some notion of "I can apply state in the audio thread" is
still needed.

-dr