[LV2] RFC: Describing programs

[Stefano D'Angelo]

2013/2/10 David Robillard <d at drobilla.net>:
> 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.

Mmm... I guess I can blame everything on DSSI API at the end of the
day. I mean, since in DSSI a plugin is allowed to change its own input
control port values and since MIDI program == preset, I don't think
it's possible to do much better than what the NASPRO bridge does, that
is to export "DSSI programs" to LV2 presets and prevent usage of
DSSI's program change mechanism.

But, more importantly, I don't think anybody cares.

Stefano