On Mon, 2007-12-03 at 02:29 +0100, Lars Luthman wrote: > On Sun, 2007-12-02 at 19:39 -0500, Dave Robillard wrote: > > On Sun, 2007-12-02 at 22:25 +0000, Krzysztof Foltman wrote: > > > Lars Luthman wrote: > > > > with data padded to 4+N*16 bytes > > > 4 + N*8. 16 is excessive, while 4 is not enough (to be able to store > > > aligned doubles or 64-bit pointers). > > > > > > But, yes, I think header is ready. Right, Dave? > > > > Works for me, I get my timestamp :) > > > > On to the buffer header (same as MIDI? more clever?) and the URI<->int > > mechanism.. > > Aligned to 8 bytes sounds good to me too. Done. > > I'm happy with a port buffer header that has the same layout as the > current MIDI one (I should be...). > > For the URI<->int mapping, I've changed my mind and vote for a separate > Feature that you have to explicitly list in the RDF file. It may be > useful for other extensions where you need to have arbitrarily > extendable stuff that you want to match to your known data reasonably > fast. The actual mapping would be done by the host by passing a > NULL-terminated URI array as the data for that Feature, where the index > of an URI in the array is the associated integer value. Or maybe we > should pass the size of the array as well and require that it's sorted > in lexicographical order, so a clever plugin can do a binary search? Not > really important, it will only happen at instantiation time anyway.
Fully agreed. int<->URI mapping is generic and widely useful. This does have me thinking about range though.. you can have an awful lot of URIs in a system. I guess the generic extension can map to, say, uint32_t, but the event extension can specifically say the event type URIs need to fit in uint16_t? Maybe doesn't matter but I think allowing a huge number of URIs is a good idea if it's just a single (or half) word, just in case. Though that's starting to sound like we're implementing a symbol system... probably going to be wanting one of those at some point regardless. Is that what this really is? (probably doesn't affect implementation much, just a hypothetical question). If it is just for URIs, we could maybe take advantage of prefixes and save some space in that table? lv2:Plugin is a lot nicer to deal with in all cases than http://lv2plug.in/ns/spec/lv2core#Plugin.... -DR- _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
