3 Dec
2007
3 Dec
'07
1:16 p.m.
On Mon, 2007-12-03 at 03:32 +0100, Lars Luthman wrote:
On Sun, 2007-12-02 at 21:08 -0500, Dave Robillard
wrote:
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.
On Mon, 2007-12-03 at 02:29 +0100, Lars Luthman
wrote:
I doubt anyone is ever going to use more than a couple of tens of URIs
with this. 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. 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.
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-
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 };