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

On Fri, Nov 06, 2009 at 10:55:17AM -0500, David Robillard wrote:

> How could changing the rules about how anything references ports be done
> as an extension?

By doing it the new way if the extension is requested,
and the old way otherwise.
 
> ... What extensions are in conflict? FUD FUD FUD

Can you name two LAD members with the same birthday ?
Probably not, but if you put 23 of them in a room the
chances are 50% there will be two. At the moment there
are few extensions, so probably there's no conflict.
 
> > 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.

Doesn't it ? If a host has to consider all active
extensions as a whole then the number of possible
combinations explodes. If it considers them one by
one, doing what is required for extension A could
easily have an impact on extension B, if both are
about similer things, e.g. ports. For this reason
a host author could decide to do first B then A, if
that solves his problem. At the same time a plugin
author could assume (even without been aware of
this) that the order has to be A then B.
 
> > 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.

Prove it.

> Even in
> this overwhelmingly unlikely case, if conflicting extensions existed it
> simply would not make sense to implement them both in a single plugin.

The whole idea of a plugin system is that host and plugins can be
developed separately. This requires that all parts of the API,
*including their possible interactions and dependencies* are
either well-defined, or guaranteed by design not to interfere
with each other.

> > 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.

Right.

> Nobody says you have to do anything.

That's valid for anything in FOSS. Still I'm doing things.

> You not wanting to do stuff is certainly is not an argument
> against LV2.

Having one potential plugin author less means a (small) impact
on its acceptance. It's not a technical argument, that's true.

> > ...
> > 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 :)

I don't hate it. I just remember the complete chaos that
resulted from uncoordinated ad-hoc extensions to HTML, before
the mess was more or less cleaned up.

> > 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.

I'd rather not. And this has nothing to do with ease of
development, or overhead in the sense that I takes more
of my time. My opinion would not change even if a perfect
SDK would hide all the dirty details and overhead.
The final result is what should be no be more complex
than required.

> > , 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?

I wouldn't require them otherwise.

> 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".

The extreme case of this is what I proposed in my Q2 earlier.
That object could take over the complete API, and in many
cases that would be the simplest solution.

> 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.

Ciao,

-- 
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev