Any plugin that analyses input to output some useful information.

Ports of this type will be connected to an array of length sample_count with elements of C type float.

Ports of this type have the same buffer format as an lv2:AudioPort, except the buffer represents audio-rate control data rather than audio. Like an lv2:ControlPort, a CVPort SHOULD have properties describing its value (e.g. lv2:minimum, lv2:maximum, and lv2:default), and may be presented to the user as a control.

It is generally safe to connect an audio output to a CV input, but not vice versa. Hosts SHOULD take care to prevent data from a CVPort port from being used as audio.

A specific channel, e.g. left or right. A channel may be audio, or another type such as a MIDI control stream.

Ports of this type will be connected to a pointer to a single value of C type float.

Any plugin that converts some form of input into a different form of output.

Plugins that intentionally delay their input signal as an effect.

The designation (or assignment) of an input or output. A designation is metadata that describes the meaning or role of data. By assigning a designation to a port using lv2:designation, the port's content becomes meaningful and can be used more intelligently by the host.

Plugins that alter the envelope or dynamic range of audio.

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.

An additional feature which a plugin or other resource may use or require.

Any plugin that generates sound internally, rather than processing its input.

Ports of this type will be connected to a pointer to some value, which will be read by the plugin during their run method.

Any plugin that is intended to be played as a musical instrument.

A plugin which mixes some number of inputs into some number of outputs.

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.

A parameter, i.e. a recognized property. A parameter is a designation for a control.

A parameter defines the meaning of a control (not the method of conveying its value). The standard way of exposing a plugin parameter is via an lv2:ControlPort, which can be given a parameter designation with lv2:designation. Other methods, such as setting dynamic parameters via messages, are possible but not defined here.

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.

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.

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.

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

Similar to lv2:PluginBase, an abstract port-like resource that MAY not actually be a fully specified LV2 port. For example, this is used for preset "ports" which do not specify an index.

A property of this port that allows a host to make more sensible decisions (e.g. to provide a better interface).

A single float Point (for control inputs).

Plugins that aim to duplicate the effect of some environmental effect or musical equipment.

Plugins that manipulate the position of audio in space (e.g. panning, stereo width, surround encoding, etc.).

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.

Plugins that alter the spectral properties (e.g. frequency) of audio.

A short restricted name used as a machine and human readable identifier. The first character must be one of _, a-z or A-Z and subsequent characters can be from _, a-z, A-Z and 0-9. This is a valid C identifier, and compatible in most other contexts with restricted string identifiers (e.g. file paths).

Includes things like mathematical functions and non-musical delays.

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.

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() or lv2_lib_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.

The default value that the host SHOULD set this port to when there is no other information available.

Indicates a channel or parameter designation.

This property is used to give the port's contents a well-defined meaning. For example, if a port has lv2:designation eg:gain, then the value of that port represents the eg:gain of the plugin instance.

Ports should be given designations whenever a well-defined designation exists. This allows the host to act more intelligently and/or provide a more effective user interface. For example, if the plugin has a BPM parameter, the host may automatically set that parameter to the current tempo.

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

Whether or not processing is currently enabled, that is, not bypassed.

If this value is greater than zero, the plugin processes normally. If this value is zero, the plugin is expected to bypass all signals unmodified. The plugin must provide a click-free transition between the enabled and disabled (bypassed) states.

Values less than zero are reserved for future use (such as click-free insertion/removal of latent plugins), and should be treated like zero (bypassed) by current implementations.

Signifies that a plugin provides additional data or functions (as defined by some extension) via LV2_Descriptor::instantiate().

Whether or not processing is currently free-wheeling. If true, this means that all processing is happening as quickly as possible, not in real-time. When free-wheeling there is no relationship between the passage of real wall-clock time and the passage of time in the data being processed (e.g. audio frames).

A non-negative zero-based 32-bit index.

The latency introduced, in frames.

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.

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.

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.

The minor version of an LV2 Resource. This, along with lv2:microVersion, is used to distinguish between different versions of the same resource, e.g. to load only the bundle with the most recent version of a plugin. An LV2 version has a minor and micro number with 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 major version; all versions with the same URI are compatible by definition. Replacing a resource with a newer version of that resource MUST NOT break anything. If a change violates this rule, then the URI of the resource (which serves as the major version) MUST be changed.

Plugins and extensions MUST adhere to at least 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 particular version is guaranteed to exist on a future version with same lv2:symbol and at least those rdf:types.
• 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 a specification MUST be compatible in the sense that an implementation of the new version can interoperate with an implementation of any previous version.

Anything that depends on a specific version of a plugin (e.g. a serialisation that references ports by index) MUST refer to the plugin by both URI and version. However, implementations should be tolerant and extensions should be designed such that there is no need to do this (e.g. indices should only be meaningful for a particular plugin instance at run-time).

When hosts discover several installed versions of a resource, they SHOULD warn the user and load only the most recent version.

An odd minor or micro version, or minor version zero, indicates that the resource is a development version. Hosts and tools SHOULD clearly indicate this wherever appropriate. Minor version zero is a special case for pre-release development of plugins, or experimental plugins that are not intended for stable use at all. Hosts SHOULD NOT expect such a plugin to remain compatible with any future version. If possible, hosts SHOULD hide such plugins from users unless an experimental option is enabled.

A display name for labeling in a user interface. Unlike lv2:symbol this is unrestricted and may be translated. The lv2:name MUST NOT be used as an identifier. 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.

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.

A port (input or output) on this plugin.

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.

The project this is a component of.

This property provides a way to group plugins and/or related resources. A project may have useful metadata common to all plugins (such as homepage, author, version history) which would be wasteful to list separately for each plugin.

Grouping via projects also allows users to find plugins in hosts by project, which is often how they are remembered. For this reason, a project that contains plugins SHOULD always have a doap:name. It is also a good idea for each plugin and the project itself to have an lv2:symbol property, which allows nice quasi-global identifiers for plugins, e.g. myproj.superamp which can be useful for display or fast user entry.

The prototype to inherit properties from.

This property can be used to include common properties in several descriptions. If a plugin has a prototype, then the host must load all the properties for the prototype as if they were properties of the plugin. That is, if :plug lv2:prototype :prot, then for each triple :prot p o, the triple :plug p o should be loaded.

This facility is useful for distributing text-only plugins that rely on a common binary, by referring to a prototype which is installed by the corresponding software, along with the plugin binary.

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

A scale point of a port or parameter.

A short display name for labeling in a user interface. The same rules for port names apply here, with the exception that short names should not be longer than 16 characters.

The value of this property MUST conform to the rules for lv2:Symbol, and MUST NOT have a language tag.

A symbol is a unique identifier with respect to the parent (e.g. a port's symbol is a unique identifier with respect to its plugin). The plugin author MUST change the plugin URI if a port symbol is changed or removed.

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.

The primary control channel. This should be used as the lv2:designation of ports that are used to send commands and receive responses. Typically this will be an event port that supports some protocol, e.g. MIDI or LV2 Atoms.

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

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:

1. The plugin MUST NOT use malloc(), free() or other heap memory management functions within its Audio class functions.
2. 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.
3. 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.
4. 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().

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.

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.

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

Indicates that a port is a "sidechain", which affects the output somehow but should not be considered a main input. Sidechain ports should be connectionOptional, and may be ignored by hosts.

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

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.

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.

A feature which is used to map URIs to integers. To support this feature, the host must pass an LV2_Feature to LV2_Descriptor::instantiate() with URI LV2_URID__map and data pointed to an instance of LV2_URID_Map.

A feature which is used to unmap URIs previously mapped to integers by urid:map. To support this feature, the host must pass an LV2_Feature to LV2_Descriptor::instantiate() with URI LV2_URID__unmap and data pointed to an instance of LV2_URID_Unmap.

A conversion from one unit to another.

A unit for LV2 port data

A conversion from this unit to another.

The factor to multiply the source value by in order to convert to the target unit.

A conversion from this unit to the same unit but with a different SI prefix (e.g. Hz to kHz).

A printf format string for rendering a value (eg. "%f dB").

The abbreviated symbol for the unit (e.g. dB).

The target unit this conversion converts to.

The unit used by the value of a port or parameter.

A point in time and/or the speed at which time is passing. A position is both a point and a speed, which precisely defines a time within a timeline.

The rate of passage of time in terms of one unit with respect to another.

A point in time in some unit/dimension.

The beat number within the bar, from 0 to beatsPerBar.

The global running beat number. This is not the beat within a bar like barBeat, but relative to the same origin as time:bar and monotonically increases unless the transport is repositioned.

Beat unit, the note value that counts as one beat. This is the bottom number in a time signature: 2 for half note, 4 for quarter note, and so on.

Tempo in beats per minute.

Frame rate in frames per second.

The rate of the progress of time as a fraction of normal speed. For example, a rate of 0.0 is stopped, 1.0 is rolling at normal speed, 0.5 is rolling at half speed, -1.0 is reverse, and so on.

Abstract base class for all atoms. An LV2_Atom has a 32-bit size and type followed by a body of size bytes. Atoms MUST be 64-bit aligned.

All concrete Atom types (subclasses of this class) MUST define a precise binary layout for their body.

The type field is the URI of an Atom type mapped to an integer. Implementations SHOULD gracefully pass through, or ignore, atoms with unknown types.

All atoms are POD by definition except references, which as a special case have type = 0. An Atom MUST NOT contain a Reference. It is safe to copy any non-reference Atom with a simple memcpy, even if the implementation does not understand type. Though this extension reserves the type 0 for references, the details of reference handling are currently unspecified. A future revision of this extension, or a different extension, may define how to use non-POD data and references. Implementations MUST NOT send references to another implementation unless the receiver is explicitly known to support references (e.g. by supporting a feature).

The atom with both type and size 0 is null, which is not considered a Reference.

A port which contains an atom:Atom. Ports of this type are connected to an LV2_Atom with a type specified by atom:bufferType.

Output ports with a variably sized type MUST be initialised by the host before every run() to an atom:Chunk with size set to the available space. The plugin reads this size to know how much space is available for writing. In all cases, the plugin MUST write a complete atom (including header) to outputs. However, to be robust, hosts SHOULD initialise output ports to a safe sentinel (e.g. the null Atom) before calling run().

This class is deprecated. Use atom:Object with ID 0 instead.

An atom:Object where the LV2_Atom_Object::id is a blank node ID (NOT a URI). The ID of a Blank is valid only within the context the Blank appears in. For ports this is the context of the associated run() call, i.e. all ports share the same context so outputs can contain IDs that correspond to IDs of blanks in the input.

An Int where 0 is false and any other value is true.

A chunk of memory with undefined contents. This type is used to indicate a certain amount of space is available. For example, output ports with a variably sized type are connected to a Chunk so the plugin knows the size of the buffer available for writing.

The use of a Chunk should be constrained to a local scope, since interpreting it is impossible without context. However, if serialised to RDF, a Chunk may be represented directly as an xsd:base64Binary string, e.g.:

[] eg:someChunk "vu/erQ=="^^xsd:base64Binary .

An atom with a time stamp prefix, typically an element of an atom:Sequence. Note this is not an Atom type.

A UTF-8 encoded string literal, with an optional datatype or language.

This type is compatible with rdfs:Literal and is capable of expressing a string in any language or a value of any type. A Literal has a datatype and lang followed by string data in UTF-8 encoding. The length of the string data in bytes is size - sizeof(LV2_Atom_Literal), including the terminating NULL character. The lang field SHOULD be a URI of the form <http://lexvo.org/id/iso639-3/LANG> or <http://lexvo.org/id/iso639-1/LANG> where LANG is a 3-character ISO 693-3 language code, or a 2-character ISO 693-1 language code, respectively.

A Literal may have a datatype OR a lang, but never both.

For example, a Literal can be "Hello" in English:

void set_to_hello_in_english(LV2_Atom_Literal* lit) {
     lit->atom.type     = map(expand("atom:Literal"));
     lit->atom.size     = 14;
     lit->body.datatype = 0;
     lit->body.lang     = map("http://lexvo.org/id/iso639-1/en");
     memcpy(LV2_ATOM_CONTENTS(LV2_Atom_Literal, lit),
            "Hello",
            sizeof("Hello"));  // Assumes enough space
}

or a Turtle string:

void set_to_turtle_string(LV2_Atom_Literal* lit, const char* ttl) {
     lit->atom.type     = map(expand("atom:Literal"));
     lit->atom.size     = 64;
     lit->body.datatype = map("http://www.w3.org/2008/turtle#turtle");
     lit->body.lang     = 0;
     memcpy(LV2_ATOM_CONTENTS(LV2_Atom_Literal, lit),
            ttl,
            strlen(ttl) + 1);  // Assumes enough space
}

An Object is an atom with a set of properties. This corresponds to an RDF Resource, and can be thought of as a dictionary with URID keys.

An LV2_Atom_Object body has a uint32_t id and type, followed by a series of atom:Property bodies (LV2_Atom_Property_Body). The LV2_Atom_Object_Body::otype field is equivalent to a property with key rdf:type, but is included in the structure to allow for fast dispatching.

Code SHOULD check for objects using lv2_atom_forge_is_object() or lv2_atom_forge_is_blank() if a forge is available, rather than checking the atom type directly. This will correctly handle the deprecated atom:Resource and atom:Blank types.

When serialised to RDF, an Object is represented as a resource, e.g.:

eg:someObject
    eg:firstPropertyKey "first property value" ;
    eg:secondPropertyKey "first loser" ;
    eg:andSoOn "and so on" .

A local file path.

A Path is a URI reference with only a path component: no scheme, authority, query, or fragment. In particular, paths to files in the same bundle may be cleanly written in Turtle files as a relative URI. However, implementations may assume any binary Path (e.g. in an event payload) is a valid file path which can passed to system functions like fopen() directly, without any character encoding or escape expansion required.

Any implemenation that creates a Path atom to transmit to another is responsible for ensuring it is valid. A Path SHOULD always be absolute, unless there is some mechanism in place that defines a base path. Since this is not the case for plugin instances, effectively any Path sent to or received from a plugin instance MUST be absolute.

A property of an atom:Object. An LV2_Atom_Property has a URID key and context, and an Atom value. This corresponds to an RDF Property, where the key is the predicate and the value is the object.

The context field can be used to specify a different context for each property, where this is useful. Otherwise, it may be 0.

Properties generally only exist as part of an atom:Object. Accordingly, they will typically be represented directly as properties in RDF (see atom:Object). If this is not possible, they may be expressed as partial reified statements, e.g.:

eg:someProperty
    rdf:predicate eg:theKey ;
    rdf:object eg:theValue .

This class is deprecated. Use atom:Object instead.

An atom:Object where the id field is a URID, i.e. an Object with a URI.

A sequence of atom:Event, i.e. a series of time-stamped Atoms.

LV2_Atom_Sequence_Body.unit describes the time unit for the contained atoms. If the unit is known from context (e.g. run() stamps are always audio frames), this field may be zero. Otherwise, it SHOULD be either units:frame or units:beat, in which case ev.time.frames or ev.time.beats is valid, respectively.

If serialised to RDF, a Sequence has a similar form to atom:Vector, but for brevity the elements may be assumed to be atom:Event, e.g.:

eg:someSequence
    a atom:Sequence ;
    rdf:value (
        [
            atom:frameTime 1 ;
            rdf:value "901A01"^^midi:MidiEvent
        ] [
            atom:frameTime 3 ;
            rdf:value "902B02"^^midi:MidiEvent
        ]
    ) .

An atom:Vector of atom:Float which represents an audio waveform. The format is the same as the buffer format for lv2:AudioPort (except the size may be arbitrary). An atom:Sound inherently depends on the sample rate, which is assumed to be known from context. Because of this, directly serialising an atom:Sound is probably a bad idea, use a standard format like WAV instead.

A UTF-8 encoded string.

The body of an LV2_Atom_String is a C string in UTF-8 encoding, i.e. an array of bytes (uint8_t) terminated with a NULL byte ('\0').

This type is for free-form strings, but SHOULD NOT be used for typed data or text in any language. Use atom:Literal unless translating the string does not make sense and the string has no meaningful datatype.

A series of Atoms with varying type and size.

The body of a Tuple is simply a series of complete atoms, each aligned to 64 bits.

If serialised to RDF, a Tuple SHOULD have the form:

eg:someVector
     a atom:Tuple ;
     rdf:value (
         "1"^^xsd:int
         "3.5"^^xsd:float
         "etc"
     ) .

A URI string. This is useful when a URI is needed but mapping is inappropriate, for example with temporary or relative URIs. Since the ability to distinguish URIs from plain strings is often necessary, URIs MUST NOT be transmitted as atom:String.

This is not strictly a URI, since UTF-8 is allowed. Escaping and related issues are the host's responsibility.

An unsigned 32-bit integer mapped from a URI (e.g. with LV2_URID_Map).

A homogeneous series of atom bodies with equivalent type and size.

An LV2_Atom_Vector is a 32-bit child_size and child_type followed by size / child_size atom bodies.

For example, an atom:Vector containing 42 elements of type atom:Float:

struct VectorOf42Floats {
    uint32_t size;        // sizeof(LV2_Atom_Vector_Body) + (42 * sizeof(float);
    uint32_t type;        // map(expand("atom:Vector"))
    uint32_t child_size;  // sizeof(float)
    uint32_t child_type;  // map(expand("atom:Float"))
    float    elems[42];
};

Note that it is possible to construct a valid Atom for each element of the vector, even by an implementation which does not understand child_type.

If serialised to RDF, a Vector SHOULD have the form:

eg:someVector
     a atom:Vector ;
     atom:childType atom:Int ;
     rdf:value (
         "1"^^xsd:int
         "2"^^xsd:int
         "3"^^xsd:int
         "4"^^xsd:int
     ) .

Time stamp in beats. Typically used for events.

Indicates that an AtomPort may be connected to a certain Atom type. A port MAY support several buffer types. The host MUST NOT connect a port to an Atom with a type not explicitly listed with this property. The value of this property MUST be a sub-class of atom:Atom. For example, an input port that is connected directly to an LV2_Atom_Double value is described like so:

<plugin>
    lv2:port [
        a lv2:InputPort , atom:AtomPort ;
        atom:bufferType atom:Double ;
    ] .

This property only describes the types a port may be directly connected to. It says nothing about the expected contents of containers. For that, use atom:supports.

The identifier for a C type describing the binary representation of an Atom of this type.

The type of a container's children.

Time stamp in audio frames. Typically used for events.

Indicates that a particular Atom type is supported.

This property is defined loosely, it may be used to indicate that anything supports an Atom type, wherever that may be useful. It applies recursively where collections are involved.

In particular, this property can be used to describe which event types are expected by a port. For example, a port that receives MIDI events is described like so:

<plugin>
    lv2:port [
        a lv2:InputPort , atom:AtomPort ;
        atom:bufferType atom:Sequence ;
        atom:supports midi:MidiEvent ;
    ] .

Transfer of the complete atom in a port buffer. Useful as the format for a LV2UI_Write_Function.

This protocol applies to atom ports. The host must transfer the complete atom contained in the port, including header.

Transfer of individual events in a port buffer. Useful as the format for a LV2UI_Write_Function.

This protocol applies to ports which contain events, usually in an atom:Sequence. The host must transfer each individual event to the recipient. The format of the received data is an LV2_Atom, there is no timestamp header.

A series of contiguous bytes (usually one) in a message.

A hexadecimal byte, which is a xsd:hexBinary value <= FF

A single raw MIDI message (i.e. a sequence of bytes).

This is equivalent to a standard MIDI messages, except with the following restrictions to simplify handling:

• Running status is not allowed, every message must have its own status byte.
• Note On messages with velocity 0 are not allowed. These messages are equivalent to Note Off in standard MIDI streams, but here only proper Note Off messages are allowed.
• "Realtime messages" (status bytes 0xF8 to 0xFF) are allowed, but may not occur inside other messages like they can in standard MIDI streams.
• All messages are complete valid MIDI messages. This means, for example, that only the first byte in each event (the status byte) may have the eighth bit set, that Note On and Note Off events are always 3 bytes long, etc. Where messages are communicated, the writer is responsible for writing valid messages, and the reader may assume that all events are valid.

If a midi:MidiEvent is serialised to a string, the format should be xsd:hexBinary, e.g. (in Turtle notation):

[] eg:someEvent "901A01"^^midi:MidiEvent .

The value of a pitch bender (-8192 to 8192).

The MIDI event to bind a parameter to. This describes which MIDI events should be used to control a port, parameter, or other object. The binding should be a midi:MidiEvent but the property that represents the control value may be omitted. For example, to bind to the value of controller 17:

port midi:binding [
    a midi:Controller ;
    midi:controllerNumber 17
] .

The 0-based index of a byte which is part of this chunk.

The channel number of a MIDI message.

A chunk of a MIDI message.

The numeric ID of a controller (0 to 127).

The value of a controller (0 to 127).

The numeric ID of a note (0 to 127).

Key pressure (0 to 127).

The numeric ID of a program (0 to 127).

The property this chunk represents.

The numeric ID of a song (0 to 127).

Song position in MIDI beats (16th notes) (-8192 to 8192).

The exact status byte for a message of this type.

The status byte for a message of this type on channel 1, i.e. a status byte with the lower nibble set to zero.

The velocity of a note message (0 to 127).

Indicates how important a port is to controlling the plugin. If a host can only display some ports of a plugin, it should prefer ports with a higher display priority. Priorities do not need to be unique, and are only meaningful when compared to each other.

This value indicates into how many evenly-divided points the (control) port range should be divided for step-wise control. This may be used for changing the value with step-based controllers like arrow keys, mouse wheel, rotary encoders, etc.

Note that when used with a pprops:logarithmic port, the steps are logarithmic too, and port value can be calculated as:

value = lower * pow(upper / lower, step / (steps - 1))

and the step from value is:

step = (steps - 1) * log(value / lower) / log(upper / lower)

where:

• value is the port value
• step is the step number (0..steps)
• steps is the number of steps (= value of :rangeSteps property)
• lower and upper are the bounds

Input ports only. Indicates that any changes to the port value may produce slight artifacts to produced audio signals (zipper noise and other results of signal discontinuities). Connecting ports of this type to continuous signals is not recommended, and when presenting a list of automation targets, those ports may be marked as artifact-producing.

Indicates that the port carries a "smooth" modulation signal. Control input ports of this type are well-suited for being connected to sources of smooth signals (knobs with smoothing, modulation rate oscillators, output ports with continuousCV type, etc.). Typically, the plugin with ports which have this property will implement appropriate smoothing to avoid audio artifacts. For output ports, this property suggests the value of the port is likely to change frequently, and describes a smooth signal (e.g. successive values may be considered points along a curve).

Indicates that the port carries a "discrete" modulation signal. Input ports of this type are well-suited for being connected to sources of discrete signals (switches, buttons, classifiers, event detectors, etc.). May be combined with pprops:trigger property. For output ports, this property suggests the value of the port describe discrete values that should be interpreted as steps (and not points along a curve).

Input ports only. Indicates that any changes to the port value may trigger expensive background calculation (e.g. regenerate some lookup tables in a background thread). Any value changes may have not have immediate effect, or may cause silence or diminished-quality version of the output until background processing is finished. Ports having this property are typically not well suited for connection to outputs of other plugins, and should not be offered as connection targets or for automation by default.

For hosts that support pprops:supportsStrictBounds, this indicates that the value of the port should never exceed the port's minimum and maximum control points. For input ports, it moves the responsibility for limiting the range of values to host, if it supports pprops:supportsStrictBounds. For output ports, it indicates that values within specified range are to be expected, and breaking that should be considered by the host as error in plugin implementation.

Indicates that port value behaviour within specified range (bounds) is a value using logarithmic scale. The lower and upper bounds must be specified, and must be of the same sign.

Indicates that the port is not primarily intended to be fed with modulation signals from external sources (other plugins, etc.). It is merely a UI hint and hosts may allow the user to override it.

Indicates that the port is not primarily intended to be represented by a separate control in the user interface window (or any similar mechanism used for direct, immediate control of control ports). It is merely a UI hint and hosts may allow the user to override it.

Indicates use of host support for pprops:hasStrictBounds port property. A plugin that specifies it as optional feature can omit value clamping for hasStrictBounds ports, if the feature is supported by the host. When specified as required feature, it indicates that the plugin does not do any clamping for input ports that have a pprops:hasStrictBounds property.

Indicates that the data item corresponds to a momentary event that has been detected (control output ports) or is to be triggered (control input ports). For input ports, the port needs to be reset to lv2:default value after run() function of the plugin has returned. If the control port is assigned a GUI widget by the host, the widget should be of auto-off (momentary, one-shot) type - for example, a push button if the port is also declared as lv2:toggled, or a series of push button or auto-clear input box with a "Send" button if the port is also lv2:integer.

The maximum block length the host will ever request the plugin to process at once, that is, the maximum sample_count parameter that will ever be passed to LV2_Descriptor::run().

The minimum block length the host will ever request the plugin to process at once, that is, the minimum sample_count parameter that will ever be passed to LV2_Descriptor::run().

The typical block length the host will request the plugin to process at once, that is, the typical sample_count parameter that will be passed to LV2_Descriptor::run(). This will usually be equivalent, or close to, the maximum block length, but there are no strong guarantees about this value whatsoever. Plugins may use this length for optimization purposes, but MUST NOT assume the host will always process blocks of this length. In particular, the host MAY process longer blocks.

The maximum size of a sequence, in bytes. This should be provided as an option by hosts that support event ports (including but not limited to MIDI), so plugins have the ability to allocate auxiliary buffers large enough to copy the input.

A feature that indicates the host will provide both the bufsz:minBlockLength and bufsz:maxBlockLength options to the plugin. Plugins that copy data from audio inputs can require this feature to ensure they know how much space is required for auxiliary buffers. Note the minimum may be zero, this feature is mainly useful to ensure a maximum is available.

All hosts SHOULD support this feature, since it is simple to support and necessary for any plugins that may need to copy the input.

A feature that indicates the plugin prefers coarse, regular block lengths. For example, plugins that do not implement sample-accurate control use this feature to indicate that the host should not split the run cycle because controls have changed.

Note that this feature is merely a hint, and does not guarantee a fixed block length. The run cycle may be split for other reasons, and the blocksize itself may change anytime.

A feature that indicates the host will always call LV2_Descriptor::run() with the same value for sample_count. This length MUST be provided as the value of both the bufsz:minBlockLength and bufsz:maxBlockLength options.

Note that requiring this feature may severely limit the number of hosts capable of running the plugin.

A feature that indicates the host will always call LV2_Descriptor::run() with a power of two sample_count. Note that this feature does not guarantee the value is the same each call, to guarantee a fixed power of two block length plugins must require both this feature and bufsz:fixedBlockLength.

Note that requiring this feature may severely limit the number of hosts capable of running the plugin.

Indicates that a port requires at least as much buffer space as the port with the given symbol on the same plugin instance. This may be used for any ports, but is generally most useful to indicate an output port must be at least as large as some input port (because it will copy from it). If a port is asLargeAs several ports, it is asLargeAs the largest such port (not the sum of those ports' sizes).

The host guarantees that whenever an ObjectPort's run method is called, any output O that is obj:asLargeAs an input I is connected to a buffer large enough to copy I, or NULL if the port is lv2:connectionOptional.

Indicates that a port requires a buffer at least this large, in bytes. Any host that supports the resize-port feature MUST connect any port with a minimumSize specified to a buffer at least as large as the value given for this property. Any host, especially those that do NOT support dynamic port resizing, SHOULD do so or reduced functionality may result.

A feature to resize output port buffers in LV2_Plugin_Descriptor::run().

To support this feature, the host must pass an LV2_Feature to the plugin's instantiate method with URI LV2_RESIZE_PORT__resize and a pointer to a LV2_Resize_Port_Resize structure. This structure provides a resize_port function which plugins may use to resize output port buffers as necessary.

Ambisonic channel configurations. These groups are divided into channels which together represent a position in an abstract n-dimensional space. The position of sound in one of these groups does not depend on a particular speaker configuration; a decoder can be used to convert an ambisonic stream for any speaker configuration.

Discrete channel configurations. These groups are divided into channels where each represents a particular speaker location. The position of sound in one of these groups depends on a particular speaker configuration.

An element of a group, which has a designation and an optional index.