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

Lars Luthman wrote:

> _Any_ structure that isn't just a dumb array of bytes will be unsafe to
> move between machines because of endianness.

A bridge can compare the architectures of the bridged machines, and
refuse to continue if they're different.

That kind of bridge could be written by a well trained chimpanzee and
work for (perhaps) majority of cases. Of course, to work for *all*
cases, the serialization would be needed.

Also, if the buffer is "simple" (as in: no pointers or handles
whatsoever), the serialization doesn't need to be implemented or invoked! :)

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

I would argue for additional Event_Port_Buffer pointer, as in "next".
This way, the host could allocate event buffers in (say) fixed-size
chunks, and the buffer is too full, another is allocated and linked to
previous one. What do you think?

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

So we agree on that one.

> The host won't instantiate the plugin unless it knows how to handle
> event ports and MIDI events, and the plugin will fail to instantiate
> unless the host passes a URI -> integer map to instantiate using a
> LV2_Feature with the URI <http://lv2.example.com/uri-map> and a
> NULL-terminated array of event type URIs as data.

How will it fail? (how will the host be notified about failure?) Is
there any way to communicate the reason for the failure to the user?

Just asking.

> The integer associated
> to each URI is simply the array index (my earlier suggestion was just a
> brain dump from a thought-in-progress, a simple array seems a lot
> cleaner).

A NULL-terminated array is good.

> Assuming that the host only supports MIDI events the data passed for
> this feature will be { "http://lv2.example.com/midi-event-type", NULL },
> the plugin will store the index 0 as the MIDI event identifier somewhere
> in its state, and everything is good to go. A basic loop for processing
> input events in a plugin could look something like this:

Looks good!

> handle_event(events[index]);
> index += 1 + (events[index].size - 8) / 16;

index += (events[index].size + 15) >> 4;

right?

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

I guess, sometimes the event port isn't *required* to be connected?
Depends on a plugin, I guess. MIDI arpeggiator will need event support,
so will a synthesizer, but a reverb with MIDI support might do without
the event port support.

Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 12:15:04 2007