From 800609f7ee4f73ddcc6916fe346a74a9e33b6a9f Mon Sep 17 00:00:00 2001
From: David Robillard There are a large number of open source and free software synthesis packages
-in use or development at this time. This API ("LV2") attempts to give
-programmers the ability to write simple "plugin" audio processors in C/C++ and
-link them dynamically ("plug" them) into a range of these packages ("hosts").
-It should be possible for any host and any plugin to communicate completely
-through this interface. This API is deliberately as short and simple as possible. The information
-required to use a plugin is in a companion data (RDF) file. The shared library
-portion of the API does not contain enough information to make use of the
-plugin possible; the data file is mandatory. Plugins can operate on any type of data. Plugins have "ports" that are
-inputs or outputs and each plugin is "run" for a "block" corresponding to a
-short time interval measured in samples. The plugin may assume that all its
-input and output ports have been connected to the relevant data location (using
-the connect_port() function) before it is asked to run, unless the port has
-been set "connection optional" in the plugin's data file. This "core" specification defines two types of port data, equivalent to
-those in LADSPA: control rate and audio rate. Audio rate data is communicated
-using arrays with one Plugins reside in shared object files suitable for dynamic linking (e.g. by
-dlopen() and family). This object provides one or more LV2 gives programmers the ability to write audio processors (or
+plugins) in C/C++ which can be dynamically loaded into a range of
+applications (or hosts). This specification is deliberately as short and simple as possible, but is
+designed so that extensions can be defined to add more advanced
+features. The shared library portion of the API includes only what must
+necessarily be written in code. The information required to use a plugin is in
+a companion data file, written in Turtle. Plugin libraries do
+not contain enough information to make use of the plugin possible; the data
+file is mandatory. This makes using, adding, and manipulating plugin data
+flexible and avoids binary compatibility issues. Plugins can operate on any type of data, which is input/output via
+ports. Data is processed by first connecting each port to a
+buffer, then repeatedly calling a plugin's This core specification defines two types of port, equivalent to
+those in LADSPA: control and
+audio. Audio data is communicated using arrays with one
+ Plugins reside in shared object files suitable for dynamic linking (e.g. via
+ This API contains very limited error-handling.Overview
-float
element per sample processed, allowing
-a block of audio to be processed by the plugin in a single pass. Control rate
-data is communicated using single float
values. Control rate data
-has a single value at the start of a call to the run() function which is
-considered valid for the duration of the call to run(). Thus the "control rate"
-is determined by the block size, controlled by the host.run()
method to process
+a block of data of some host-specified length (measured in audio
+frames).float
element per sample, allowing a block of audio to be
+processed by the plugin in a single call to run()
. Control data is
+communicated using single float
values, which are considered valid
+for the duration of the call to run()
. Thus the "control rate" is
+determined by the block size, which is controlled by the host (and not
+necessarily constant).dlopen()
). This library provides one or more plugin descriptors via the
-lv2_descriptor() function. These plugins can be instantiated to create "plugin
-instances", which can be connected together to perform tasks.lv2_descriptor()
function. These plugins can be instantiated to
+create plugin instances, which can be run directly on data or
+connected together to perform advanced signal processing tasks.