[LV2] RFC: Describing programs

[David Robillard]

On Sun, 2013-02-10 at 11:02 +0200, Stefano D'Angelo wrote:
> 2013/2/10 David Robillard <d at drobilla.net>:
> > On Sun, 2013-02-10 at 10:56 +0200, Stefano D'Angelo wrote:
> > [...]
> >> > 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.
> >
> > Is there anything wrong with that solution?  Seems fine to me.
> 
> It works correctly at least. I was just considering that there's no
> much point in using the new lv2:Program thing.

If what you have is a preset, i.e. sets control ports and possibly loads
state, then no, not really.

Perhaps pset:Preset could be used for this purpose too by simply not
describing any state or control port values.

One elegant way of associating PC events with presets also applies to
controls, by literally describing a trigger event separately, like

program
    a lv2:PresetProgramThing
    rdfs:label "Whatever" ;
    midi:binding [
        a midi:ProgramChange ;
        midi:programNumber 42 ;
    ] .

But this has a few problems.  It's very verbose, and doesn't describe
bank, which in MIDI is a completely separate message sent via CC (why is
anyone's guess).  The verbosity and nested structure sucks quite a bit
when you use it dynamically.  It does however let you describe weird
things like a program triggered by note, though I'm not sure that's even
a good thing.  It is consistent with making a parameter work via CC
though:

param
    a lv2:Parameter ;
    rdfs:label "gain" ;
    midi:binding [
        a midi:Controller ;
        midi:controllerNumber 7
    ] .

I can't really say much about this preset+program mishmash stuff because
I don't know the use cases.  The one I do know, MIDI programs needing
labels, is straightforward and addressed by the current proposal.
There's been much hand-waving about programs+presets, but so far it
keeps ending up with the conclusion that they are entirely different
things.  It seems to me the *binding* of MIDI, which is a host
implemented thing, to presets, is almost entirely orthogonal to the
plugin having programs.  You could even bind program 1 in the host to a
preset that has plugin internal program 5 as a parameter.  Host MIDI
bindings are an entirely different animal, really.  You could bind
loading a preset (which may or may not set a program) to an OSC message
that's not even MIDI at all.  They aren't the same thing.

In short, program is a *parameter*.  If we need a standard way to
associate MIDI bank and program numbers with presets, I can add a
midi:bankNumber which I think is all that is needed for that
(midi:programNumber already exists), but it seems to me that is
completely different from the plugin itself supporting programs
internally.

-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/8b553817/attachment-0002.pgp>