Programming LV2 Plugins

Introduction

The LV2 specification(link) is a large collection of documentations and extensions to the core LV2 API. On their own they’re difficult to parse. In this document a collection of example plugins are presented to show how the components of LV2 fit together and demonstrate best practices when writing LV2 plugins.

Overall this guide should be considered a complement for the more complete LV2 specification. The examples presented will correspond with those included in the LV2 distribution and will be presented in order of increasing complexity.

This includes:

A simple amplifier: Shows the basic LV2 skeleton, introduces control ports, provides basic .ttl file information
A MIDI gate: Shows midi processing, introduces LV2 atoms, introduces LV2 extension API
Fifths: A more complex MIDI processor, explains ??? LV2 concept
Metromome: Explores timining information, explains ??? LV2 concept
A trivial sampler: Provides a MIDI waveform sampler, introduces the LV2 worker extension and extensions in general
A GUI oscilloscope: Discusses user interfaces in the context of the LV2 ecosystem

This manual encourages users to jump around, but recommends reading the LV2 asides in each chapter in order to best understand how the LV2 specific concepts relate to each other.

Building a basic amplifier

In this example we’re going to build a simple amplifier plugin. There will be audio input, audio output, and a gain control.

Part 1: The code

Let’s start off by including the base LV2 headers and defining a name for the plugin.

#include <lv2/lv2plug.in/ns/lv2core/lv2.h>
#define AMP_URI "http://lv2plug.in/plugins.eg-amp"

In this case we’re using one of the core LV2 headers which has it’s API specification at an almost identical URL: http://lv2plug.in/ns/lv2core This is by design and is an easy way to find detailed information about LV2 core API and extensions.

In LV2 applications, the plugins are responsible for keeping track of information associated with what audio and control ports they have as well as to what host controlled data structures they’re attached to. For the basic amplifier plugin we can define a short enum and struct to keep track of them.

typedef struct {
    const float *gain;     //control input
    const float *data_in;  //audio  input
    float       *data_out; //audio output
} Amp;

typedef enum {
    AMP_GAIN,
    AMP_INPUT,
    AMP_OUTPUT
} PortIndex;

With the data for our amplifier setup we need to implement the functions needed for the host to communicate with our plugin. These functions are summarized in the LV2_descriptor(link) which is passed to a host and it includes:

instantiate: Setup the core data structures of a plugin
connect_port: Connect audio, MIDI, etc inputs and outputs to the plugin host
activate: Reset the plugin to a default state and prepare it to run
run: Process audio, MIDI, and other events. (regularly called)
deactivate: Stop the plugin from running anymore
cleanup: Free any resources that the plugin got during instantiate
extension_data: Used for LV2 extensions (see XXX example)
NOTE: For this simple plugin we don’t really need to care about when each one of these callbacks can be called. For more detailed information about what guarentees you have for when each callback may be invoked see XXX

The amplifier is a simple plugin, so right off the bat it’s possible to make some simple definitions for the functions we don’t need:

static void activate(LV2_Handle instance) {}
static void deactivate(LV2_Handle instance) {}
static const char *extension_data(const char *uri) { return NULL; }

Since all of the plugins internal information is stored in the Amp struct the definitions for resource acquisition are similarly trivial:

static LV2_Handle instantiate(const LV2_Descriptor *,
double, const char *, const LV2_Features**) { return calloc(sizeof(Amp)); }
static void cleanup(LV2_Handle instance) { free(instance) };

Connecting ports provided by the LV2 host is somewhat more complex. Each call from the host will provide a pointer to a buffer for one of the ports. The plugin will need to store that pointer and either read from it or write to it depending upon if it’s an input or an output.

static void
connect_port(LV2_Handle instance,
             uint32_t   port,
             void*      data)
{
	Amp* amp = (Amp*)instance;

	switch ((PortIndex)port) {
	case AMP_GAIN: amp->gain = (const float*)data; break;
	case AMP_INPUT: amp->input = (const float*)data; break;
	case AMP_OUTPUT: amp->output = (float*)data; break;
	}
}

After the host has connected data to each one of the ports and activated the plugin then the amplfier LV2 plugin can run for a number of samples.

#define DB_CO(g) ((g) > -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f)

static void
run(LV2_Handle instance, uint32_t n_samples)
{
	const Amp* amp = (const Amp*)instance;

	const float        gain   = *(amp->gain);
	const float* const input  = amp->input;
	float* const       output = amp->output;

	const float coef = DB_CO(gain);

	for (uint32_t i = 0; i < n_samples; ++i)
		output[i] = input[i] * coef;
}

All that’s left is providing the host with a descriptor containing pointers to all of these functions. Since multiple LV2 plugins can be contained in the same shared library this is done through the exported lv2_descriptor(link) function:

static const LV2_Descriptor descriptor = {
	AMP_URI,
	instantiate,
	connect_port,
	activate,
	run,
	deactivate,
	cleanup,
	extension_data
};

LV2_SYMBOL_EXPORT
const LV2_Descriptor*
lv2_descriptor(uint32_t index)
{
	switch (index) {
	case 0:  return &descriptor;
	default: return NULL;
	}
}

Part 2: The specification

Now that we have an amplifier plugin setup, you might expect that a host could load it and be ready to run. The code however doesn’t define all of the details. For instance the code doesn’t provide a list of the inputs and outputs of the plugin, so how does the host know about them?

The answer is that LV2 uses data files to store this information.

LV2 plugins are defined in two parts: code and data. The code is written in C, or any C compatible language such as C++. Static data is described separately in the human and machine friendly Turtle syntax.

Generally, the goal is to keep code minimal, and describe as much as possible in the static data. There are several advantages to this approach:

Hosts can discover and inspect plugins without loading or executing any plugin code.
Plugin data can be used from a wide range of generic tools like scripting languages and command line utilities.
The standard data model allows the use of existing vocabularies to describe plugins and related information.
The language is extensible, so authors may describe any data without requiring changes to the LV2 specification.
Labels and documentation are translatable, and available to hosts for display in user interfaces.

A .ttl file maps a collection of properties to values using a collection of URLs. Now let’s build one for the amplifier called amp.ttl

We can start out by saying that the AMP_URL which we previously defined is a plugin:

<http://lv2plug.in/plugins/eg-amp>
    a http://lv2plug.in/ns/lv2core#Plugin .

Since we’re going to define a number of properties in the LV2 namspace, let’s define a few macros to condense the file and since we’re defining multiple properties on our plugin let’s use the continuation ; rather than the property terminator ..

@prefix doap:  <http://usefulinc.com/ns/doap#> .
@prefix lv2:   <http://lv2plug.in/ns/lv2core#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix units: <http://lv2plug.in/ns/extensions/units#> .
<http://lv2plug.in/plugins/eg-amp>
    a lv2:Plugin ;

From here we can provide information to what project the plugin is associated with, a display name, a license, and even specify features of the plugin:

	lv2:project <http://lv2plug.in/ns/lv2> ;
	doap:name "Simple Amplifier" ;
	doap:license <http://opensource.org/licenses/isc> ;
	lv2:optionalFeature lv2:hardRTCapable ;

Now as per defining the inputs and outputs of the plugin, let’s consider what information we need to specify.

Type of data
Input vs output
Name of the port for a host to display
Index in the C code
etc

For the control port it could also be handy to state the default value, a minimum, maximum, and what sort of units are present. All of this information helps hosts display the state of the plugin.

With these basics in mind we have the following port description:

	lv2:port [
		a lv2:InputPort , lv2:ControlPort ;
		lv2:index 0 ;
		lv2:symbol "gain" ;
		lv2:name "Gain"
		lv2:default 0.0 ;
		lv2:minimum -90.0 ;
		lv2:maximum 24.0 ;
		units:unit units:db ;
	] , [
		a lv2:AudioPort , lv2:InputPort ;
		lv2:index 1 ;
		lv2:symbol "in" ;
		lv2:name "In"
	] , [
		a lv2:AudioPort , lv2:OutputPort ;
		lv2:index 2 ;
		lv2:symbol "out" ;
		lv2:name "Out"
	] .

Part 3: The bundle

Phew, that’s a lot of setup, but we’re almost there. All that’s left is creating a bundle for the audio plugin and describing the contents in a manifest .ttl. What’s a bundle exactly? Well a bundle is a directory that includes:

The plugin’s executable library
One ttl file per plugin in the library to define ports and describe features about the plugin
One manifest .ttl file providing metadata about what ttl files a host needs to look at

This manifest file makes searching through your plugin library a quick and efficient process for plugin hosts and as such you’re expected to have a tiny manifest. For this project it is:

@prefix lv2:  <http://lv2plug.in/ns/lv2core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://lv2plug.in/plugins/eg-amp>
	a lv2:Plugin ;
	lv2:binary <amp.so>  ;
	rdfs:seeAlso <amp.ttl> .

In that manifest we define that:

The bundle only contains one plugin
The URI of that plugin
The files that the host needs to use the plugin.

Part 4: A recap

amp.c:

#include <lv2/lv2plug.in/ns/lv2core/lv2.h>
#define AMP_URI "http://lv2plug.in/plugins.eg-amp"

typedef struct {
    const float *gain;     //control input
    const float *data_in;  //audio  input
    float       *data_out; //audio output
} Amp;

typedef enum {
    AMP_GAIN,
    AMP_INPUT,
    AMP_OUTPUT
} PortIndex;

static void activate(LV2_Handle instance) {}
static void deactivate(LV2_Handle instance) {}
static const char *extension_data(const char *uri) { return NULL; }

static LV2_Handle instantiate(const LV2_Descriptor *,
double, const char *, const LV2_Features**) { return calloc(sizeof(Amp)); }
static void cleanup(LV2_Handle instance) { free(instance) };

static void
connect_port(LV2_Handle instance,
             uint32_t   port,
             void*      data)
{
	Amp* amp = (Amp*)instance;

	switch ((PortIndex)port) {
	case AMP_GAIN: amp->gain = (const float*)data; break;
	case AMP_INPUT: amp->input = (const float*)data; break;
	case AMP_OUTPUT: amp->output = (float*)data; break;
	}
}

#define DB_CO(g) ((g) > -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f)

static void
run(LV2_Handle instance, uint32_t n_samples)
{
	const Amp* amp = (const Amp*)instance;

	const float        gain   = *(amp->gain);
	const float* const input  = amp->input;
	float* const       output = amp->output;

	const float coef = DB_CO(gain);

	for (uint32_t i = 0; i < n_samples; ++i)
		output[i] = input[i] * coef;
}

static const LV2_Descriptor descriptor = {
	AMP_URI,
	instantiate,
	connect_port,
	activate,
	run,
	deactivate,
	cleanup,
	extension_data
};

LV2_SYMBOL_EXPORT
const LV2_Descriptor*
lv2_descriptor(uint32_t index)
{
	switch (index) {
	case 0:  return &descriptor;
	default: return NULL;
	}
}

amp.ttl:

@prefix doap:  <http://usefulinc.com/ns/doap#> .
@prefix lv2:   <http://lv2plug.in/ns/lv2core#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix units: <http://lv2plug.in/ns/extensions/units#> .
<http://lv2plug.in/plugins/eg-amp>
    a lv2:Plugin ;
	lv2:project <http://lv2plug.in/ns/lv2> ;
	doap:name "Simple Amplifier" ;
	doap:license <http://opensource.org/licenses/isc> ;
	lv2:optionalFeature lv2:hardRTCapable ;
	lv2:port [
		a lv2:InputPort , lv2:ControlPort ;
		lv2:index 0 ;
		lv2:symbol "gain" ;
		lv2:name "Gain"
		lv2:default 0.0 ;
		lv2:minimum -90.0 ;
		lv2:maximum 24.0 ;
		units:unit units:db ;
	] , [
		a lv2:AudioPort , lv2:InputPort ;
		lv2:index 1 ;
		lv2:symbol "in" ;
		lv2:name "In"
	] , [
		a lv2:AudioPort , lv2:OutputPort ;
		lv2:index 2 ;
		lv2:symbol "out" ;
		lv2:name "Out"
	] .

manifest.ttl:

@prefix lv2:  <http://lv2plug.in/ns/lv2core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://lv2plug.in/plugins/eg-amp>
	a lv2:Plugin ;
	lv2:binary <amp.so>  ;
	rdfs:seeAlso <amp.ttl> .

That’s the first LV2 plugin example out of the way. In this chapter we introduced the code skeleton needed to run a LV2 plugin, the necessary supporting metadata files, and how they can be bundled together to form a distributable bundle. This is just the basics of the LV2 API and we’ll start to get a bit more in depth with the next example which starts processing MIDI events.

Building a MIDI Gate

Now that the basic skeleton is out of the way, let’s talk about a slightly more complex control data in the form of MIDI. Sticking with the same core functionality of an amplifier, let’s build a new plugin that either outputs the input signal or outputs a sequence of zeros depending upon the current MIDI input.

Part 1: What’s an Atom?

Instead of starting with the code for this new plugin, let’s take a look at how the .ttl files will differ. The manifest will be nearly identical once the plugin name is changed. The midigate.ttl file will feature a replacement for the old control port looking like:

	lv2:port [
		a lv2:InputPort ,
			atom:AtomPort ;
		atom:bufferType atom:Sequence ;
		atom:supports midi:MidiEvent ;
		lv2:designation lv2:control ;
		lv2:index 0 ;
		lv2:symbol "control" ;
		lv2:name "Control"
	] , [

We’ve got a new type of port which features LV2 atoms. A LV2 Atom is essentially a flexible container for all sorts of different data. It could be floats, strings, arrays, etc. In this case we’re specifying that it uses MIDI by specifying lv2:supports. Lastly we provide a hint to the host that the primary (and currently only) control input is this port by specifying the lv2:destination.

Part 1b: What’s an Atom URID?

Both midi and atom are in the extension namespace of LV2, but they’re generally considered part of the core set of features a host should provide. Going beyond them, there is the URID extension which makes using Atom ports a bit easier. So, let’s include that as well:

	lv2:requiredFeature urid:map ;

Part 2: Handling Atoms in C

A large bit of this plugin is going to still use the same skeleton as the first example, so let’s focus on what is different. To start off with, we’re going to need headers for each one of the chunks of the API we’re using:

#include "lv2/lv2plug.in/ns/ext/atom/atom.h"
#include "lv2/lv2plug.in/ns/ext/atom/util.h"
#include "lv2/lv2plug.in/ns/ext/midi/midi.h"
#include "lv2/lv2plug.in/ns/ext/urid/urid.h"
#include "lv2/lv2plug.in/ns/lv2core/lv2.h"

#define MIDIGATE_URI "http://lv2plug.in/plugins/eg-midigate"

Next up we’ll want to store our data which consists of:

The port bindings
A URID which identifies a MIDI event from other Atom events
The number of active notes

typedef struct {
	const LV2_Atom_Sequence* control;
	const float*             in;
	float*                   out;

    LV2_URID midi_MidiEvent;

	unsigned n_active_notes;
} Midigate;

Now in instantiate we can find the value of the MIDI event URID:

static LV2_Handle
instantiate(const LV2_Descriptor*     descriptor,
            double                    rate,
            const char*               bundle_path,
            const LV2_Feature* const* features)
{
    //Search the provided feature list for the requested URID mapper
	LV2_URID_Map* map = NULL;
	for (int i = 0; features[i]; ++i) {
		if (!strcmp(features[i]->URI, LV2_URID__map)) {
			map = (LV2_URID_Map*)features[i]->data;
			break;
		}
	}

    //A host MUST provide the required features
    assert(map);

	Midigate* self = (Midigate*)calloc(1, sizeof(Midigate));
    //Store the URID for a midi event
	self->uris.midi_MidiEvent = map->map(map->handle, LV2_MIDI__MidiEvent);

	return (LV2_Handle)self;
}

Now to handle the actual MIDI events. Within the run() function we can step through all of the events in the control port and handle them in-order. What this means for the output port is that we can process a chunk of samples up to the new MIDI event, update the number of notes, and then process the next chunk of data.

static void
run(LV2_Handle instance, uint32_t sample_count)
{
	Midigate* self   = (Midigate*)instance;
	size_t  offset = 0;

	LV2_ATOM_SEQUENCE_FOREACH(self->control, ev) {
		write_output(self->out + offset, self->in + offset,
                     self->n_active_notes > 0,
                     ev->time.frames - offset);


		if (ev->body.type == self->uris.midi_MidiEvent) {

			const uint8_t* const msg = (const uint8_t*)(ev + 1);

			switch (lv2_midi_message_type(msg)) {
			case LV2_MIDI_MSG_NOTE_ON:  ++self->n_active_notes; break;
			case LV2_MIDI_MSG_NOTE_OFF: --self->n_active_notes; break;
			}
		}


		offset = ev->time.frames;
	}

    write_output(self->out + offset, self->in + offset,
                 self->n_active_notes > 0,
                 sample_count - offset);
}

static void
write_output(float *dst, const float *src, bool active, size_t len) {
	if (active)
		memcpy(dest, src, len * sizeof(float));
	else
		memset(dest, 0,   len * sizeof(float));
}

Now the last bit of housekeeping. When we first initialize the plugin all of the data is zeroed out, but that isn’t the case if the host deactivates the plugin and reruns the activate() function. We need to preserve any connections, but wipe out any state in the plugin. For the MIDI gate this is just clearing the number of active notes

static void activate(LV2_Handle instance) {
	Midigate* self = (Midigate*)instance;
	self->n_active_notes = 0;
}

Part 3: MIDI Gate Wrapup

In review…