[LAD] "enhanced event port" LV2 extension proposal
lars.luthman at gmail.com
Wed Nov 28 16:19:55 UTC 2007
On Wed, 2007-11-28 at 15:56 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > I guess my point was that I think this should be part of the semantics
> > of the particular event type that needs it.
> Well, making the common part common (for all "large" events) doesn't
> hurt. And it can potentially make stuff easier for transparent bridging
> over the network (when each "large" type implements an interface for
Sure, but you don't need it to be defined in the event transport
specification itself. There's nothing that says that different
lv2:Features (event types in this case) can't share code and binary
interfaces - the IDataBuffer could be defined in a separate file that is
not part of the actual event transport extension but used by all event
types that need it. Even if a simple host that only wants to deal with
MIDI can completely ignore the IDataBuffer part of the event transport
specification it still makes it _look_ more complicated and adds
potential confusion - I think it's better to have it outside the basic
> Serialization is necessary because "large" events can potentially refer
> to some "foreign" objects, like handles to OpenGL textures in video
> memory and what not :) You cannot assume that all of your "large" event
> data will be conveniently placed in a single contiguous buffer in RAM,
> because it might not be the most practical way of dealing with them.
No argument with any of this. Passing around reference counted opaque
objects can certainly be useful and I can imagine lots of sexy
applications, I just don't think it needs to be in the event transport
specification when it works just as well outside it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Linux-audio-dev