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

Dan Mills <dmills@email-addr-hidden> writes:
> Now here is the trick, we convert that to a unique identifier at run
> time by registering each unique event URI as a string in some data
> structure (Map, linked list of parameters, whatever), then at event
> creation time we set the pointer to point to our single common instance
> of the URI. Now all events of a given type have the same value stored in
> that pointer which will serve as a unique ID for this event for run of
> the programme. If saving event data to disk, we just replace the pointer
> with the string it pointed to.
>
> struct event_t {
> char * uri;
> size_t data_length;
> char data[1]
> };
>
> On loading a set of events build a list of every unique uri and patch
> each events uri pointer to point to it.

I somewhat like the idea, but how would this work for a host dispatching
opaque/unknown events? Maybe such host would load plugin event type uris
From RDF and just use them in opaque way. However, I dont see benefits
over the uri-map approach proposed in the other subthread. using uri map
indexes looks quite more cleaner and intuitive to me than assuming uri
pointers are constant. IMHO later can be quite confisung for not that
experienced plugin writters.

> struct known_events {
> char *uri;
> int (*handler)(struct event_t * ev, void *param);
> struct known_events *next;
> }

I don't get why this handler callback is needed at all. In LV2 such
events are supposed to be processed during run().

It is worth to discuss how host dispatching opaque events will notify
already instantiated plugins about new event type introduced by loading
new plugin.

-- 
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