Resource
type: Class
comment: An LV2 Resource (e.g. plugin, specification, or any other LV2 related thing).

Specification
type: Class
subclass of: Resource
documentation: An LV2 specification (i.e. this specification, or an LV2 extension). Specification data, like plugin data, is distributed in bundles so hosts may discover all present LV2 data.

documentation
type: Property
type: AnnotationProperty
range: Literal
documentation: Relates a Resource to documentation markup. The value of this property MUST be a string literal which is a valid XHTML Basic 1.1 fragment suitable for use as the content of the element. This can be used by hosts to provide rich online documentation or by tools to generate external documentation pages. The standard language tagging facility of RDF can be used to provide multi-lingual documentation. XHTML Basic is a W3C Recommendation which defines a basic subset of XHTML intended to be reasonable to implement with limited resources (e.g. on embedded devices). See XHTML Basic, Section 3 for a list of legal tags.

lv2core
type: Specification
type: Ontology
type: Project
imports: foaf.owl
imports: doap.owl
license: isc
name: LV2
homepage: http://lv2plug.in
created: 2004-04-21
shortdesc: An audio plugin interface specification
programming-language: C
release:
  revision: 4.0
  created: 2011-03-18
maintainer: Steve Harris
maintainer: David Robillard
documentation: Overview LV2 is an interface for writing audio processors, or plugins, in C/C++ which can be dynamically loaded into many applications, or hosts. This core specification is simple and minimal, but is designed so that extensions can be defined to add more advanced features, making it possibly to implement nearly any feature imaginable. LV2 maintains a strong distinction between code and data. Plugin code is in a shared library, while data is in a companion data file written in Turtle. Code, data, and any other resources (e.g. waveforms) are shipped together in a bundle directory. The code contains only the executable portions of the plugin which inherently must be written in code. All other data is provided in the data file(s). This makes plugin data flexible and extensible, and allows the host to do everything but run the plugin without loading or executing any code. Among other advantages, this makes hosts more robust (broken plugins can't crash a host during discovery) and allows generic tools and non-C programs to work with LV2 data. LV2 itself and extensions are distributed in a similar way. An LV2 plugin library is suitable for dynamic loading (e.g. via dlopen()) and provides one or more plugin descriptors via the lv2_descriptor() function. These can be instantiated to create plugin instances, which can be run directly on data or connected together to perform advanced signal processing tasks. Plugins communicate via ports, which can transmit any type of data. Data is processed by first connecting each port to a buffer, then repeatedly calling a plugin's run() method to process blocks of data. This core specification defines two types of port, equivalent to those in LADSPA: lv2:ControlPort and lv2:AudioPort. Audio ports contain arrays with one float element per sample, allowing a block of audio to be processed in a single call to run(). Control ports contain single float values, which are fixed and valid for the duration of the call to run(). Thus the control ra…

PluginBase
type: Class
subclass of: Resource
documentation: An abstract plugin-like resource that MAY not actually be an LV2 plugin (e.g. may not actually have a plugin binary). PluginBase SHOULD be used as a base type for any resource that may have ports or otherwise mimic the structure of a Plugin (e.g. a preset), since hosts and other tools already understand this structure.

Plugin
type: Class
subclass of: PluginBase
subclass of: Restriction
  on property: name
  some values from: string
  comment: A Plugin MUST have at least one doap:name that is a string with no language tag.
documentation: The class which represents an LV2 plugin. To be discovered by hosts, plugins MUST explicitly have rdf:type lv2:Plugin listed in their bundle's manifest, e.g.: <http://example.org/my-plugin> a lv2:Plugin . Plugins SHOULD have a doap:license property whenever possible. The doap:name property should be at most a few words in length using title capitalization, e.g. Tape Delay Unit. Use doap:shortdesc or doap:description for more detailed descriptions.

Port
type: Class
subclass of: Resource
subclass of: Restriction
  on property: index
  all values from: nonNegativeInteger
  cardinality: 1
  comment: A port MUST have a single lv2:index which is of type xsd:nonNegativeInteger (e.g. a non-negative integer literal in Turtle). The actual RDF datatype of the index MAY be xsd:integer (which is what a generic Turtle parser will do), but the value itself MUST be non-negative.
subclass of: Restriction
  on property: symbol
  some values from: string
  comment: A port MUST have a single lv2:symbol which is of type xsd:string with no language tag.
subclass of: Restriction
  on property: name
  some values from: string
  comment: A port MUST have at least one lv2:name which is of type xsd:string.
documentation: The class which represents an LV2 port. All LV2 port descriptions MUST have a rdf:type that is one of lv2:Port lv2:InputPort or lv2:OutputPort. Additionally there MUST be at least one other rdf:type which more precisely describes type of the port (e.g. lv2:AudioPort). Hosts that do not support a specific port class MUST NOT instantiate the plugin, unless that port has the connectionOptional property set (in which case the host can simply connect that port to NULL). If a host is interested in plugins to insert in a certain signal path (e.g. stereo audio), it SHOULD consider all the classes of a port to determine which ports are most suitable for connection (e.g. by ignoring ports with additional classes the host does not recognize). A port has two identifiers: a (numeric) index, and a (textual) symbol. The index can be used as an identifier at run-time, but persistent references to ports (e.g. in a saved preset) MUST use the symbol. A symbol is guaranteed to refer to the same port on all plugins with a given URI. An index does NOT necessarily refer to the same port on all plugins with a given URI (i.e. the index for a port may differ between plugin binaries).

Input port
type: Class
subclass of: Port
comment: Ports of this type will be connected to a pointer to some value, which will be read by the plugin during their run method.

Output port
type: Class
subclass of: Port
comment: Ports of this type will be connected to a pointer to some value, which will be written to by the plugin during their run method.

Control port
type: Class
subclass of: Port
documentation: Ports of this type will be connected to a pointer to a single value of C type float.

Audio port
type: Class
subclass of: Port
documentation: Ports of this type will be connected to an array of length sample_count with elements of C type float.

port
type: Property
type: ObjectProperty
domain: PluginBase
range: Port
comment: Relates a Plugin to the Ports it contains

minor version
type: Property
type: DatatypeProperty
domain: Resource
range: nonNegativeInteger
documentation: The minor version of an LV2 Resource. This property is used (along with lv2:microVersion) by hosts to distinguish different versions of a compatible resource, e.g. to load only the bundle with the most recent version. The version of an LV2 resource is composed of two fields: minor version, and micro version. These have the usual semantics: The minor version MUST be incremented when backwards (but not forwards) compatible additions are made, e.g. the addition of a port to a plugin. The micro version is incremented for changes which do not affect compatibility at all, e.g. bug fixes or documentation updates. Note there is deliberately no concept of a major version: all versions of an LV2 resource with a given URI are by definition backwards compatible. More precisely: replacing a resource with a newer version of that resource MUST NOT break anything. If a change is made which breaks this rule, the URI of the resource MUST be changed. In contexts where a full (e.g. SemVer conformant) version number is required, the major version of all released LV2 resources is 1. Plugins and extensions MUST adhere to the following rules: All versions of a plugin with a given URI MUST have the same set of mandatory (i.e. not lv2:connectionOptional) ports with respect to lv2:symbol and rdf:type. In other words, every port on a specific version of a plugin has a lv2:symbol and a set of rdf:types; all future versions of that plugin are guaranteed to have a port with the same lv2:symbol and at least those rdf:types. New types may be added only if doing so does not break compatibility, i.e. if old hosts will continue to work correctly with the new plugin. New ports MAY be added without changing the plugin URI if and only if they are lv2:connectionOptional and the minor version is incremented. The minor version MUST be incremented if the index of any port (identified by its symbol) is changed. All versions of an extension MUST be compatible in the sense that an implementation of the new vers…

micro version
type: Property
type: DatatypeProperty
domain: Resource
range: nonNegativeInteger
documentation: The micro component of a Resource's version. Releases of plugins and extensions MUST be explicitly versioned. Correct version numbers MUST always be maintained for any versioned resource that is published. For example, after a release, if a change is made in the development version in source control, the micro version MUST be incremented (to an odd number) to distinguish this modified version from the previous release. This property describes half of a resource version. For detailed documentation on LV2 resource versioning, see lv2:minorVersion.

binary
type: Property
type: ObjectProperty
domain: Resource
range: Thing
documentation: The binary of an LV2 resource. The value of this property must be a URI that resolves to a shared library object (the actual type of this library is system specific). This is a required property of a Plugin which MUST be included in the bundle's manifest.ttl file. The lv2:binary of an lv2:Plugin is the shared object containing the lv2_descriptor() function which can be used to access the descriptor for that plugin. This property may be used similarly by extensions to relate other resources to their implementations.

Applies to
type: Property
type: ObjectProperty
domain: Resource
range: Plugin
documentation: Specifies that a resource is related to a plugin. This is primarily intended for discovery purposes: bundles that describe resources that work with particular plugins (e.g. presets or user interfaces) SHOULD use this predicate in manifest.ttl to relate the resource to the applicable plugin(s), e.g.: <thing> a ext:Thing ; lv2:appliesTo <plugin> ; rdfs:seeAlso <thing.ttl> . Particularly for large amounts of data, this is preferable to extending the plugin description with rdfs:seeAlso since the host may choose if/when to load the data, knowing that it describes an additional resource and not the plugin itself.

index
type: Property
type: DatatypeProperty
domain: Port
range: nonNegativeInteger
comment: Specifies the index of the port, passed as an argument to the connect port function. The index uniqely identifies the port on an instance of the plugin.

symbol
type: Property
type: DatatypeProperty
comment: A short name used as a machine and human readable identifier. The first character must be one of _, a-z or A-Z and subsequenct characters can be from _, a-z, A-Z and 0-9. A language tag MUST NOT be used on this property. The symbol uniquely identifies the port on a plugin with a given URI (i.e. the plugin author MUST change the plugin URI if a port symbol is changed or removed).

name
type: Property
type: DatatypeProperty
domain: Port
comment: A display name for labeling the Port in a user interface. This property is required for Ports, but MUST NOT be used by the host for port identification. The plugin author may change the values of this property without changing the Plugin URI.

Port value point
type: Class
documentation: A Point describes an interesting value in a Port's range (much like a labeled notch on a physical knob). A Point MUST have at least one rdfs:label which is a string. A Point MUST have exactly one rdf:value with a type that is compatible with the type of the corresponding Port.

ScalePoint
type: Class
subclass of: Port value point
comment: A single float Point (for control inputs).

Scale point
type: Property
type: ObjectProperty
domain: Port
range: ScalePoint
comment: Relates a Port to its ScalePoints.

Default value
type: Property
type: DatatypeProperty
domain: Port
comment: The default value that the host SHOULD set this port to when there is no other information available.

Minimum value
type: Property
type: DatatypeProperty
domain: Port
documentation: A hint to the host for the minimum useful value that the port will use. This is a soft limit; the plugin is required to gracefully accept all values in the range of a port's data type.

Maximum value
type: Property
type: DatatypeProperty
domain: Port
documentation: A hint to the host for the maximum useful value that the port will use. This is a soft limit; the plugin is required to gracefully accept all values in the range of a port's data type.

Feature
type: Class
subclass of: Resource
comment: An additional feature which a plugin or other resource may use or require.

Optional feature
type: Property
type: ObjectProperty
domain: Resource
range: Feature
documentation: Signifies that a plugin or other resource supports a certain feature. If the host supports this feature, it MUST pass its URI and any additional data to the plugin in LV2_Descriptor::instantiate(). The plugin MUST NOT fail to instantiate if an optional feature is not supported by the host.

Required feature
type: Property
type: ObjectProperty
domain: Resource
range: Feature
documentation: Signifies that a plugin or other resource requires a certain feature. If the host supports this feature, it MUST pass its URI and any additional data to the plugin in LV2_Descriptor::instantiate(). The plugin MUST fail to instantiate if a required feature is not present; hosts SHOULD always check this before attempting to instantiate a plugin (i.e. discovery by attempting to instantiate is strongly discouraged).

Extension Data
type: Class
subclass of: Resource
comment: Additional data and/or functions a plugin may return from LV2_Descriptor:extension_data() which can be used to add additional API beyond that defined by LV2_Descriptor.

Available extension data
type: Property
type: ObjectProperty
domain: Resource
range: Extension Data
documentation: Signifies that a plugin provides additional data or functions (as defined by some extension) via LV2:Descriptor::instantiate().

Has a live (realtime) dependency
type: Feature
documentation: Indicates that the plugin has a real-time dependency (e.g. queues data from a socket) and so its output must not be cached or subject to significant latency, and calls to the run method should be done in rapid succession. This property is not related to hard real-time execution requirements (see lv2:hardRTCapable).

In-place broken
type: Feature
documentation: Indicates that the plugin may cease to work correctly if the host elects to use the same data location for both input and output. Plugins that will fail to work correctly if ANY input port is connected to the same location as ANY output port MUST require this Feature. Doing so should be avoided as it makes it impossible for hosts to use the plugin to process data in-place.

Hard realtime capable
type: Feature
documentation: Indicates that the plugin is capable of running not only in a conventional host but also in a hard real-time environment. To qualify for this the plugin MUST satisfy all of the following: The plugin MUST NOT use malloc(), free() or other heap memory management functions within its Audio class functions. The plugin MUST NOT attempt to make use of any library functions in its Audio class functions, unless those functions themselves adhere to these rules (i.e. are hard realtime safe). The plugin MAY assume the standard C and C math library functions are safe. The plugin will not access files, devices, pipes, sockets, IPC or any other mechanism that might result in process or thread blocking within its Audio class functions. The plugin will take an amount of time to execute a run() call approximately of form A + B * sample_count where A and B depend on the machine and host in use. This amount of time MUST NOT depend on input signals or plugin state. Note these rules apply to the connect_port() function as well as run().

Port property
type: Class
comment: A port property - a useful piece of information that allows a host to make more sensible decisions (e.g. to provide a better interface).

Port property
type: Property
type: ObjectProperty
domain: Port
range: Port property
comment: Relates Ports to PortProperties. The PortProperty may be ignored without catastrophic effects, though it may be useful e.g. for providing a sensible interface for the port.

Optionally connected port
type: Port property
comment: Indicates that this port does not have to be connected to valid data by the host. If it is to be disconnected then the port MUST set to NULL with a call to the connectPort method.

Latency reporting port
type: Port property
documentation: Indicates that the port is used to express the processing latency incurred by the plugin, expressed in samples. The latency may be affected by the current sample rate, plugin settings, or other factors, and may be changed by the plugin at any time. Where the latency is frequency dependent the plugin may choose any appropriate value. If a plugin introduces latency it MUST provide EXACTLY ONE port with this property set which informs the host of the correct latency. In fuzzy cases the value output should be the most reasonable based on user expectation of input/output alignment (eg. musical delay/echo plugins should not report their delay as latency, as it is an intentional effect).

Toggled
type: Port property
documentation: Indicates that the data item should be considered a Boolean toggle. Data less than or equal to zero should be considered off or false, and data above zero should be considered on or true.

Sample rate
type: Port property
comment: Indicates that any bounds specified should be interpreted as multiples of the sample rate. For instance, a frequency range from 0Hz to the Nyquist frequency (half the sample rate) could be requested by this property in conjunction with lv2:minimum 0.0 and lv2:maximum 0.5. Hosts that support bounds at all MUST support this property.

Integer
type: Port property
comment: Indicates that a port's reasonable values are integers (eg. a user interface would likely wish to provide a stepped control allowing only integer input). A plugin MUST operate reasonably even if such a port has a non-integer input.

Enumeration
type: Port property
comment: Indicates that a port's only reasonable values are the scale points defined for that port. A host SHOULD NOT allow a user to set the value of such a port to anything other than a scale point. However, a plugin MUST operate reasonably even if such a port has an input that is not a scale point, preferably by simply choosing the largest enumeration value less than or equal to the actual input value (i.e. round the input value down).

Generator
type: Class
subclass of: Plugin
comment: Any plugin that generates sound internally, rather than processing its input.

Instrument
type: Class
subclass of: Generator
comment: Any plugin that is intended to be played as a musical instrument.

Oscillator
type: Class
subclass of: Generator

Utility
type: Class
subclass of: Plugin
comment: Includes things like mathematical functions and non-musical delays.

Converter
type: Class
subclass of: Utility
comment: Any plugin that converts some form of input into a different form of output.

Analyser
type: Class
subclass of: Utility
comment: Any plugin that analyses input to output some useful information.

Mixer
type: Class
subclass of: Utility
comment: A plugin which mixes some number of inputs into some number of outputs.

Simulator
type: Class
subclass of: Plugin
comment: Plugins that aim to duplicate the effect of some environmental effect or musical equipment.

Delay
type: Class
subclass of: Plugin
comment: Plugins that intentionally delay their input signal as an effect.

Modulator
type: Class
subclass of: Plugin

Reverb
type: Class
subclass of: Plugin
subclass of: Simulator
subclass of: Delay

Phaser
type: Class
subclass of: Modulator

Flanger
type: Class
subclass of: Modulator

Chorus
type: Class
subclass of: Modulator

Filter
type: Class
subclass of: Plugin

Lowpass
type: Class
subclass of: Filter

Bandpass
type: Class
subclass of: Filter

Highpass
type: Class
subclass of: Filter

Comb
type: Class
subclass of: Filter

Allpass
type: Class
subclass of: Filter

Equaliser
type: Class
subclass of: Filter

Parametric
type: Class
subclass of: Equaliser

Multiband
type: Class
subclass of: Equaliser

Spatial
type: Class
subclass of: Plugin
comment: Plugins that manipulate the position of audio in space (e.g. panning, stereo width, surround encoding, etc.).

Spectral
type: Class
subclass of: Plugin
comment: Plugins that alter the spectral properties (e.g. frequency) of audio.

Pitch Shifter
type: Class
subclass of: Spectral

Amplifier
type: Class
subclass of: Dynamics

Distortion
type: Class
subclass of: Plugin

Waveshaper
type: Class
subclass of: Distortion

Dynamics
type: Class
subclass of: Plugin
comment: Plugins that alter the envelope or dynamic range of audio.

Compressor
type: Class
subclass of: Dynamics

Expander
type: Class
subclass of: Dynamics

Limiter
type: Class
subclass of: Dynamics

Gate
type: Class
subclass of: Dynamics

Function
type: Class
subclass of: Utility

Constant
type: Class
subclass of: Generator