diff options
Diffstat (limited to 'lv2/state')
| -rw-r--r-- | lv2/state/state.meta.ttl | 381 | ||||
| -rw-r--r-- | lv2/state/state.ttl | 370 |
2 files changed, 398 insertions, 353 deletions
diff --git a/lv2/state/state.meta.ttl b/lv2/state/state.meta.ttl index 784946d..ac3f2d6 100644 --- a/lv2/state/state.meta.ttl +++ b/lv2/state/state.meta.ttl @@ -1,7 +1,9 @@ @prefix dcs: <http://ontologi.es/doap-changeset#> . @prefix doap: <http://usefulinc.com/ns/doap#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . +@prefix lv2: <http://lv2plug.in/ns/lv2core#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . +@prefix state: <http://lv2plug.in/ns/ext/state#> . <http://lv2plug.in/ns/ext/state> a doap:Project ; @@ -73,5 +75,382 @@ rdfs:label "Initial release." ] ] - ] . + ] ; + lv2:documentation """ + +This extension defines a simple mechanism that allows hosts to save and restore +a plugin instance's state. The goal is for an instance's state to be +completely described by port values and a simple dictionary. + +The <q>state</q> defined here is conceptually a key:value dictionary, with URI keys +and values of any type. For performance reasons the key and value type are +actually a "URID", a URI mapped to an integer. A single key:value pair is +called a "property". + +This state model is simple yet has many benefits: + + * Both fast and extensible thanks to URID keys. + + * No limitations on possible value types. + + * Easy to serialise in almost any format. + + * Easy to store in a typical "map" or "dictionary" data structure. + + * Elegantly described in Turtle, so state can be described in LV2 data files + (including presets). + + * Does not impose any file formats, data structures, or file system + requirements. + + * Suitable for portable persistent state as well as fast in-memory snapshots. + + * Keys _may_ be well-defined and used meaningfully across several + implementations. + + * State _may_ be dynamic, but plugins are not required to have a dynamic + dictionary data structure available. + +To implement state, the plugin provides a state:interface to the host. To save +or restore, the host calls LV2_State_Interface::save() or +LV2_State_Interface::restore(), passing a callback to be used for handling a +single property. The host is free to implement property storage and retrieval +in any way. + +Since value types are defined by URI, any type is possible. However, a set of +standard types is defined by the [LV2 Atom](atom.html) extension. Use of these +types is recommended. Hosts MUST implement at least +[atom:String](atom.html#String), which is simply a C string. + +### Referring to Files + +Plugins may need to refer to existing files (e.g. loaded samples) in their +state. This is done by storing the file's path as a property just like any +other value. However, there are some rules which MUST be followed when storing +paths, see state:mapPath for details. Plugins MUST use the type +[atom:Path](atom.html#Path) for all paths in their state. + +Plugins are strongly encouraged to avoid creating files, instead storing all +state as properties. However, occasionally the ability to create files is +necessary. To make this possible, the host can provide the feature +state:makePath which allocates paths for plugin-created files. Plugins MUST +NOT create files in any other locations. + +### Plugin Code Example + + :::c + + /* Namespace for this plugin's keys. This SHOULD be something that could be + published as a document, even if that document does not exist right now. + */ + #define NS_MY "http://example.org/myplugin/schema#" + + #define DEFAULT_GREETING "Hello" + + LV2_Handle + my_instantiate(...) + { + MyPlugin* plugin = ...; + plugin->uris.atom_String = map_uri(LV2_ATOM__String); + plugin->uris.my_greeting = map_uri(NS_MY "greeting"); + plugin->state.greeting = strdup(DEFAULT_GREETING); + return plugin; + } + + LV2_State_Status + my_save(LV2_Handle instance, + LV2_State_Store_Function store, + LV2_State_Handle handle, + uint32_t flags, + const LV2_Feature *const * features) + { + MyPlugin* plugin = (MyPlugin*)instance; + const char* greeting = plugin->state.greeting; + + store(handle, + plugin->uris.my_greeting, + greeting, + strlen(greeting) + 1, // Careful! Need space for terminator + plugin->uris.atom_String, + LV2_STATE_IS_POD | LV2_STATE_IS_PORTABLE); + + return LV2_STATE_SUCCESS; + } + + LV2_State_Status + my_restore(LV2_Handle instance, + LV2_State_Retrieve_Function retrieve, + LV2_State_Handle handle, + uint32_t flags, + const LV2_Feature *const * features) + { + MyPlugin* plugin = (MyPlugin*)instance; + + size_t size; + uint32_t type; + uint32_t flags; + const char* greeting = retrieve( + handle, plugin->uris.my_greeting, &size, &type, &flags); + + if (greeting) { + free(plugin->state->greeting); + plugin->state->greeting = strdup(greeting); + } else { + plugin->state->greeting = strdup(DEFAULT_GREETING); + } + + return LV2_STATE_SUCCESS; + } + + const void* + my_extension_data(const char* uri) + { + static const LV2_State_Interface state_iface = { my_save, my_restore }; + if (!strcmp(uri, LV2_STATE__interface)) { + return &state_iface; + } + } + +### Host Code Example + + :::c + LV2_State_Status + store_callback(LV2_State_Handle handle, + uint32_t key, + const void* value, + size_t size, + uint32_t type, + uint32_t flags) + { + if ((flags & LV2_STATE_IS_POD)) { + // We only care about POD since we're keeping state in memory only. + // Disk or network use would also require LV2_STATE_IS_PORTABLE. + Map* state_map = (Map*)handle; + state_map->insert(key, Value(copy(value), size, type)); + return LV2_STATE_SUCCESS;; + } else { + return LV2_STATE_ERR_BAD_FLAGS; // Non-POD events are unsupported + } + } + + Map + get_plugin_state(LV2_Handle instance) + { + LV2_State* state = instance.extension_data(LV2_STATE__interface); + + // Request a fast/native/POD save, since we're just copying in memory + Map state_map; + state.save(instance, store_callback, &state_map, + LV2_STATE_IS_POD|LV2_STATE_IS_NATIVE); + + return state_map; + } + +### Extensions to this Specification + +It is likely that other interfaces for working with plugin state will be +developed as needed. This is encouraged, however everything SHOULD work within +the state _model_ defined here. That is, **do not complicate the state +model**. Implementations can assume the following: + + * The current port values and state dictionary completely describe a plugin + instance, at least well enough that saving and restoring will yield an + "identical" instance from the user's perspective. + + * Hosts are not expected to save and/or restore any other attributes of a + plugin instance. + +### The "Property Principle" + +The main benefit of this meaningful state model is that it can double as a +plugin control/query mechanism. For plugins that require more advanced control +than simple control ports, instead of defining a set of commands, define +properties whose values can be set appropriately. This provides both a way to +control and save that state "for free", since there is no need to define +commands _and_ a set of properties for storing their effects. In particular, +this is a good way for UIs to achieve more advanced control of plugins. + +This "property principle" is summed up in the phrase: "Don't stop; set playing +to false". + +This extension does not define a dynamic mechanism for state access and +manipulation. The [LV2 Patch](patch.html) extension defines a generic set of +messages which can be used to access or manipulate properties, and the [LV2 +Atom](atom.html) extension defines a port type and data container capable of +transmitting those messages. + +"""^^lv2:Markdown . + +state:interface + lv2:documentation """ + +A structure (LV2_State_Interface) which contains functions to be called by the +host to save and restore state. In order to support this extension, the plugin +must return a valid LV2_State_Interface from LV2_Descriptor::extension_data() +when it is called with URI LV2_STATE__interface. + +The plugin data file should describe this like so: + + :::turtle + @prefix state: <http://lv2plug.in/ns/ext/state#> . + + <plugin> + a lv2:Plugin ; + lv2:extensionData state:interface . + +"""^^lv2:Markdown . + +state:State + lv2:documentation """ + +This type should be used wherever instance state is described. The properties +of a resource with this type correspond directly to the properties of the state +dictionary (except the property that states it has this type). + +"""^^lv2:Markdown . + +state:loadDefaultState + lv2:documentation """ + +This feature indicates that the plugin has default state listed with the +state:state property which should be loaded by the host before running the +plugin. Requiring this feature allows plugins to implement a single state +loading mechanism which works for initialisation as well as restoration, +without having to hard-code default state. + +To support this feature, the host MUST restore the default state after +instantiating the plugin but before calling run(). + +"""^^lv2:Markdown . + +state:state + lv2:documentation """ + +This property may be used anywhere a state needs to be described, for example: + + :::turtle + @prefix eg: <http://example.org/> . + + <plugin-instance> + state:state [ + eg:somekey "some value" ; + eg:someotherkey "some other value" ; + eg:favourite-number 2 + ] . + +"""^^lv2:Markdown . + +state:mapPath + lv2:documentation """ + +This feature maps absolute paths to/from <q>abstract paths</q> which are stored +in state. To support this feature a host must pass an LV2_Feature with URI +LV2_STATE__mapPath and data pointed to an LV2_State_Map_Path to the plugin's +LV2_State_Interface methods. + +The plugin MUST map _all_ paths stored in its state (including those inside any +files). This is necessary so that hosts can handle file system references +correctly, for example to share common files, or bundle state for distribution +or archival. + +For example, a plugin may write a path to a state file like so: + + :::c + void write_path(LV2_State_Map_Path* map_path, FILE* myfile, const char* path) + { + char* abstract_path = map_path->abstract_path(map_path->handle, path); + fprintf(myfile, "%s", abstract_path); + free(abstract_path); + } + +Then, later reload the path like so: + + :::c + char* read_path(LV2_State_Map_Path* map_path, FILE* myfile) + { + /* Obviously this is not production quality code! */ + char abstract_path[1024]; + fscanf(myfile, "%s", abstract_path); + return map_path->absolute_path(map_path->handle, abstract_path); + } + +"""^^lv2:Markdown . + +state:makePath + lv2:documentation """ + +This feature allows plugins to create new files and/or directories. To support +this feature the host passes an LV2_Feature with URI LV2_STATE__makePath and +data pointed to an LV2_State_Make_Path to the plugin. The host may make this +feature available only during save by passing it to +LV2_State_Interface::save(), or available any time by passing it to +LV2_Descriptor::instantiate(). If passed to LV2_State_Interface::save(), the +feature MUST NOT be used beyond the scope of that call. + +The plugin is guaranteed a hierarchical namespace unique to that plugin +instance, and may expect the returned path to have the requested path as a +suffix. There is one such namespace, even if the feature is passed to both +LV2_Descriptor::instantiate() and LV2_State_Interface::save(). Beyond this, +the plugin MUST NOT make any assumptions about the returned paths. + +Like any other paths, the plugin MUST map these paths using state:mapPath +before storing them in state. The plugin MUST NOT assume these paths will be +available across a save/restore otherwise, that is, only mapped paths saved to +state are persistent, any other created paths are temporary. + +For example, a plugin may create a file in a subdirectory like so: + + :::c + char* save_myfile(LV2_State_Make_Path* make_path) + { + char* path = make_path->path(make_path->handle, "foo/bar/myfile.txt"); + FILE* myfile = fopen(path, 'w'); + fprintf(myfile, "I am some data"); + fclose(myfile); + return path; + } + +"""^^lv2:Markdown . + +state:threadSafeRestore + lv2:documentation """ + +If a plugin supports this feature, its LV2_State_Interface::restore method is +thread-safe and may be called concurrently with audio class functions. + +To support this feature, the host MUST pass a +[work:schedule](worker.html#schedule) feature to the restore method, which will +be used to complete the state restoration. The usual mechanics of the worker +apply: the host will call the plugin's work method, which emits a response +which is later applied in the audio thread. + +The host is not required to block audio processing while restore() and work() +load the state, so this feature allows state to be restored without dropouts. + +"""^^lv2:Markdown . + +state:freePath + lv2:documentation """ + +This feature provides a function that can be used by plugins to free paths that +were allocated by the host via other state features (state:mapPath and +state:makePath). + +"""^^lv2:Markdown . + +state:Changed + lv2:documentation """ + +A notification that the internal state of the plugin has been changed in a way +that the host can not otherwise know about. + +This is a one-way notification, intended to be used as the type of an +[Object](atom.html#Object) sent from plugins when necessary. + +Plugins SHOULD emit such an event whenever a change has occurred that would +result in a different state being saved, but not when the host explicity makes +a change which it knows is likely to have that effect, such as changing a +parameter. + +"""^^lv2:Markdown . diff --git a/lv2/state/state.ttl b/lv2/state/state.ttl index 2140309..de6d18b 100644 --- a/lv2/state/state.ttl +++ b/lv2/state/state.ttl @@ -5,388 +5,54 @@ <http://lv2plug.in/ns/ext/state> a lv2:Specification ; + rdfs:label "LV2 State" ; + rdfs:comment "An interface for LV2 plugins to save and restore state." ; rdfs:seeAlso <state.h> , - <state.meta.ttl> ; - lv2:documentation """ -<p>This extension defines a simple mechanism which allows hosts to save and -restore a plugin instance's state. The goal is for an instance's state to be -<em>completely</em> described by port values (as with all LV2 plugins) and a -simple dictionary.</p> - -<p>The <q>state</q> defined here is conceptually a key:value dictionary, with -URI keys and values of any type. For performance reasons the key and value -type are actually a <q>URID</q>, a URI mapped to an integer. A single -key:value pair is called a <q>property</q>.</p> - -<p>This state model is simple yet has many benefits:</p> -<ul> - <li>Both fast and extensible thanks to URID keys.</li> - <li>No limitations on possible value types.</li> - <li>Easy to serialise in almost any format.</li> - <li>Easy to store in a typical <q>map</q> or <q>dictionary</q> data - structure.</li> - <li>Elegantly described in Turtle, so state can be described in LV2 data - files (including presets).</li> - <li>Does not impose any file formats, data structures, or file system - requirements.</li> - <li>Suitable for portable persistent state as well as fast in-memory - snapshots.</li> - <li>Keys <em>may</em> be well-defined and used meaningfully across several - implementations.</li> - <li>State <em>may</em> be dynamic, but plugins are not required to have a - dynamic dictionary data structure available.</li> -</ul> - -<p>To implement state, the plugin provides a state:interface to the host. To -save or restore, the host calls LV2_State_Interface::save() or -LV2_State_Interface::restore(), passing a callback to be used for handling a -single property. The host is free to implement property storage and retrieval -in any way.</p> - -<p>Since value types are defined by URI, any type is possible. However, a set -of standard types is defined by the <a href="atom.html">LV2 Atom</a> -extension. Use of these types is recommended. Hosts MUST implement at least -<a href="atom.html#String">atom:String</a>, which is simply a C -string.</p> - -<h3>Referring to Files</h3> - -<p>Plugins may need to refer to existing files (e.g. loaded samples) in their -state. This is done by storing the file's path as a property just like any -other value. However, there are some rules which MUST be followed when storing -paths, see state:mapPath for details. Plugins MUST use the type <a -href="atom.html#Path">atom:Path</a> for all paths in their state.</p> - -<p>Plugins are strongly encouraged to avoid creating files, instead storing all -state as properties. However, occasionally the ability to create files is -necessary. To make this possible, the host can provide the feature -state:makePath which allocates paths for plugin-created files. Plugins MUST -NOT create files in any other locations.</p> - -<h3>Plugin Code Example</h3> - -<pre class="c-code"> - -/* Namespace for this plugin's keys. This SHOULD be something that could be - published as a document, even if that document does not exist right now. -*/ -#define NS_MY "http://example.org/myplugin/schema#" - -#define DEFAULT_GREETING "Hello" - -LV2_Handle -my_instantiate(...) -{ - MyPlugin* plugin = ...; - plugin->uris.atom_String = map_uri(LV2_ATOM__String); - plugin->uris.my_greeting = map_uri(NS_MY "greeting"); - plugin->state.greeting = strdup(DEFAULT_GREETING); - return plugin; -} - -LV2_State_Status -my_save(LV2_Handle instance, - LV2_State_Store_Function store, - LV2_State_Handle handle, - uint32_t flags, - const LV2_Feature *const * features) -{ - MyPlugin* plugin = (MyPlugin*)instance; - const char* greeting = plugin->state.greeting; - - store(handle, - plugin->uris.my_greeting, - greeting, - strlen(greeting) + 1, // Careful! Need space for terminator - plugin->uris.atom_String, - LV2_STATE_IS_POD | LV2_STATE_IS_PORTABLE); - - return LV2_STATE_SUCCESS; -} - -LV2_State_Status -my_restore(LV2_Handle instance, - LV2_State_Retrieve_Function retrieve, - LV2_State_Handle handle, - uint32_t flags, - const LV2_Feature *const * features) -{ - MyPlugin* plugin = (MyPlugin*)instance; - - size_t size; - uint32_t type; - uint32_t flags; - const char* greeting = retrieve( - handle, plugin->uris.my_greeting, &size, &type, &flags); - - if (greeting) { - free(plugin->state->greeting); - plugin->state->greeting = strdup(greeting); - } else { - plugin->state->greeting = strdup(DEFAULT_GREETING); - } - - return LV2_STATE_SUCCESS; -} - -const void* -my_extension_data(const char* uri) -{ - static const LV2_State_Interface state_iface = { my_save, my_restore }; - if (!strcmp(uri, LV2_STATE__interface)) { - return &state_iface; - } -} -</pre> - -<h3>Host Code Example</h3> - -<pre class="c-code"> -LV2_State_Status -store_callback(LV2_State_Handle handle, - uint32_t key, - const void* value, - size_t size, - uint32_t type, - uint32_t flags) -{ - if ((flags & LV2_STATE_IS_POD)) { - /* We only care about POD since we're keeping state in memory only. - For disk or network use, LV2_STATE_IS_PORTABLE must also be checked. - */ - Map* state_map = (Map*)handle; - state_map->insert(key, Value(copy(value), size, type)); - return 0; - } else { - return 1; /* Non-POD events are unsupported. */ - } -} - -Map -get_plugin_state(LV2_Handle instance) -{ - LV2_State* state = instance.extension_data(LV2_STATE__interface); - Map state_map; - /** Request a fast/native/POD save, since we're just copying in memory */ - state.save(instance, store_callback, &state_map, - LV2_STATE_IS_POD|LV2_STATE_IS_NATIVE); - return state_map; -} -</pre> - -<h3>Extensions to this Specification</h3> - -<p>It is likely that other interfaces for working with plugin state will be -developed as needed. This is encouraged, however everything SHOULD work within -the state <em>model</em> defined here. That is, <strong>do not complicate the -state model</strong>. Implementations can assume the following:</p> - -<ul> -<li>The current port values and state dictionary completely describe a plugin -instance, at least well enough that saving and restoring will yield an -<q>identical</q> instance from the user's perspective.</li> -<li>Hosts are not expected to save and/or restore any other attributes of a -plugin instance.</li> -</ul> - -<h3>The <q>Property Principle</q></h3> - -<p>The main benefit of this meaningful state model is that it can double as a -plugin control/query mechanism. For plugins that require more advanced control -than simple control ports, instead of defining a set of commands, define -properties whose values can be set appropriately. This provides both a way to -control and save that state <q>for free</q>, since there is no need to define -commands <em>and</em> a set of properties for storing their effects. In -particular, this is a good way for UIs to achieve more advanced control of -plugins.</p> - -<p>This <q>property principle</q> is summed up in the phrase: -<q>Don't stop; set playing to false</q>.</p> - -<p>This extension does not define a dynamic mechanism for state access and -manipulation. The <a href="patch.html">LV2 Patch</a> extension -defines a generic set of messages which can be used to access or manipulate -properties, and the <a href="atom.html">LV2 Atom</a> extension defines -a port type and data container capable of transmitting those messages.</p> -""" . + <state.meta.ttl> . state:interface a lv2:ExtensionData ; - lv2:documentation """ -<p>A structure (LV2_State_Interface) which contains functions to be called by -the host to save and restore state. In order to support this extension, the -plugin must return a valid LV2_State_Interface from -LV2_Descriptor::extension_data() when it is called with URI -LV2_STATE__interface.</p> - -<p>The plugin data file should describe this like so:</p> -<pre class="turtle-code"> -@prefix state: <http://lv2plug.in/ns/ext/state#> . - -<plugin> - a lv2:Plugin ; - lv2:extensionData state:interface . -</pre> -""" . + rdfs:label "interface" ; + rdfs:comment "A plugin interface for saving and restoring state." . state:State a rdfs:Class ; rdfs:label "State" ; - lv2:documentation """ -<p>A state dictionary. This type should be used wherever instance state is -described. The properties of a resource with this type correspond directly to -the properties of the state dictionary (except the property that states it has -this type).</p> -""" . + rdfs:comment "LV2 plugin state." . state:loadDefaultState a lv2:Feature ; - lv2:documentation """ -<p>This feature indicates that the plugin has default state listed with the -state:state property which should be loaded by the host before running the -plugin. Requiring this feature allows plugins to implement a single state -loading mechanism which works for initialisation as well as restoration, -without having to hard-code default state.</p> - -<p>To support this feature, the host MUST <q>restore</q> the default state -after instantiating the plugin but before calling run().</p> -""" . + rdfs:label "load default state" ; + rdfs:comment "A feature indicating that the plugin has default state." . state:state a rdf:Property ; rdfs:label "state" ; rdfs:range state:State ; - lv2:documentation """ -<p>The state of this instance. This property may be used anywhere a state -needs to be described, for example:</p> - -<pre class="turtle-code"> -@prefix eg: <http://example.org/> . - -<plugin-instance> - state:state [ - eg:somekey "some value" ; - eg:someotherkey "some other value" ; - eg:favourite-number 2 - ] . -</pre> -""" . + rdfs:comment "The state of an LV2 plugin instance." . state:mapPath a lv2:Feature ; - rdfs:label "map file paths" ; - lv2:documentation """ -<p>This feature maps absolute paths to/from <q>abstract paths</q> which are -stored in state. To support this feature a host must pass an LV2_Feature with -URI LV2_STATE__mapPath and data pointed to an LV2_State_Map_Path to the -plugin's LV2_State_Interface methods.</p> - -<p>The plugin MUST map <em>all</em> paths stored in its state (including those -inside any files in its state). This is necessary to enable host to handle -file system references correctly, e.g. for distribution or archival.</p> - -<p>For example, a plugin may write a path to a state file like so:</p> - -<pre class="c-code"> -void write_path(LV2_State_Map_Path* map_path, FILE* myfile, const char* path) -{ - char* abstract_path = map_path->abstract_path(map_path->handle, path); - fprintf(myfile, "%s", abstract_path); - free(abstract_path); -} -</pre> - -<p>Then, later reload the path like so:</p> - -<pre class="c-code"> -char* read_path(LV2_State_Map_Path* map_path, FILE* myfile) -{ - /* Obviously this is not production quality code! */ - char abstract_path[1024]; - fscanf(myfile, "%s", abstract_path); - return map_path->absolute_path(map_path->handle, abstract_path); -} -</pre> -""" . + rdfs:label "map path" ; + rdfs:comment "A feature for mapping between absolute and abstract file paths." . state:makePath a lv2:Feature ; - rdfs:label "create new file paths" ; - lv2:documentation """ -<p>This feature allows plugins to create new files and/or directories. To -support this feature the host passes an LV2_Feature with URI -LV2_STATE__makePath and data pointed to an LV2_State_Make_Path to the plugin. -The host may make this feature available only during save by passing it to -LV2_State_Interface::save(), or available any time by passing it to -LV2_Descriptor::instantiate(). If passed to LV2_State_Interface::save(), the -feature MUST NOT be used beyond the scope of that call.</p> - -<p>The plugin is guaranteed a hierarchical namespace unique to that plugin -instance, and may expect the returned path to have the requested path as a -suffix. There is <em>one</em> such namespace, even if the feature is passed to -both LV2_Descriptor::instantiate() <em>and</em> LV2_State_Interface::save(). -Beyond this, the plugin MUST NOT make any assumptions about the returned -paths.</p> - -<p>Like any other paths, the plugin MUST map these paths using state:mapPath -before storing them in state. The plugin MUST NOT assume these paths will be -available across a save/restore otherwise, i.e. only mapped paths saved to -state are persistent, any other created paths are temporary.</p> - -<p>For example, a plugin may create a file in a subdirectory like so:</p> - -<pre class="c-code"> -char* save_myfile(LV2_State_Make_Path* make_path) -{ - char* path = make_path->path(make_path->handle, "foo/bar/myfile.txt"); - FILE* myfile = fopen(path, 'w'); - fprintf(myfile, "I am some data"); - fclose(myfile); - return path; -} -</pre> -""" . + rdfs:label "make path" ; + rdfs:comment "A feature for creating new files and directories." . state:threadSafeRestore a lv2:Feature ; rdfs:label "thread-safe restore" ; - lv2:documentation """ -<p>If a plugin supports this feature, its LV2_State_Interface::restore method -is thread-safe and may be called concurrently with audio class functions.</p> - -<p>To support this feature, the host MUST pass a <a -href="worker.html#schedule">work:schedule</a> feature to the restore -method, which will be used to complete the state restoration. The usual -mechanics of the worker apply: the host will call the plugin's work method, -which emits a response which is later applied in the audio thread.</p> - -<p>The host is not required to block run() while restore() and work() load the -state, so this feature allows state to be restored without dropouts.</p> -""" . + rdfs:comment "A feature indicating support for thread-safe state restoration." . state:freePath a lv2:Feature ; - rdfs:label "free a file path" ; - lv2:documentation """ -<p>This feature provides a function that can be used by plugins to free paths -that were allocated by the host via other state features (state:mapPath and -state:makePath).</p> -""" . + rdfs:label "free path" ; + rdfs:comment "A feature for freeing paths allocated by the host." . state:Changed a rdfs:Class ; - rdfs:label "State changed" ; - lv2:documentation """ -<p>A notification that the internal state of the plugin has been changed in a -way that the host can not otherwise know about.</p> - -<p>This is a one-way notification, intended to be used as the type of an <a -href="atom.html#Object">Object</a> sent from plugins when -necessary.</p> - -<p>Plugins SHOULD emit such an event whenever a change has occurred that would -result in a different state being saved, but not when the host explicity makes -a change which it knows is likely to have that effect, such as changing a -parameter.</p> -""" . + rdfs:label "Changed" ; + rdfs:comment "A notification that the internal state of the plugin has changed." . |