[LV2] Dynamic midnam support for LV2 instruments.

[David Robillard]

On Fri, 2013-05-17 at 12:14 +0200, Bent Bisballe Nyeng wrote:
> Hi list
> 
> Ardour recently added midnam files for a variety of different midi 
> hardware. This has made me start thinking about how I could supply 
> similar functionality for my LV2 plugin.
> 
> In short; the midnam files map each midi note into a symbolic string 
> which can then be shown in the midi editor for easier note placement.
> 
> This could for example be "snare drum" for midi note 38 (as per GM 
> drummap), or "drain gurgling" for note 42 (which is not in any map that 
> I know of...)
> 
> I hereby propose a new extension, enabling the LV2 plugin to report back 
> the symbolic textual names of the midi notes to the host.

I tried to add some basic vocabulary for programs the last time around,
but it was rejected mainly due to an unclear relationship with presets,
and no established way to do dynamicism.  It is still a necessary thing,
though.

The MIDI extension already has vocabulary for describing notes,
controllers, and so on.  Sticking a label on one of those is easy
enough.

Logistically, the way to do this is, as (almost) always, via events.
Doing so quasi-manually (e.g. with LV2_Atom_Force) is pretty verbose
though, and requires grasping the basic idea of atom stuff.  So,
probably the most important thing to do to make this realistic is coming
up with a simpler interface (e.g. utility header) to make doing this
very simple for both hosts and plugins.

As a long-term sidenote, I think the static vs. dynamic thing here is a
symptom of something that needs to happen: the host code (via lilv)
should really be using the same basic data structures as the dynamic
code (atoms).  Ideally, getting this information from the .ttl or
dynamically should be nearly identical and share most of the involved
code.  That's a pretty long-term lilv overhaul that will probably
correspond with moving the host stuff into LV2 proper, which I won't
have time for any time soon, but I thought it worth mentioning.

Perhaps we should make a new Object type for updates about the plugin's
"world view" the host/UI might be interested in, then a host-side
utility header could provide a function that scans the plugin output and
fires a callback for every such event?  Probably, the simplicity of this
will have to fight against extensibility, but we probably at least want
to be able to do more than talk about MIDI CC and such...

-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/20130522/fbf90c3a/attachment-0002.pgp>