aboutsummaryrefslogtreecommitdiffstats
path: root/doc/lv2_plugin_guide/guide.adoc
blob: c59f346a151c2f1d89e62baa31eb8b818c0dc835 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
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/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:

[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&lowbar;_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&lowbar;_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]
--------------------------------------------------------------------------------
<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:

[source, turtle]
--------------------------------------------------------------------------------
	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:

[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:  <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:
[source,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:
[source, turtle]
--------------------------------------------------------------------------------
@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:
[source, turtle]
--------------------------------------------------------------------------------
@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.

[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...