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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev