[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

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-