On Wed, 2013-05-15 at 13:01 -0700, J. Liles wrote:
[...]

>
> You've seen the consequences of these design decisions in Rui's
> response. As extensible and awesome as your design may be on paper,
> the end result is that users get overly fancy, in consistent (and
> probably slow) GUIs that fiddle with parameters through hidden
> channels and have poor accessibility. I think that is a real problem.

Meh, the facility is genuinely useful for certain things.  Like anything
it can be abused, but you can't legislate good programming.

As usual the reality was not a choice between plugins doing the right
thing, or the wrong thing, right now; but a choice between plugins
existing whatsoever or not.  Mailing list bullshit tends to suggest the
former is reality, but it is not.  Reality check: No user would rather
simply not have e.g. the JUCE plugins whatsoever.  Don't like them?
Don't use them.  Nobody loses anything by plugins existing.

As the incentive to do things correctly increases (e.g. hosts doing
fancy things, or not supporting instance access at all like Ingen), then
plugins will move to them.  If separation is better, then real-world
incentive will reflect that, and things will evolve appropriately.  It
won't be the first kludge to die in LV2 land, and it won't be the last.

It is a small problem at this point in evolution, but it's not a design
problem, it is a simple "work that needs doing" problem.

... or, in the case of host authors, not-work that needs doing.  Don't
like it?  Don't implement it.  Plugins that want to work in your host
will then have to adapt.

A custom UI not working is hardly the end of the world anyway.