[LAD] "enhanced event port" LV2 extension proposal

Lars Luthman lars.luthman at gmail.com
Thu Nov 29 13:48:39 UTC 2007

On Thu, 2007-11-29 at 13:23 +0000, Krzysztof Foltman wrote:
> Lars Luthman 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.
> Yes. But that makes it impossible to use a fixed size buffer. If we
> already have a fixed size buffer extension, why break it this way?

I just don't like to add complexity to the port buffer struct. Sure,
worrying about one extra pointer may seem silly, but it's yet another
thing that the plugin needs to check. The simpler the better.

A host doesn't necessarily have to allocate one fixed-size memory block
for every plugin event port, it can use one large shared buffer and dole
out portions of it to each input port in each period, changing the
capacity for each port on the fly to fit as many events as it needs to
write to that port in that period. It's not a perfect method but it
might work in most cases.

> > 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.
> Why not use lv2:optionalFeature?

Because it isn't really a separate optional feature, it depends on
whether 1) all event ports have the lv2:connectionOptional hint and 2)
the host doesn't plan to connect to any of those ports.

If there are event ports that are _not_ optional, then the URI map is
definitely required and the plugin should fail to instantiate if it
doesn't get one. In that case it might make sense to list the URI map
feature as a lv2:requiredFeature, although a bit redundant.

If all event ports are optional then the plugin should not fail to
instantiate because it doesn't get a URI map, but if the host then
connects an event port anyway and writes events to it the plugin will
have no idea what to do with them.

You _could_ list the URI map Feature in the RDF data (as an
lv2:optionalFeature if all event ports are lv2:connectionOptional, as an
lv2:requiredFeature if not). I suppose it's just a matter of taste.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20071129/628344da/attachment.pgp>

More information about the Linux-audio-dev mailing list