29 Nov
2007
29 Nov
'07
8:57 a.m.
On Thu, 2007-11-29 at 09:19 +0000, Krzysztof Foltman wrote:
For that case I think it would be cleaner if the host just splits the
processing period in smaller parts if it needs to fit in more events per
time unit. The plugin doesn't need to worry about it.
The same way the core spec says that a plugin should always fail to
instantiate when a required feature is missing - by returning NULL from
the instantiate() callback. There is no error message passing.
No, that doesn't work. If the event size is 16 it will need to use the 8
free bytes in this event header and 8 bytes in the next one, so the
index needs to be increased by 2, but (16 + 15) >> 4 == 1.
And mine is wrong too. Embarassing. This works:
index += (events[index].size + 23) / 16;
Right, if the event port has the lv2:connectionOptional hint (from the
core spec) the host doesn't need to know about the event extension at
all. So I guess the cleanest way would be to not list the uri-map thing
as a separate lv2:Feature in the RDF data but require that a host that
handles events passes that LV2_Feature to the plugin's instantiate
callback if it is going to connect a non-NULL buffer to any event ports.
--ll
Lars Luthman wrote:
OK, maybe. It's trivial to add a "safe" RDF indicator in a separate
extension and just assume that an event type is not safe if it doesn't
have it.
_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. 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? 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?
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.