[LAD] "enhanced event port" LV2 extension proposal
wdev at foltman.com
Wed Dec 5 16:34:50 UTC 2007
Lars Luthman wrote:
> The difference is not in the number of lines but in how many new
> functions and types are used.
I think the cost-benefit ratio is important here. The added complexity
may be worth it for me, but perhaps not for you.
I hope we're still at pretty low complexity level, but that is a very
> If a plugin supports an event type (I assume that's what you meant) it
> can list it in its RDF file, and then the host can map it and that
> plugin will get an ID for that event type URI,
The point is, how a previously loaded plugin (a transparent bridge or
something) will be informed about the new type? In most cases it would
work, though. It's just that "old" loaded plugins will not know the
mapping for "new" types, which might be OK for many applications. Not
that I think it's a good solution, just an acceptable one.
We can ignore the issue for now, but maybe it should be picked up later
at some point, when deciding about runtime extensibility.
Question to Dave, do you see any way to "invalidate" a particular RDF
triplet, then announce another one? say: PluginX is no longer a
ReverbPlugin, PluginX is now a FilterPlugin. Or port 4 is no longer the
plugin X's port. It's unrelated to our current discussion, I know.
Perhaps some kind of "rdf triplet" event type, that would carry
information about "knowledge update", if you know what I mean? Not
timestamped, perhaps :)
> Sure. It's just on instantiation. If you wanted to be smart you could
> have the host sort the array and pass the size as well and let the
> plugin do binary searches.
So it would have to be an array of pairs (uri, number), right? Because
otherwise adding any new number will mess up the numbering.
More information about the Linux-audio-dev