2 Dec
2007
2 Dec
'07
10:08 p.m.
On Mon, 2007-12-03 at 02:29 +0100, Lars Luthman wrote:
On Sun, 2007-12-02 at 19:39 -0500, Dave Robillard
wrote:
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-
On Sun, 2007-12-02 at 22:25 +0000, Krzysztof
Foltman wrote:
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. Lars Luthman wrote:
Works for me, I get my timestamp :)
On to the buffer header (same as MIDI? more clever?) and the URI<->int
mechanism.. 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?