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