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?
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).
Any alternatives?
Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 16:15:05 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 16:15:05 EET