A filter that changes the phase relationship between frequency components.

A plugin that primarily changes the volume of its input.

A plugin that analyses its input and emits some useful information.

A port connected to an array of float audio samples.

Ports of this type are connected to a buffer of float audio samples, which the host guarantees have sample_count elements in any call to LV2_Descriptor::run().

Audio samples are normalized between -1.0 and 1.0, though there is no requirement for samples to be strictly within this range.

A filter that attenuates frequencies outside of some band.

A port connected to an array of float control values.

Ports of this type have the same buffer format as an AudioPort, except the buffer represents audio-rate control data rather than audio. Like a ControlPort, a CV port SHOULD have properties describing its value, in particular minimum, maximum, and default.

Hosts may present CV ports to users as controls in the same way as control ports. Conceptually, aside from the buffer format, a CV port is the same as a control port, so hosts can use all the same properties and expectations.

In particular, this port type does not imply any range, unit, or meaning for its values. However, if there is no inherent unit to the values, for example if the port is used to modulate some other value, then plugins SHOULD use a normalized range, either from -1.0 to 1.0, or from 0.0 to 1.0.

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

An individual channel, such as left or right.

A specific channel, for example the left channel of a stereo stream. A channel may be audio, or another type such as a MIDI control stream.

An effect that mixes significantly delayed copies of its input.

A filter that adds a delayed version of its input to itself.

A plugin that reduces the dynamic range of its input.

A plugin that emits constant values.

A port connected to a single `float`.

A plugin that converts its input into a different form.

An effect that intentionally delays its input as an effect.

A designation which defines the meaning of some data.

A designation is metadata that describes the meaning or role of something. By assigning a designation to a port using designation, the port's content becomes meaningful and can be used more intelligently by the host.

A plugin that adds distortion to its input.

A plugin that alters the envelope or dynamic range of its input.

A plugin that adjusts the balance between frequency components.

A plugin that applies an envelope to its input.

A plugin that expands the dynamic range of its input.

Additional data defined by an extension.

This is additional data that a plugin may return from LV2_Descriptor::extension_data(). This is generally used to add APIs to extend that defined by LV2_Descriptor.

An additional feature which may be used or required.

An effect that manipulates the frequency spectrum of its input.

An effect that mixes slightly delayed copies of its input.

A plugin whose output is a mathmatical function of its input.

A plugin that attenuates signals below some threshold.

A plugin that generates new sound internally.

A filter that attenuates frequencies below some cutoff.

A port connected to constant data which is read during `run()`.

A plugin intended to be played as a musical instrument.

A plugin that limits its input to some maximum level.

A filter that attenuates frequencies above some cutoff.

A plugin that primarily processes MIDI messages.

A string in Markdown syntax.

This datatype is typically used for documentation in Markdown syntax.

Generally, documentation with this datatype should stay as close to readable plain text as possible, but may use core Markdown syntax for nicer presentation. Documentation can assume that basic extensions like codehilite and tables are available.

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

An effect that modulats its input as an effect.

A plugin that adjusts the balance between a fixed set of frequency components.

A plugin that generates output with an oscillator.

A port connected to data which is written during `run()`.

A plugin that adjusts the balance between configurable frequency components.

A property that is a plugin parameter.

A parameter is a designation for a control.

A parameter defines the meaning of a control, not the method of conveying its value. For example, a parameter could be controlled via a ControlPort, messages, or both.

A ControlPort can be associated with a parameter using designation.

An effect that periodically sweeps a filter over its input.

A plugin that shifts the pitch of its input.

An LV2 plugin.

To be discovered by hosts, plugins MUST explicitly have an rdf:type of Plugin in their bundle's manifest, for example:

<http://example.org/my-plugin> a lv2:Plugin .

Plugins should have a doap:name property that is at most a few words in length using title capitalization, for example Tape Delay Unit.

Base class for a plugin-like resource.

An abstract plugin-like resource that may not actually be an LV2 plugin, for example that may not have a binary. This is useful for describing things that share common structure with a plugin, but are not themselves an actul plugin, such as presets.

An interesting point in a value range.

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

An LV2 plugin port.

All LV2 port descriptions MUST have a rdf:type that is one of Port, InputPort or OutputPort. Additionally, there MUST be at least one other rdf:type which more precisely describes type of the port, for example AudioPort.

Hosts that do not support a specific port class MUST NOT instantiate the plugin, unless that port has the connectionOptional property set.

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 (for example in presets or save files) MUST use the symbol. Only the symbol is guaranteed to refer to the same port on all plugins with a given URI, that is the index for a port may differ between plugin binaries.

Base class for a port-like resource.

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

A particular property that a port has.

An effect that adds reverberation to its input.

A single `float` Point for control inputs.

A plugin that aims to emulate some environmental effect or musical equipment.

A plugin that manipulates the position of audio in space.

An LV2 specifiation.

An LV2 specification typically contains a vocabulary description, C headers to define an API, and any other resources that may be useful. Specifications, like plugins, are distributed and installed as bundles so that hosts may discover them.

A plugin that alters the spectral properties of audio.

A short restricted name used as a strong identifier.

The first character of a symbol must be one of _, a-z or A-Z, and subsequent characters may additionally be 0-9. This is, among other things, a valid C identifier, and generally compatible in most contexts which have restrictions on string identifiers, such as file paths.

A utility plugin that is not a typical audio effect or generator.

An effect that alters the shape of input waveforms.

The plugin this resource is related to.

This is primarily intended for discovery purposes: bundles that describe resources that work with particular plugins (like presets or user interfaces) SHOULD specify this in their manifest.ttl so the host can associate them with the correct plugin. For example:

<thing>
    a             ext:Thing ;
    lv2:appliesTo <plugin> ;
    rdfs:seeAlso  <thing.ttl> .

Using this pattern is preferable for large amounts of data, since the host may choose whether/when to load the data.

The binary of this resource.

The value of this property must be the URI of a shared library object, typically in the same bundle as the data file which contains this property. The actual type of the library is platform specific.

This is a required property of a Plugin which MUST be included in the bundle's manifest.ttl file. The binary of a Plugin is the shared object containing the lv2_descriptor() or lv2_lib_descriptor() function. This probably may also be used similarly by extensions to relate other resources to their implementations (it is not implied that a binary on an arbitrary resource is an LV2 plugin library).

The default value for this control.

The host SHOULD set the port to this value initially, and in any situation where the port value should be cleared or reset.

The designation that defines the meaning of this input or output.

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

Ports should be given designations whenever possible, particularly if a suitable designation is already defined. This allows the host to act more intelligently and 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.

Extended documentation.

Relates a Resource to extended documentation.

LV2 specifications are documented using this property with an Markdown datatype.

If the value has no explicit datatype, it is assumed to be a valid XHTML Basic 1.1 fragment suitable for use as the content of the <body> element of a page.

XHTML Basic is a W3C Recommendation which defines a simplified subset of XHTML intended to be reasonable to implement with limited resources, for exampe on embedded devices. See XHTML Basic, Section 3 for a list of valid tags.

Whether processing is currently enabled (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.

Extension data provided by a plugin or other binary.

If a plugin has a value for this property, it must be a URI that defines the extension data. The plugin should return the appropriate data when LV2_Descriptor::extension_data() is called with that URI as a parameter.

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

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

The latency introduced, in frames.

The maximum value for this control.

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 version of this resource.

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

The minimum value for this control.

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 this resource.

This, along with microVersion, is used to distinguish between different versions of the same resource, for example 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, for example the addition of a port to a plugin.

• The micro version is incremented for changes which do not affect compatibility at all, for example bug fixes or documentation updates.

Note that 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 (not connectionOptional) ports with respect to symbol and rdf:type. In other words, every port on a particular version is guaranteed to exist on a future version with same symbol and at least those rdf:types.

• New ports MAY be added without changing the plugin URI if and only if they are 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 (including referencing ports by index) MUST refer to the plugin by both URI and version. However, implementations should be tolerant where possible.

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. Where feasible, hosts SHOULD NOT expose such plugins to users by default, but may provide an option to display them.

A display name for labeling in a user interface.

Unlike symbol, this is unrestricted, may be translated, and is not relevant for compatibility. The name is not necessarily unique and MUST NOT be used as an identifier.

An optional feature that is supported if available.

To support this feature, the host 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.

A property of this port hosts may find useful.

States that a port has a particular PortProperty. This may be ignored without catastrophic effects, though it may be useful, for example to provide a sensible user interface for the port.

The project this is a part 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 symbol property, which allows nice quasi-global identifiers for plugins, for example 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, serving as a sort of template mechanism. 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 prototype :prot, then for each triple :prot p o, the triple :plug p o should be loaded.

This facility is useful for distributing data-only plugins that rely on a common binary, for example those where the internal state is loaded from some other file. Such plugins can refer to a prototype in a template LV2 bundle which is installed by the corresponding software.

A required feature that must be available to run.

To support this feature, the host MUST pass its URI and any additional data to the plugin in LV2_Descriptor::instantiate().

The host MUST check this property before attempting to instantiate a plugin, and not attempt to instantiate plugins which require features it does not support. The plugin MUST fail to instantiate if a required feature is not supported by the host. Note that these rules are intentionally redundant for resilience: neither host nor plugin should assume that the other does not violate them.

A scale point of a port or parameter.

A short display name for labeling in a user interface.

This is the same as name, with the additional requirement that the value is shorter than 16 characters.

The symbol that identifies this resource in the context of its parent.

The value of this property MUST be a valid Symbol, and MUST NOT have a language tag.

A symbol is a unique identifier with respect to the parent, for example a port's symbol is a unique identifiers with respect to its plugin. The plugin author MUST change the plugin URI if any port symbol is changed or removed.

The property that this port may be connected to NULL.

This property means that the port does not have to be connected to valid data by the host. To leave a port unconnected, the host MUST explicitly connect the port to NULL.

The primary control channel.

This should be used as the designation of ports that are used to send commands and receive responses. Typically this will be an event port that supports some protocol, for example MIDI or LV2 Atoms.

Control port scale points represent all useful values.

Indicates that all the rasonable values for a port are defined by scalePoint properties. For such ports, a user interface should provide a selector that allows the user to choose any of the scale point values by name. It is recommended to show the value as well if possible.

Note that this is only a hint, and that the plugin MUST operate reasonably even if such a port has a value that does not correspond to a scale point.

Plugin is capable of running in a hard real-time environment.

This feature indicates that the plugin is capable of running in a hard real-time environment. This should be the case for most audio processors, so most plugins are expected to have this feature.

To support this feature, plugins MUST adhere to the following in all of their audio class functions (LV2_Descriptor::run() and LV2_Descriptor::connect_port()):

• There is no use of malloc(), free() or any other heap memory management functions.

• There is no use of any library functions which do not adhere to these rules. The plugin may assume that the standard C math library functions are safe.

• There is no access to files, devices, pipes, sockets, system calls, or any other mechanism that might result in the process or thread blocking.

• The maximum amount of time for a run() call is bounded by some expression of the form A + B * sample_count, where A and B are platform specific constants. Note that this bound does not depend on input signals or plugin state.

Plugin requires separate locations for input and output.

This feature indicates that the plugin may not 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 whenever possible since it prevents hosts from running the plugin on data in-place.

Control port values are treated as integers.

Indicates that all the reasonable values for a port are integers. For such ports, a user interface should provide a stepped control that only allows choosing integer values.

Note that this is only a hint, and that the plugin MUST operate reasonably even if such a port has a non-integer value.

Plugin has a real-time dependency.

This feature is for plugins that have time-sensitive internals, for example communicating in real time over a socket. It indicates to the host that its input and output must not be cached or subject to significant latency, and that calls to LV2_Descriptor::run() should be made at a rate that roughly corresponds to wall clock time (according to the sample_count parameter).

Note that this feature is not related to hard real-time execution requirements (see hardRTCapable).

Signal for port should not be considered a main input or output.

Indicates that a port is a sidechain, which affects the output somehow but should not be considered a part of the main signal chain. Sidechain ports SHOULD be connectionOptional, and may be ignored by hosts.

Control port value is the plugin latency in frames.

This property 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. In fuzzy cases the value should be the most reasonable one based on user expectation of input/output alignment. For example, musical delay plugins should not report their delay as latency, since it is an intentional effect that the host should not compensate for.

This property is deprecated, use a designation of latency instead, following the same rules as above:

<http://example.org/plugin>
    lv2:port [
        a lv2:OutputPort , lv2:ControlPort ;
        lv2:designation lv2:latency ;
        lv2:symbol "latency" ;
    ]

Control port bounds are interpreted as multiples of the sample rate.

Indicates that any specified bounds should be interpreted as multiples of the sample rate. For example, a frequency range from 0 Hz to the Nyquist frequency (half the sample rate) can be specified by using this property with minimum 0.0 and maximum 0.5. Hosts that support bounds at all MUST support this property.

Control port value is considered a boolean toggle.

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 to map URI strings to integer URIDs.

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 to unmap URIDs back to strings.

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 a control value.

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 another with the same base but a different prefix.

A printf format string for rendering a value (e.g., "%f dB").

The abbreviated symbol for this unit (e.g., "dB").

The target unit this conversion converts to.

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

Musical bars or measures.

Musical beats.

Beats Per Minute (BPM), the standard unit for musical tempo.

Cents (hundredths of semitones).

Centimetres (hundredths of metres).

A scale coefficient where 1 is unity, or 100 percent.

Decibels, a logarithmic relative unit where 0 is unity.

An angle where 360 degrees is one full rotation.

Audio frames or samples.

Hertz, or inverse seconds, the SI derived unit for frequency.

An inch, defined as exactly 0.0254 metres.

Kilohertz (thousands of Hertz).

Kilometres (thousands of metres).

Metres, the SI base unit for length.

Megahertz (millions of Hertz).

A MIDI note number.

A mile, defined as exactly 1609.344 metres.

Minutes (60s of seconds and 60ths of an hour).

Millimetres (thousandths of metres).

Milliseconds (thousandths of seconds).

Octaves, relative musical pitch where +1 octave doubles the frequency.

Percentage, a ratio as a fraction of 100.

Seconds, the SI base unit for time.

A semitone in the 12-tone equal temperament scale.

A point in time and/or the speed at which time is passing.

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.

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

A point in time in some unit/dimension.

A musical bar or measure.

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 bar and monotonically increases unless the transport is repositioned.

The note value that counts as one beat.

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.

The number of beats in one bar.

Tempo in beats per minute.

A time stamp in audio frames.

Frame rate in frames per second.

A musical position.

The rate of the progress of time as a fraction of normal speed.

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 special case of a null atom with both type and size 0 is not considered a reference.

A port which contains an Atom.

Ports of this type are connected to an LV2_Atom with a type specified by bufferType.

Output ports with a variably sized type MUST be initialised by the host before every run() to an 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().

An anonymous collection of properties without a URI.

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

An 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, for example:

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

A native `double`.

An atom with a time stamp prefix in a sequence.

An Event is typically an element of an Sequence. Note that this is not an Atom type since it begins with a timestamp, not an atom header.

A native `float`.

A native `int32_t`.

A UTF-8 string literal with 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("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("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
}

A native `int64_t`.

Base class for numeric types.

A collection of properties.

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 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 Resource and Blank types.

When serialised to RDF, an Object is represented as a resource, for example:

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 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 Object. Accordingly, they will typically be represented directly as properties in RDF (see Object). If this is not possible, they may be expressed as partial reified statements, for example:

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

A named collection of properties with a URI.

This class is deprecated. Use Object directly instead.

An Object where the id field is a URID, that is, an Object with a URI.

A sequence of events.

A flat sequence of Event, that is, 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 Vector, but for brevity the elements may be assumed to be Event, for example:

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

A Vector of Float which represents an audio waveform.

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

A UTF-8 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 Literal unless translating the string does not make sense and the string has no meaningful datatype.

A sequence 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 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 ID for a URI.

A URID is typically generated with the LV2_URID_Map provided by the host .

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

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 Vector containing 42 elements of type Float:

struct VectorOf42Floats {
    uint32_t size;        // sizeof(LV2_Atom_Vector_Body) + (42 * sizeof(float);
    uint32_t type;        // map(expand("Vector"))
    uint32_t child_size;  // sizeof(float)
    uint32_t child_type;  // map(expand("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
     ) .

A time stamp in beats.

An atom type that a port may be connected to.

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

The C type that describes the binary representation of an Atom type.

The type of children in a container.

A time stamp in audio frames.

A supported atom type.

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 ;
    ] .

A port protocol for transferring atoms.

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.

A port protocol for transferring events.

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

MIDI active sense message.

MIDI aftertouch message.

MIDI bender message.

MIDI channel pressure message.

A sequence of contiguous bytes in a MIDI message.

MIDI clock message.

MIDI continue message.

MIDI controller change message.

A hexadecimal byte, which has a value <= FF.

A single raw MIDI message.

A single raw MIDI message (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 MidiEvent is serialised to a string, the format should be xsd:hexBinary, for example:

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

MIDI note off message.

MIDI note on message.

MIDI program change message.

MIDI quarter frame message.

MIDI reset message.

MIDI song position pointer message.

MIDI song select message.

MIDI start message.

MIDI stop message.

MIDI system common message.

MIDI system exclusive message.

MIDI system message.

MIDI system realtime message.

MIDI tune request message.

MIDI voice message.

MIDI pitch bender message (-8192 to 8192).

The MIDI event to bind a parameter to.

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.

This is a status byte with the lower nibble set to zero.

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

A priority ranking this port in importance to its plugin.

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.

The number of even steps the range should be divided into.

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, and so on.

Note that when used with a 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 port causes audible artifacts when changed.

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.

Port carries a smooth modulation signal.

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 (so successive values may be considered points along a curve).

Port carries a discrete modulation signal.

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 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 port is expensive to change.

Input ports only. Indicates that any changes to the port value may trigger expensive background calculation (for example, regeneration of 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.

Port has strict bounds which are not internally clamped.

For hosts that support 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 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.

Port value is logarithmic.

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.

Port that is not intended to be fed with a modulation signal.

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.

Port that should not be displayed on a GUI.

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.

A feature indicating plugin support for strict port bounds.

Indicates use of host support for 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 hasStrictBounds property.

Port is a momentary trigger.

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.

Block length has an upper bound.

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

Block length has a lower bound.

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

Typical block length that will most often be processed.

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.

Block length has lower and upper bounds.

A feature that indicates the host will provide both the minBlockLength and 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.

Plugin prefers coarse block length without buffer splitting.

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.

Block length never changes.

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 minBlockLength and maxBlockLength options.

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

Block length is a power of 2.

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

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

Port that this port must have at least as much buffer space as.

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 asLargeAs an input I is connected to a buffer large enough to copy I, or NULL if the port is lv2:connectionOptional.

Minimum buffer size required by a port, in bytes.

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 for resizing output port buffers.

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.