29 Nov
2007
29 Nov
'07
10:05 a.m.
Lars Luthman wrote:
It's not just extra pointer, it's also extra outer loop in every plugin,
so the complexity is definitely there.
Are hosts forced to reveal all features that they implement for
instantiate call, or just the ones mentioned by the particular plugin in
RDF?
In theory, passing some features to a plugin despite if they use the
features or not, might require the host to create additional objects,
often unnecessarily. That's not a huge problem though.
Krzysztof
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,
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.