Re: [LAD] "enhanced event port" LV2 extension proposal

On Thu, 2007-11-29 at 14:03 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > 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,
>
> What about plugin-to-host communication, then? Before getting the events
> from the host we set the capacity to maximum, and after the plugin
> returns, we just reuse the part that wasn't used by the plugin for other
> events?

It's up to the host I suppose. If you pass the maximum capacity you get
maximum flexibility, but also risk that a greedy plugin fills your
entire buffer with 12412 MIDI CC's per audio frame. But at some point I
guess you just have to assume that plugin writers aren't going to be
maliciously stupid. =)

> >> 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.
>
> Are hosts forced to reveal all features that they implement for
> instantiate call, or just the ones mentioned by the particular plugin in
> RDF?

According to the core spec, hosts are only required to pass the features
to a plugin that the plugin lists as required in its RDF data. In
practice many hosts will probably keep one static feature array with all
the features they supports that they pass to every plugin instance but
it's not necessary.

If we decide that plugins with event ports do _not_ have to list the URI
map thing as an optional or required feature but still pass the
LV2_Feature struct to the plugin at instantiation that's OK too - that's
what extensions are for, extending and modifying the core spec.

--ll

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev