[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
useful.
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
presets.
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.
-dr
-------------- 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