LV2

LV2 (LADSPA Version 2) is a set of royalty-free open standards[1] for plug-ins and matching host applications. It includes support for the synthesis and processing of digital audio and CV, [2] events such as MIDI and OSC, and provides a free alternative to audio plug-in standards such as Virtual Studio Technology (VST) and Audio Units (AU).

LV2
Developer(s)Steve Harris, David Robillard, other members of linux-audio-dev
Repositorygitlab.com/lv2/lv2
Written inC and Turtle
LicenseISC License
Websitelv2plug.in

LV2 succeeds the more limited Linux Audio Developer's Simple Plugin API (LADSPA) standard and replaces the Disposable Soft Synth Interface (DSSI) plugin infrastructure ("LADSPA for instruments"), adding abilities such as MIDI capability, custom UIs, and a system allowing extensibility of the initial standard.[3][4]

LV2 plugin listing in the Carla host

Over twelve hundred plugins are now available in LV2 format.[5] Notable plugins include Calf Studio Gear[6] Software that can host LV2 plugin "bundles" includes Ardour, Ingen, Carla (of the KXStudio distribution), Qtractor, Traverso DAW,[7] Harrison Mixbus,[8] MusE, Audacity,[9] Ecasound, FFmpeg, the GStreamer framework and DJing software Mixxx, with currently partial support in LMMS and REAPER. It is also the plugin format used by the MOD Duo and MOD Duo X, [10] Zynthian, and Poly Effects Digit/Beebo hardware units.

Concepts

LV2 is an extensible framework, allowing a program to load a plugin to do some processing. Note that the terms used here are generic on purpose because LV2 allows any type of data to be exchanged between the host and the plugin.

LV2 plugins in the Ingen host
LV2 modular drum synth in Carla

RDF

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

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.[15] 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.[16] 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 lines declare that this resource is an lv2:Plugin, a binary object file library with the filename silence.so should be present, that 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[17][18] for the transfer of MIDI,[19] OSC, Patch,[20] UI and other events between plugin instances. These can also be serialised to Turtle. [21][22]

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[23] and the plugin is then able to use it.

Development

There are tools and frameworks available to assist with in creating LV2 plugins. These include DPF (DISTRHO Plugin Framework), two forks of JUCE, Faust, Dplug, iPlug 2 (alpha), and Cabbage (alpha). There is also the ability to load Pure Data patches as well as JIT-run Faust, Rust, Lua or C code in certain LV2 plugins. For information exchange and discussions about LV2 there are user and developer mailing lists, along with the #lv2 and #lad channels on freenode IRC, and forums such as LinuxMusicians.

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.