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

On Wed, 2007-11-28 at 16:45 +0000, Krzysztof Foltman wrote: _Any_ structure that isn't just a dumb array of bytes will be unsafe to move between machines because of endianness. If the host doesn't know exactly what the internal structure of the event buffer is it can't do anything like that (unless it has a serialisation callback like in your object event proposal) and if it does it can, so having a separate flag for that is probably redundant. OK, so what we have now is something like this: 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 }; A pointer to an Event_Port_Buffer is passed to connect_port() for every event port etc. And in the RDF file for the plugin there would be something like this: <http://myplugin.example.com> a lv2:Plugin; lv2:requiredFeature <http://lv2.example.com/midi-event-type>; lv2:port [ a lv2:InputPort, <http://lv2.example.com/event-port>; ... ]; ... 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. 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). 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: Event_Port_Buffer* buf = ports[EVENT_PORT]; uint32_t index; uint32_t next_frame; uint32_t frames_done = 0 while (index < buf->used_size) { next_frame = events[index].timestamp >> 16; render_audio(frames_done, next_frame); frames_done = next_frame; handle_event(events[index]); index += 1 + (events[index].size - 8) / 16; } render_audio(frames_done, nframes); 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. Does anyone else see any other problems with this type of event port? Steve, Dave, Nedko? --ll