state
type: Specification
name: LV2 State
shortdesc: An interface for LV2 plugins to save and restore state.
license: isc
release:
  revision: 0.8
  created: 2012-03-30
  blame: me
developer: paniq
developer: me
maintainer: me
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 th…

interface
type: ExtensionData
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 .

Plugin Instance State
type: Class
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
type: Property
range: Plugin Instance State
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 ] .

Support for storing paths in state
type: Feature
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); }

Support for creating new files and directories
type: Feature
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; }