Save plugin state using a host-provided store callback.
@param instance The instance handle of the plugin.
@param store The host-provided store callback.
@param handle An opaque pointer to host data which MUST be passed as the
handle parameter to store if it is called.
@param flags Flags describing desired properties of this save. These
flags may be used to determine the most appropriate values to store.
@param features Extensible parameter for passing any additional
features to be used for this save.
The plugin is expected to store everything necessary to completely
restore its state later. Plugins SHOULD store simple POD data whenever
possible, and consider the possibility of state being restored much
later on a different machine.
The handle pointer and store function MUST NOT be used
beyond the scope of save().
This function has its own special threading class: it may not be called
concurrently with any "Instantiation" function, but it may be called
concurrently with functions in any other class, unless the definition of
that class prohibits it (e.g. it may not be called concurrently with a
"Discovery" function, but it may be called concurrently with an "Audio"
function. The plugin is responsible for any locking or lock-free
techniques necessary to make this possible.
Note that in the simple case where state is only modified by restore(),
there are no synchronization issues since save() is never called
concurrently with restore() (though run() may read it during a save).
Plugins that dynamically modify state while running, however, must take
care to do so in such a way that a concurrent call to save() will save a
consistent representation of plugin state for a single instant in time.
Save plugin state using a host-provided store callback.
@param instance The instance handle of the plugin. @param store The host-provided store callback. @param handle An opaque pointer to host data which MUST be passed as the handle parameter to store if it is called. @param flags Flags describing desired properties of this save. These flags may be used to determine the most appropriate values to store. @param features Extensible parameter for passing any additional features to be used for this save.
The plugin is expected to store everything necessary to completely restore its state later. Plugins SHOULD store simple POD data whenever possible, and consider the possibility of state being restored much later on a different machine.
The handle pointer and store function MUST NOT be used beyond the scope of save().
This function has its own special threading class: it may not be called concurrently with any "Instantiation" function, but it may be called concurrently with functions in any other class, unless the definition of that class prohibits it (e.g. it may not be called concurrently with a "Discovery" function, but it may be called concurrently with an "Audio" function. The plugin is responsible for any locking or lock-free techniques necessary to make this possible.
Note that in the simple case where state is only modified by restore(), there are no synchronization issues since save() is never called concurrently with restore() (though run() may read it during a save).
Plugins that dynamically modify state while running, however, must take care to do so in such a way that a concurrent call to save() will save a consistent representation of plugin state for a single instant in time.