Re: [LAD] How to develop guis for LV2?

On Fri, 2009-11-06 at 12:08 +0100, fons@email-addr-hidden 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 6 20:15:01 2009