[LV2] RFC: Describing programs

David Robillard d at drobilla.net
Sat Feb 9 20:00:53 PST 2013

Hi all,

I have defined a way to describe programs, including but not limited to
MIDI programs.  The most basic use case here is to simply allow naming
programs, so hosts can present a decent UI, like that recently
implemented in Ardour for external instruments[1].

It is defined more broadly though, to be potentially usable in ways
other than MIDI, which we will build on in the future.

Since it didn't seem to fit anywhere else and seems pretty similar in
scope and appropriateness to lv2:Parameter, I stuck it in core.  See
svn, or commit for details:


This also adds a new simple example plugin that demonstrates how to
implement host-understood MIDI programs.  If you're not one for reading
schemas, see midigate.ttl which sums everything up tidily.  Notice how
the description is extremely similar to ports, which makes it seem
pretty conservative and Right to me.  I have deliberately made banks a
nested structure, though, rather than a property as in port groups, to
keep things terse and more well-defined.


There is a bit of strange overlap here with presets, but once understood
I think the distinction is sensible, which I have hopefully described
clearly in the lv2:Program documentation.

As an aside, this is somewhat similar to how we will move to event-based
control: first, simply as a way of naming MIDI controllers by describing
them as an lv2:Parameter.  Then, there is the possibility of a different
protocol for setting them (e.g. an atom-based one that supports 32-bit
float), since the definition is separate from the events used to change
them.  It is a nice way to both add basic MIDI name functionality while
also gracefully transitioning to more modern event-based controls
without hitting implementers over the head with it.  This commit deals
only with programs, though.

This only defines some vocabulary for describing programs, which is
directly usable for describing static programs in plugin data files.
Dynamic programs (using the same vocabulary) are also possible (the
atom-savvy will immediately see how to do this, nothing new is
required), as are "state/port changing programs" (new stuff is required
there), and both, but I am leaving implementing example plugins and host
support for this until after 1.4.0.

Other than potentially doing a named CC example as well, this is the
last thing I wanted to get done for LV2 1.4.0, which would be nice to
release soon, so comments are most welcome.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130209/8a5705cf/attachment.pgp>

More information about the Devel mailing list