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

On Fri, 2009-11-06 at 18:27 +0100, fons@email-addr-hidden wrote:
> 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.

This would not solve the problem because hosts need to follow the rules
too. The core spec obviously has to specify things like how to refer to
ports correctly. There are a small number of things that need to be
defined in the core spec for obvious reasons, this is one of them.

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

This presumes that extensions "conflicting" makes sense, or is likely to
happen.

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

Why? Says who? Example?

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

I don't know what this "order" stuff means at all. Extensions don't
have an order.

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

Extensions are usually either new port types, which can't conflict with
anything, or newly added functions, which can't conflict with anything
either.

The only kind of extension that could "conflict" is what that redefines
the semantics of something very fundamental in the core spec, which is
silly, and again, even if such an extension existed, it doesn't matter,
because that one particular weird extension might not make sense with
such and such a host/plugins/extension/whatever. So? If it's
fundamentally incapable of working in some setup, then it won't.

You are making the outrageous claim, the burden of proof is on you.
  
> > 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.

Again, what interactions and dependencies? You're waving your hands
around screaming about "conflict" with no example or argument to suggest
such conflict is likely or even possible.

Is isn't, and furthermore, if it did happen it's not a big dealer, and
furtherfurthermore, the community would take care of this anyway (why
would anyone do this without a good reason? and if they did, why would
anyone implement it?)

Here is an actual example of the sort of way extensions might
"conflict": Extension A says the block size passed to the process method
must be always 1. Extension B says the block size passed to the process
method must be always 512. These extensions "conflict". So what? You
can't do both on the same plugin, obviously. The things they describe
inherently "conflict". This is simply not a problem.

If you think it is a problem, then come up with an example for why. I
can't think of one.

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

Maybe, and everyone would like as many plugins as possible, but you
don't have any concrete reasons. I'd love to address your concerns, but
you don't have any actual concerns. One can not make a patch for FUD.

Why should you even care if this "conflicting" thing is possible anyway?
Will it affect your plugins? Obviously not, you couldn't implement
"conflicting" extensions on a single set of plugins anyway, by
definition.

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

A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my shared library analogy
from earlier.

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

Having the data separate from the code is pretty much "required" to get
all the things we want anyway. Is it more complex than is "required"?
Maybe. It depends how you feel like conveniently defining "complex".
Having an equivalently powerful data model defined in the code somehow
is hardly free either. A vague notion of "complex" doesn't really
matter much when there are tangible advantages/disadvantages to take
into consideration.

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

A lot of functionality can be implemented such that the plugin works
without it. You don't /have/ to "require" them.

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

This wouldn't be an LV2 plugin at all.

-dr

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