On Fri, 2009-11-06 at 12:08 +0100, fons(a)kokkinizita.net wrote:
On Thu, Nov 05, 2009 at 06:21:03PM -0500, David
Robillard wrote:
Something about how things refer to ports had to
be clarified/changed in
the core spec. Unfortunate, but them's the ropes. Extremely unlikely
that something similar happens again (since there isn't much in the core
spec to change in the first place).
(having read your other post wich outlines the technicalities)
This could have been done as an extension. I agree that would
have created some chaos, so changing the core spec was probably
a wise choice.
How could changing the rules about how anything references ports be done
as an extension?
The point of the change is that referring to indices makes things break.
It has to be defined in the core to prevent this. It is associated with
versioning. There are the sort of (very few) things that are, and must
be, defined in the core. It is not so much a breakage specific to the
GUI extension as an oversight that has now been resolved.
But that's the point: this can happen at any time
with extensions. If you have N extensions, how big is the chance
that not any subset of S <= N of them will not be in conflict
somehow ?
... What extensions are in conflict? FUD FUD FUD
Or depend on things that are specified nowhere, such
as the order in which a host should use them and call any new
extension specific functions in the plugin ?
This doesn't really make any sense.
What mechanism is
there in LV2's core spec that ensures that extensions will be
orthogonal to each other, even if written by authors who don't
know each other's work, and evaluated by a host in unspecified
order ?
This also makes no sense. It might be possible to deliberately
construct a really, really, really cracked out extension that would
somehow be in "conflict" with another, but I can't even come up with
such a case. I'd say the chance of this happening with extensions that
aren't deliberately written to do this is extremely close to 0. Even in
this overwhelmingly unlikely case, if conflicting extensions existed it
simply would not make sense to implement them both in a single plugin.
Big deal.
Maybe if you can come up with an example of such "conflicting"
extensions...
Nobody has to
"accept" anything.
I'm not going to spend even a minute writing a plugin or
a set of them, requiring maybe five new extensions, if I'm
not absolutely sure that these extensions will be accepted
(that is: implemented) by the authors of the major host
programs, e.g. Ardour. And don't ask me to do that myself.
It would take ages for me to get familiar enough with e.g.
Ardour's internal structures and code to be able to do that.
And even then, the patches would still have to be accepted
by Ardour's core team. And that's only _one_ host, be it an
important one.
Fine then, don't. Nobody says you have to do anything. You not wanting
to do stuff is certainly is not an argument against LV2.
Currently I'm designing a rather large app that
will rely
a lot on plugins. It will have at least three incompatible
types of them. By incompatible I mean that if the types are
A,B,C, it would be completely pointless to try and insert
e.g. a B where an A is expected and so on. All of them
require _embedded_ GUIs, to the point that a user will
not even be aware that some parts of the app are plugins.
Some of them require quite complex interaction with the
core of the app, not just a set of audio and traditional
control values. Type A could probably be used outside the
app as well, if you strip some its features, for the others
the chances that they can be re-used as plugins are zero.
Should I try and use LV2 for all of this ?
Lucky for you, because of the extension mechanism you ironically seem to
hate, you can :)
It would create
a lot of extra complexity, starting with having to squeeze
everything through a C interface while both sides are C++,
(see below)
a lot of textual representation of fixed things just
adding
overhead
This is true, but the benefits are substantial, it's not "just" adding
overhead. Extensions could be invented to avoid (most of) the text part
entirely, but that's a lot of work for little gain. I'd rather just
deal with that overhead as it comes up.
, and a collection of extensions that I'm pretty
sure no other host will ever implement.
What would these extensions be? And would they be mandatory for the
plugins working whatsoever?
So the answer is
no, unless I missed something.
All this is pretty much the cost of using a generic plugin mechanism.
If you want them to work elsewhere, then yes, you should. Otherwise,
they won't. If these needed extensions are absolutely necessary for the
plugins to be in any way useful, and very non-generic and not likely to
be implemented elsewhere, then the plugins are inherently not useful in
general, LV2 or no LV2. This is pretty unlikely though.
There are much simpler solutions available. If I
define each
of A,B,C as a C++ base class then any .so that provides a
factory for a derived class of any of them is a plugin. And
that's it. Of course this could mean issues with C++ binary
compatibility, but in this case, given that most of this
will never be used elsewhere anyway and distributed as a
single package, I accept those.
You can use C++ in an extension if you like. Such an extension would be
trivial, e.g. "the extension_data method on a plugin, called with this
URI, returns an object of this type". Might piss off some of the pure C
people, but whatever. It's better to have LV2 plugins that (can) work
in any C++ host than no plugins that work elsewhere at all.
That said, it's certainly better to use C if possible...
-dr