29 Nov
2007
29 Nov
'07
5:21 a.m.
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