Why LV2?
Unlike many popular audio plugin APIs, LV2 is a platform-agnostic Free Software specification with a liberal license permitting virtually any implementation (both free and proprietary).
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 the start. Instead of a monolithic design that can only be improved by a central authority, new functionality (an "extension") can be added to LV2 by anyone, making distributed development of the plugin API itself possible.
Bundles
Everything an LV2 plugin needs is bundled inside a directory, which can easily be handled as a whole while still allowing direct access to the parts. Users can easily manage their installations by moving or deleting bundles with any file manager.
Plugin Metadata
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:
There is code for providing static data inside each plugin's implementation. The plugin has to be loaded and linked to retrieve any information about it, leading to potential crashes and making it difficult to write tools in other languages. There's no support for internationalisation. Adding new static data without causing compatibility problems is difficult or impossible. 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 and use extensions. Strings can be internationalised easily. Detailed descriptions and documentation can be written using a very large (and growing) pool of pre-existing vocabularies.
Generic API
The code portion of LV2 (the C99 header lv2.h) is as small and generic as possible. Hooks are provided for passing around any type of data, so LV2 is not limited to 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 of feature is possible, but plugins can degrade gracefully if a host does not support a particular feature.
Distributed Development
LV2 offers identification of plugins and ports not (necessarily) by obscure ID numbers, but by human-readable URIs and "symbols" (restricted strings).
The use of URIs allows developers to create plugins, extensions, and hosts, requiring only "fine-grained" coordination between developers implementing an extension (or none at all if a developer is working on both a host and plugin implementation).
While ports have an index (like in LADSPA) at runtime, the ID of a port is a "symbol": a short restricted name which makes uses in e.g. scripting and networking much more comfortable. There is also a distinct (possibly internationalised) "friendly name" for ports, such as would be displayed in a user interface.
