On Thu, 2007-11-29 at 09:19 +0000, Krzysztof Foltman wrote: > 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.
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. > > 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? 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 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? 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. > > handle_event(events[index]); > > index += 1 + (events[index].size - 8) / 16; > > index += (events[index].size + 15) >> 4; > > right? 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; > > 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. 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev