Re: [LAD] "enhanced event port" LV2 extension proposal

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Dec 3 04:15:03 2007