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

Lars Luthman <lars.luthman@email-addr-hidden> writes:

> struct Event_Port_Buffer {
> uint32_t capacity; // number of elements in the array
> uint32_t used_size; // number of _used_ elements
> uint32_t event_count; // number of events (different from
> // used_size if there are large events -
> // would this really be needed?)
> struct Event* events; // an array allocated by the host
> };
>
> struct Event {
> uint32_t timestamp;
> uint16_t size;
> uint16_t event_type;
> uint8_t data[8]; // or a union or whatever, as long
> // as it's 8 bytes
> };

snip

> Should plugins have to list <http://lv2.example.com/uri-map> as a
> required feature, or should that be implicit whenever a plugin has an
> event port? Both methods have some drawbacks - if plugins are required
> to list it there is some redundancy, if they are not we have a required
> feature that isn't listed as one which can be a bit confusing.

I think uri-map feature should be part of event extension itself. what
would be use without it?

I think using untyped 8 byte array instead of union is more appropriate,
we can map those 8 bytes to whethever is needed based on type
uri. However, the "needs additional marshaling" flag is good thing
imho. this can include endian swaping, and dereferencing external
objects. It would be appropriate to have marshaling feature lv2
extension in future (for cross machine events). Since value of this
"flag" is known at compile/deploy stage, there is no need it to be
runtime variable. Having it specified in RDF is the way to go.

Also, i doubt we need three "count" members in Event_Port_Buffer
structure. used_size - number of used events is perfectly fine by
itself. I dont see why plugin should know whether buffer is actually
larger.

Is midi event type semantics a broad or narrow one? I'd prefer narrow
one, i.e. one type for note on/offs, one for pitch bend, and for midi
cc, etc. Reasoning behind this is to indicate to user (informational) or
maybe to host for runtime optimizations too, that only certain types of
midi events will be actually processed. Read this as "lv2zynadd does not
respond to MIDI CC events" (zynjacku however maps (will) those to actual
parameter changes, through separate ports).

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev