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

On Mon, 2007-12-03 at 03:32 +0100, Lars Luthman wrote:
> 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.

What if, say, symbols are used as identifiers to shared data structures?
If you've got a symbol per sample or something, it could get high fast.

OSC has a specific symbol type we could use to get super fast
comparison/lookup of things keyed by symbol. Parameters in each message
being a symbol? That can definitely get high fast...

Using a uint32_t (which is a reasonable limit for number of symbols in
pretty much any system) and just not using out of range numbers for the
event ones doesn't seem so bad, just in case. It's one line in a
comment somewhere, BFD.

> 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 };

Yeah, this extension probably shouldn't be concerned with the actual
contents of the strings/symbols anyway (they can still be prefixed names
in some cases). Just a thought..

-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 20:15:02 2007