[LAD] "enhanced event port" LV2 extension proposal

[Dave Robillard]

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-