aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDavid Robillard <d@drobilla.net>2011-03-10 04:43:48 +0000
committerDavid Robillard <d@drobilla.net>2011-03-10 04:43:48 +0000
commit800609f7ee4f73ddcc6916fe346a74a9e33b6a9f (patch)
tree15ea8a1bfe9f4baf72601ef465cb8ad14784c83b
parent4c606a36fbda4f8c649282f1c52d9a3bf80b3f56 (diff)
downloadlv2-800609f7ee4f73ddcc6916fe346a74a9e33b6a9f.tar.xz
Rewrite overview to be a bit more modern and to the point.
-rw-r--r--core.lv2/lv2.ttl69
1 files changed, 35 insertions, 34 deletions
diff --git a/core.lv2/lv2.ttl b/core.lv2/lv2.ttl
index 27943d7..8ed3d06 100644
--- a/core.lv2/lv2.ttl
+++ b/core.lv2/lv2.ttl
@@ -87,41 +87,42 @@ more details.
lv2:documentation """
<h4>Overview</h4>
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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 <code>float</code> 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 <code>float</code> 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.</p>
-
-<p>Plugins reside in shared object files suitable for dynamic linking (e.g. by
-dlopen() and family). This object provides one or more <a
+<p>LV2 gives programmers the ability to write audio processors (or
+<em>plugins</em>) in C/C++ which can be dynamically loaded into a range of
+applications (or <em>hosts</em>).</p>
+
+<p>This specification is deliberately as short and simple as possible, but is
+designed so that <em>extensions</em> 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 <a
+href="http://www.w3.org/TeamSubmission/turtle/">Turtle</a>. 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.</p>
+
+<p>Plugins can operate on any type of data, which is input/output via
+<em>ports</em>. Data is processed by first <em>connecting</em> each port to a
+buffer, then repeatedly calling a plugin's <code>run()</code> method to process
+a <em>block</em> of data of some host-specified length (measured in audio
+frames).</p>
+
+<p>This <em>core</em> specification defines two types of port, equivalent to
+those in <a href="http://www.ladspa.org/">LADSPA</a>: <em>control</em> and
+<em>audio</em>. Audio data is communicated using arrays with one
+<code>float</code> element per sample, allowing a block of audio to be
+processed by the plugin in a single call to <code>run()</code>. Control data is
+communicated using single <code>float</code> values, which are considered valid
+for the duration of the call to <code>run()</code>. Thus the "control rate" is
+determined by the block size, which is controlled by the host (and not
+necessarily constant).</p>
+
+<p>Plugins reside in shared object files suitable for dynamic linking (e.g. via
+<code>dlopen()</code>). This <em>library</em> provides one or more <a
href="urn:struct:LV2_Descriptor">plugin descriptors</a> via the
-lv2_descriptor() function. These plugins can be instantiated to create "plugin
-instances", which can be connected together to perform tasks.</p>
-
-<p>This API contains very limited error-handling.</p>
+<code>lv2_descriptor()</code> function. These plugins can be instantiated to
+create plugin <em>instances</em>, which can be run directly on data or
+connected together to perform advanced signal processing tasks.</p>
<h4>Threading Rules</h4>