RDF

The LV2 specifications are defined by^[12] and make use^[13] of RDF metadata in Turtle format. Technologies involved include Dublin Core, FOAF, DOAP, SPDX, XSD, RDFS and OWL.^[14] The relational capabilities and properties this syntax supports are powerful but can be hard to understand at first.^[15]

Beyond the core specification there are 21 official extensions providing support for host options, plugin presets, time and units, port buffers, properties, groups and parameter labels, for sending MIDI, patches, UI events and more.^[16] There are various third-party extensions for supporting expressive events, OSC, and MOD Devices specific hardware and software, with three in the KXStudio LV2 Namespace.

The plugin uses this information to provide a list of capabilities to the host, so the host can accommodate those.^[17] Similarly, the host can provide a list of LV2 extension capabilities that it supports on initialization of the plugin.

In the example below, first the shortcut prefixes for the lv2, doap and spdx ontology are declared. Next, every plugin must have its own URI or URN. Then the 4 following declare that this resource is an lv2:Plugin, a binary object file library with the filename silence.so should be present, the plugin is known under the name Silence, and is licensed under the GNU GPL. These 4 properties are mandatory for an LV2 plugin; if a plugin does not have all of them a host might not load it.

@prefix lv2:  <http://lv2plug.in/ns/lv2core#>.
@prefix doap: <http://usefulinc.com/ns/doap#>.
@prefix spdx: <http://spdx.org/rdf/terms#>.

<http://example.org/lv2/wikipediaexample/silence>
  a lv2:Plugin;
  lv2:binary <silence.so>;
  doap:name "Silence";
  doap:license spdx:GPL-3.0-or-later;
  rdfs:comment "This is an example plugin that includes an example plugin description."

  lv2:port [
    a lv2:AudioPort, lv2:OutputPort;
    lv2:index 0;
    lv2:symbol "output";
    lv2:name "Output";
  ].

Atoms

"Atom" data structures are used for messaging between plugin ports^[18][19] for the transfer of MIDI,^[20] OSC, Patch,^[21] UI and other events between plugin instances. These can also be serialised on Turtle.^[22][23]

UI

Host interface to plugin properties

Aside from separating metadata from binaries, LV2 mandates a general separation between DSP and user interface processing. Benefits include that UI processing cannot hold back DSP processing, and UI and DSP can be separated across a network. Messaging using Atoms is the preferred method for passing updates between the running DSP and UI binaries.

Hosts can also provide an interface for displaying and configuring the properties of plugin instances. There are extensions and properties to help display the correct control types.

Threading

One capability that a host can provide to a plugin is a "worker thread". In programming terms, this means that the plugin can offload some work to be done in another thread that the host provides. This is generally useful because a plugin is usually run in the real-time audio thread of an application, and hence cannot do any non-real-time safe operations (disk-accesses, system calls, etc.). To make it easy for the plugin to achieve its goals (e.g.: load a file from disk), the host can provide a worker thread. The host provides the LV2_Extension for the worker thread^[24] and the plugin is then able to use it.