LV2 is a standard for plugins and matching host applications, mainly targeted at audio processing and generation.
LV2 is a simple but extensible successor of LADSPA, intended to address the limitations of LADSPA which many applications have outgrown.
While LADSPA has been quite successful with many plugins and hosts, it is quite limited and can't be extended without breaking existing implementations. LV2 in contrast is designed with extensibility in mind right from start.
With LADSPA, fixed data fields providing information about the plugin (like the number and type of ports) are inside the plugin binary, resulting in a number of problems:
LV2 separates the static data into RDF files in the easy to read and hand-write Turtle syntax. This provides a solution to all of the above problems. By using RDF, any kind of additional data can be added by plugin authors without compatibility problems. Thanks to RDF namespacing, anyone can create extensions under their own namespace. Successful extensions can then later be made part of the core spec. Strings can be internationalised easily.
The code portion of LV2 (the standard C header lv2.h) is deliberately as small and generic as possible. Hooks are provided for passing around any type of data, so LV2 is not limited by the features built in to the "core specification". Instead, "extensions" to LV2 can be defined independently and used by hosts and plugins. The "core" LV2 specification is generic enough that almost any conceivable type or feature is possible, but the plugin can still function (without extended features) in a more basic host.
Everything a LV2 plugin needs is bundled inside a directory, which can easily be handled as a whole while still allowing direct access to the parts.
LV2 offers identification of plugins and ports not (necessarily) by obscure ID numbers, but human readable URIs and port symbols.
The URI can be a web address (optionally, any URI is fine). This allows the use of HTTP content negotiation to ask for the RDF of a plugin originally only the URI is known of. The RDF could include machine readable information about where to get the plugin. Thus sharing files that reference plugins such as sequencer sessions or modular synthesizer patches would become more comfortable, as missing plugins could be fetched automatically (or finding them would be easier, at least).
While ports have an index (like in LADSPA), all ports also have a "symbol": a short restricted name which makes low-level use such as scripting and network use much more comfortable. There is also a distinct (possibly internationalised) 'friendly name' for ports, such as would be displayed in a user interface.
Ports are no longer limited to the float data type. Port type extensions will allow plugins to handle any data type, e.g. MIDI or OSC. Other possibilities include frequency domain (FFT) data, sample files managed by the host... any type conceivable
Existing extensions:
Other ideas:
... and many others. Because plugins authors may associate whatever data they wish with a plugin without any centralized standardization process, the possibilities are endless.
Development around LV2 is very active, with several developers porting and/or working on new things no previous Open Source plugin specification could handle.