From 4db67120efca2d4c200d2e1ba5cf3d7b97cab97e Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sat, 22 Sep 2018 20:38:01 +0200 Subject: Install standard headers to simpler include paths --- lv2/lv2plug.in/ns/ext/state/state.ttl | 382 ---------------------------------- 1 file changed, 382 deletions(-) delete mode 100644 lv2/lv2plug.in/ns/ext/state/state.ttl (limited to 'lv2/lv2plug.in/ns/ext/state/state.ttl') diff --git a/lv2/lv2plug.in/ns/ext/state/state.ttl b/lv2/lv2plug.in/ns/ext/state/state.ttl deleted file mode 100644 index c86fea7..0000000 --- a/lv2/lv2plug.in/ns/ext/state/state.ttl +++ /dev/null @@ -1,382 +0,0 @@ -@prefix lv2: . -@prefix rdf: . -@prefix rdfs: . -@prefix state: . - - - a lv2:Specification ; - rdfs:seeAlso , - ; - lv2:documentation """ -

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 -completely described by port values (as with all LV2 plugins) and a -simple dictionary.

- -

The state 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 -extension. Use of these types is recommended. Hosts MUST implement at least -atom: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 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

- -
-
-/* 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

- -
-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;
-}
-
- -

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 extension -defines a generic set of messages which can be used to access or manipulate -properties, and the LV2 Atom extension defines -a port type and data container capable of transmitting those messages.

-""" . - -state:interface - a lv2:ExtensionData ; - 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:

-
-@prefix state: <http://lv2plug.in/ns/ext/state#> .
-
-<plugin>
-    a lv2:Plugin ;
-    lv2:extensionData state:interface .
-
-""" . - -state:State - a rdfs:Class ; - rdfs:label "State" ; - lv2:documentation """ -

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).

-""" . - -state:loadDefaultState - a lv2:Feature ; - 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().

-""" . - -state:state - a rdf:Property ; - rdfs:label "state" ; - rdfs:range state:State ; - lv2:documentation """ -

The state of this instance. This property may be used anywhere a state -needs to be described, for example:

- -
-@prefix eg: <http://example.org/> .
-
-<plugin-instance>
-    state:state [
-        eg:somekey "some value" ;
-        eg:someotherkey "some other value" ;
-        eg:favourite-number 2
-    ] .
-
-""" . - -state:mapPath - a lv2:Feature ; - rdfs:label "map file paths" ; - lv2:documentation """ -

This feature maps absolute paths to/from abstract paths 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 in its state). This is necessary to enable host to handle -file system references correctly, e.g. for distribution or archival.

- -

For example, a plugin may write a path to a state file like so:

- -
-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:

- -
-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);
-}
-
-""" . - -state:makePath - a lv2:Feature ; - rdfs:label "create new file paths" ; - 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, i.e. 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:

- -
-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;
-}
-
-""" . - -state:threadSafeRestore - a lv2:Feature ; - rdfs:label "thread-safe restore" ; - 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 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 run() while restore() and work() load the -state, so this feature allows state to be restored without dropouts.

-""" . - -state:Changed - a rdfs:Class ; - rdfs:label "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 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.

-""" . -- cgit v1.2.1