29 Nov
2007
29 Nov
'07
10:18 a.m.
On Thu, 2007-11-29 at 14:03 +0000, Krzysztof Foltman wrote:
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
Lars Luthman wrote:
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. =)
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? 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.