[LAD] "enhanced event port" LV2 extension proposal

Lars Luthman lars.luthman at gmail.com
Mon Dec 3 02:32:50 UTC 2007


On Sun, 2007-12-02 at 21:08 -0500, Dave Robillard wrote:
> On Mon, 2007-12-03 at 02:29 +0100, Lars Luthman wrote:
> > 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.

I doubt anyone is ever going to use more than a couple of tens of URIs
with this. It's really only for things that will be compared and
processed in a realtime thread, non-time-critical code might as well use
strings directly. I'm fine with limiting the total number of URIs (or
symbols or names or whatever) to 2^16 in the URI mapping extension
itself to avoid annoying and inelegant constraints in the event port
extension.


> 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....

Hm. Feels a bit hacky. Memory isn't really an issue unless you use tens
of thousands of these which seems a bit unlikely, and if it's just for
code prettification you might as well use a macro.

  #define LV2(sfx) "http://lv2plug.in/ns/spec/lv2core#" sfx

  const char* my_uri_map[] = { LV2("Plugin"), LV2("Baaah"), NULL };


--ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071203/0ccb8148/attachment.pgp>


More information about the Linux-audio-dev mailing list