[LV2] RFC: Describing programs

David Robillard d at drobilla.net
Sun Feb 10 00:41:14 PST 2013

On Sun, 2013-02-10 at 10:23 +0200, Stefano D'Angelo wrote:
> 2013/2/10 David Robillard <d at drobilla.net>:
> > 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.
> Doc reads "However, a program MAY be associated with a preset, or one
> resource may be both a program and a preset, to support completely
> changing a plugin instance's state via a program change.", which seems
> what I would need for the DSSI bridge... but it looks fuzzy. Maybe
> define a standard way for a host to know that a lv2:Program is
> associated with a preset? It could very well be that the program is
> the preset, but I got the feeling that you have something else in
> mind.

It is indeed currently fuzzy.  The main problem is that loading state is
not, in general, real-time, it requires a full 'stop the world'
deactivate, restore, activate.  Since things with simple internal
programs don't have this very rough requirement, a separate mechanism is

I don't really know, "associated" is probably not well-defined at all.
lv2:program is a property, so the obvious way they are associated is
that the plugin can save that property as part of its state.

The other thing is loading a preset with a program change.  That raises
a bunch of questions, like... who stores those things?  Who makes the
mapping?  What if one program number is assigned to several presets?

I am mainly interested in supporting MIDI programs, statically as in the
example, and then dynamically using the same vocabulary for things like
soundfont plugins.  Program is effectively a parameter.  I see no
problem in supporting this without dealing with all that preset+program
mess, which is really more like MIDI binding.

Dealing with that requires somebody to actually implement it.  I don't
personally have the time or inclination to do that on both the plugin
and host side.  If you do, feel free.  I know of exactly one existing
compelling use case for this, fluidsynth, and it doesn't care about
If they are static, can't you just stick bank and program numbers on a
preset description?  That may be an argument for using midi:bankNumber
and midi:programNumber instead of lv2:index.

-------------- 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/20130210/56530529/attachment-0002.pgp>

More information about the Devel mailing list