Programming LV2 Plugins

Introduction

The LV2 specification 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
Metronome: 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 core LV2 header.

#include <lv2/core/lv2.h>

LV2 has many "extensions" each with their own headers. This simple plugin uses only lv2.h from the "core" LV2 specification, http://lv2plug.in/ns/lv2core.

LV2 plugins are are responsible for keeping track of what ports they have and what host-controlled data structures they’re attached to. In our simple amplifier, these are the only variables stored in the plugin structure:

typedef struct {
	const float* gain;   // Gain control input
	const float* input;  // Audio input
	float*       output; // Audio output
} Amp;

We also define an enum for their indices to keep the code readable:

typedef enum {
	AMP_GAIN   = 0,
	AMP_INPUT  = 1,
	AMP_OUTPUT = 2
} PortIndex;

With the data for our amplifier set up we need to implement the functions needed for the host to communicate with it. These functions will end up in the LV2_Descriptor which is accessed by the host.

This plugin does not need the activate, deactivate, or extension_data functions, which are optional and do not need to be defined if they are not needed. That leaves instantiate, connect_port, run, and cleanup.

Since this plugin contains minimal state, the instantiate and cleanup functions simply allocate and free the Amp structure:

static LV2_Handle
instantiate(const LV2_Descriptor*     descriptor,
            double                    rate,
            const char*               bundle_path,
            const LV2_Feature* const* features)
{
	Amp* amp = (Amp*)calloc(1, sizeof(Amp));

	return (LV2_Handle)amp;
}

static void
cleanup(LV2_Handle instance)
{
	free(instance);
}

Connecting ports provided by the host is a bit more involved. The host will provide a pointer to a buffer for one of the ports by calling connect_port. The plugin needs to store that pointer for use while it is running.

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, the plugin is ready to process audio. This is done by the run() function, which is called repeatedly for blocks of samples:

static void
run(LV2_Handle instance, uint32_t n_samples)
{
	/** Define a macro for converting a gain in dB to a coefficient. */
#define DB_CO(g) ((g) > -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f)

	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 pos = 0; pos < n_samples; pos++) {
		output[pos] = input[pos] * coef;
	}
}

Now that we’ve implemented the core of our plugin, all that’s left is to provide a descriptor to the host so that it can use the plugin. For this, we define an LV2_Descriptor:

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

Then, expose it to the host with the lv2_descriptor() function, which is the entry point to our library:

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

Part 2: The data

Now that we have an amplifier plugin written, you might expect that a host could run it. However, the code doesn’t include all the necessary details. For example, the code doesn’t provide a list of the inputs and outputs of the plugin, so how does the host know about them?

For various reasons, this information is provided in a separate data file which describes the plugin. Plugins, along with other things in LV2, are described in the human-friendly but machine-readable Turtle syntax.

A Turtle file describes things as sets of properties. If you are familiar with JSON, the basic idea is similar, but property keys are URIs rather than arbitrary strings.

First we will define some prefixes for the namespaces we use, to keep things nice and readable later on:

@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#> .

To describe our plugin, we can start by saying that our plugin is a Plugin: ^[1]

<http://lv2plug.in/plugins/eg-amp>
	a lv2:Plugin ;

Important

The URI used to identify the plugin must match the one in the code, AMP_URI in this example.

From here we can provide all kinds of information about our plugin, such as an associated project, display name, license, and supported features:

	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 [
# Every port must have at least two types, one that specifies direction
# (lv2:InputPort or lv2:OutputPort), and another to describe the data type.
# This port is a lv2:ControlPort, which means it contains a single float.
		a lv2:InputPort ,
			lv2:ControlPort ;
		lv2:index 0 ;
		lv2:symbol "gain" ;
		lv2:name "Gain" ,
			"收益"@zh ,
			"Verstärkung"@de ,
			"Gain"@en-gb ,
			"Aumento"@es ,
			"Gain"@fr ,
			"Guadagno"@it ,
			"利益"@jp ,
			"Увеличение"@ru ;
# An lv2:ControlPort should always describe its default value, and usually a
# minimum and maximum value.  Defining a range is not strictly required, but
# should be done wherever possible to aid host support, particularly for UIs.
		lv2:default 0.0 ;
		lv2:minimum -90.0 ;
		lv2:maximum 24.0 ;
# Ports can describe units and control detents to allow better UI generation
# and host automation.
		units:unit units:db ;
		lv2:scalePoint [
			rdfs:label "+5" ;
			rdf:value 5.0
		] , [
			rdfs:label "0" ;
			rdf:value 0.0
		] , [
			rdfs:label "-5" ;
			rdf:value -5.0
		] , [
			rdfs:label "-10" ;
			rdf:value -10.0
		]
	] , [
		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…

1. a here is a special shorthand for rdf:type