Re: [LAD] "enhanced event port" LV2 extension proposal

On Thu, 2007-11-29 at 12:55 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
>
> > I'd prefer to just have one MIDI event type and pass the status bytes as
> > part of the event data. That way you can have generic MIDI processors or
> > channel filters or whatever without having to list every event type in
> > the RDF file.
>
> Yes. MIDI Implementation Chart LV2 extension, anyone? ;)
>
> In fact, MIDI Map extension serves exactly that purpose - however, it
> only deals with CC, not other messages.
>
> A totally unrelated note: static RDF files in LV2 might be fine for now,
> but sometimes I'd like to generate the same kind of metadata on the fly.
> Think dynamic parameters, dynamic event types, editable CC maps...
>
> Nedko has tried to solve the first problem by his dynamic parameters
> extension, but I guess that a general solution could be better, because
> the same problem he had with params, is practically guaranteed to appear
> everywhere else.
>
> Think of plugin standard adapters (VST-to-LV2) and the like. Or any
> adapters, bridges and what not. Or plugin-side MIDI learn which sends
> controller information via dynamic CC map.
>
> Any thoughts how to attack that problem? A function to send an updated
> RDF to the host? A function to send incremental information?

We will want that eventually, but it's officially Hard(TM) :)

> Oh, and by the way - Nedko has mentioned that a *host* may want to send
> updates of URI number allocations - how are we going to solve that?
>
> I suppose a host object with a function to subscribe/unsubscribe
> URI-number allocation update information could be a way to go - a
> classic Observer pattern. A plugin that doesn't make use of it would
> just ignore unknown event types in the event buffer, which is fine, as
> long as the only URIs that may appear in updates are new URIs (there are
> no reassignments or deletions).

Dynamic URI<->int mapping is probably a good thing. Raises issues
though - maybe an acceptable compromise is that the existing ones never
change, but ones can be added? Really no reason an already designated
number needs to change URIs that I can think of, just tack new ones on
the end.

-DR-

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 30 04:15:03 2007