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

Dave Robillard wrote: We have some choices: 1. your original uint8_t - good because you can still do (&event->data)[offset], bad because it breaks sizeof somewhat, making it totally misleading (this particular clock doesn't show the right time even once per 12 hours ;) ) 2. uint8_t[1] - variant of solution 1, just *slightly* better because you can write event->data[offset] instead of (&event->data)[offset] 3. uint8_t[0] - gcc extension, possibly incompatible with non-gcc compilers (I don't care, I bet someone else does) 4. uint8_t[4] - variant of solution 1 with somewhat better sizeof behaviour (at least it returns the proper size for payload length <= 4) 5. separate "header structure" and event-type specific "event structure" (with header as first field), equivalent to what Nedko proposed. Not as awkward as you probably imagine. You'll find examples in my previous mails if you have any doubt about what I mean. I'm fine with either choice. 4 and 5 look somewhat attractive, 3 is probably out of the question. Anyway, we're arguing about changing one or two lines of code in a plugin here, so if you think a single uint8_t member is a way to go, it's fine IMHO. The URI passing thing is much more interesting, as it affects 5 lines of plugin code, not 2, so it'd be better to concentrate on that one. I'd still prefer to have new URI mappings delivered to plugins (which you don't like), and URI-int mapping to be implemented in a host (which you like, IIRC). No matter what calling convention is - "C++-style" object or a structure with function pointer and instance pointer. At least as long as it doesn't lead to GObject-style insanity :) Absolutely. Yes, and how would you refer to in-place char data? ((char *)(&event->data))[0]? Do you like it? Krzysztof