Lars Luthman <[EMAIL PROTECTED]> 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>
pgpoyJHUMAEGa.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev