Programming LV2 Plugins ======================= :toc: :source-highlighter: pygments :pygments-style: friendly Introduction ------------ The link:http://lv2plug.in/ns[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. [ditaa] -------------------------------------------------------------------------------- Gain In | | v +-------------+ | | Audio In ----> | Amp | ------> Audio Out | | +-------------+ -------------------------------------------------------------------------------- Part 1: The code ~~~~~~~~~~~~~~~~ Let's start off by including the core LV2 header. [source,c] -------------------------------------------------------------------------------- #include -------------------------------------------------------------------------------- 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: [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=Amp] ---- We also define an `enum` for their indices to keep the code readable: [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=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 link:http://lv2plug.in/doc/html/group__lv2core.html#structLV2__Descriptor[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: [source,c] -------------------------------------------------------------------------------- include::../../plugins/eg-amp.lv2/amp.c[tags=instantiate] -------------------------------------------------------------------------------- [source,c] -------------------------------------------------------------------------------- include::../../plugins/eg-amp.lv2/amp.c[tags=cleanup] -------------------------------------------------------------------------------- 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. [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=connect_port] ---- 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: [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=run] ---- 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 link:http://lv2plug.in/doc/html/group__lv2core.html#structLV2__Descriptor[LV2_Descriptor]: [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=descriptor] ---- Then, expose it to the host with the `lv2_descriptor()` function, which is the entry point to our library: [source,c] ---- include::../../plugins/eg-amp.lv2/amp.c[tags=lv2_descriptor] ---- 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 http://www.w3.org/TeamSubmission/turtle/[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: [source, turtle] -------------------------------------------------------------------------------- include::../../plugins/eg-amp.lv2/amp.ttl[tags=prefixes] -------------------------------------------------------------------------------- To describe our plugin, we can start by saying that our plugin is `a` link:http://lv2plug.in/ns/lv2core#Plugin[Plugin]: footnote:[`a` here is a special shorthand for `rdf:type`] [source, turtle] -------------------------------------------------------------------------------- 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: [source, turtle] -------------------------------------------------------------------------------- lv2:project ; doap:name "Simple Amplifier" ; doap:license ; 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: [source, turtle] -------------------------------------------------------------------------------- include::../../plugins/eg-amp.lv2/amp.ttl[tags=ports] -------------------------------------------------------------------------------- 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: [source, turtle] -------------------------------------------------------------------------------- @prefix lv2: . @prefix rdfs: . a lv2:Plugin ; lv2:binary ; rdfs:seeAlso . -------------------------------------------------------------------------------- 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: [source,c] -------------------------------------------------------------------------------- #include #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: [source, turtle] -------------------------------------------------------------------------------- @prefix doap: . @prefix lv2: . @prefix rdf: . @prefix rdfs: . @prefix units: . a lv2:Plugin ; lv2:project ; doap:name "Simple Amplifier" ; doap:license ; 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: [source, turtle] -------------------------------------------------------------------------------- @prefix lv2: . @prefix rdfs: . a lv2:Plugin ; lv2:binary ; rdfs:seeAlso . -------------------------------------------------------------------------------- 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. [ditaa] -------------------------------------------------------------------------------- MIDI (LV2 atom) | | v +-------------+ | | Audio In ----> | Gate | ------> Audio Out | | +-------------+ -------------------------------------------------------------------------------- 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: [source,turtle] -------------------------------------------------------------------------------- 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 http://lv2plug.in/ns/ext/atom[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 http://lv2plug.in/ns/ext/midi/[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 http://lv2plug.in/ns/ext/urid[URID] extension which makes using Atom ports a bit easier. So, let's include that as well: [source,turtle] -------------------------------------------------------------------------------- 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: [source,c] -------------------------------------------------------------------------------- #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 [source,c] -------------------------------------------------------------------------------- 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: [source,c] -------------------------------------------------------------------------------- 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. [source,c] -------------------------------------------------------------------------------- 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 [source,c] -------------------------------------------------------------------------------- static void activate(LV2_Handle instance) { Midigate* self = (Midigate*)instance; self->n_active_notes = 0; } -------------------------------------------------------------------------------- Part 3: MIDI Gate Wrapup ~~~~~~~~~~~~~~~~~~~~~~~~ In review...