 | |
| Developer(s) | Steve Harris, David Robillard, other members of linux-audio-dev |
|---|---|
| Stable release |
1.18.10[1] |
| Repository | gitlab |
| Written in | C and Turtle |
| License | ISC License |
| Website | lv2plug |
LV2 (LADSPA Version 2) is a set of royalty-free open standards[2] for music production plug-ins and matching host applications. It includes support for the synthesis and processingofdigital audio and CV,[3] 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 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.[4][5]
Over twelve hundred plugins are now available in LV2 format.[6] Notable plugins include Calf Studio Gear.[7] Software that can host LV2 plugin "bundles" includes Ardour, Ingen, Carla (ofKXStudio), Qtractor, Traverso DAW,[8] Harrison Mixbus,[9] MusE, Audacity,[10] Ecasound, FFmpeg, Guitarix, 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, [11] Zynthian, and Poly Effects Digit/Beebo hardware units.
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.
The LV2 specifications are defined by[12] and make use[13]ofRDF 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 URIorURN. 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";
].
"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]
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.
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.
There are tools and frameworks available to assist with in creating LV2 plugins. These include DPF (DISTRHO Plugin Framework), 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.
