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

On Thu, 2007-11-29 at 05:59 +0200, Nedko Arnaudov wrote:
> 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?

Shared data structures? Maybe even things inside events themselves (ie
the type of various message arguments).

I think a URI<->int mapping mechanism will probably be very useful in
several places, since it's the only way of getting URI extensibility
with DSP appropriate performance. Doesn't hurt to keep it separate
anyway, it's not really event specific at all.

-DR-

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 30 04:15:02 2007