1 Nov
2009
1 Nov
'09
1:55 p.m.
On Sun, 2009-11-01 at 12:24 -0400, Paul Davis wrote:
On Sun, Nov 1, 2009 at 12:14 PM, David Robillard
<dave(a)drobilla.net> wrote:
Meh, I don't think that's true at all. All of this stuff is not a
barrier to anyone actually doing the work at all. Honestly, be
realistic. What kind of developer on a mission to get ramped control
ports sits down to solve the problem and goes OH GOD THERE'S NO W3C
STANDARDS BODY TO SUBMIT TO THAT WILL FOLD THIS EXTENSION INTO SOME KIND
OF META STANDARD WITH A FANCY NAME THEREFORE MY EFFORTS ARE WASTED!
Please ;)
These developers DO come along and they DO do things. Stefano, who is
also participating in this discussion, is a good example. He showed up
a little while ago on a mission to get dynamic plugin discovery working,
things were discussed on the list as necessary, and things got done.
Reality. Notice the common theme around here of people who havn't
actually looked into doing anything at all like to scream endlessley
about these supposed problems, but everyone who actually /has/ either
doesn't participate at all, or actively disagrees? It's not a
coincidence, because these problems are completely fictitious.
On Sat, 2009-10-31 at 23:38 -0400, Paul Davis
wrote:
specifically *not* the entire extension ecosystem.
subsets of the ecosystem that can be named, referenced, referred to,
*developed against* by plugin/host authors, with some expectations.
when you give examples from the web, i think there is an interesting
lesson there. people with an interest in extending "html" in some way
(e.g. embedded svg, theora, whatever) know what the path is: develop
the technology/specs/etc, get some initial implementations, push
toward w3c ... adoption by w3c (if you're lucky).
a similar path exists for LV2 except for the last part. you can argue
that its the cart before the horse - develop the stuff first, then
lets argue about how its to be part of a named "ensemble" or
"standard" or whatever. but i would contend that part of the reason
for a reluctance to develop (which you pointedly referenced) is the
lack of any clue what happens *after* that. you know, its great that
LV2 lets anyone and their mom define a cool new way to do ramped
plugin parameter control. but so what? how is that of any interest to
someone who wants to figure out, not just a technical solution to the
issue, but an accepted, in-use engineering solution? if the pathway to
the second part isn't clear, the first part is less likely to get
done. On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
[ ... stuff .... ]
the idea occured to me sometime today.
"my host supports LV2-E1"
"my plugin requires LV2-E2"
"this application uses LV2-E<N>"
EV<N> = LV2 core + { extA, extB, extC .. }
Trying to put the entire "extension ecosystem" on a linear scale is
definitely completely impossible. with LADSPA, it was very easy to motivate discussions
about design
changes
And even easier for them to go nowhere at all...
- there was one header, and it got into the header,
or it
didn't.
Which in reality, after the initial one is out, means it didn't, ever.
Use LADSPA if you think that plan is so fantastic. It's no coincidence
that it's a complete and utter joke power-wise compared to all of its
competition.
its similarly easy, when necessary, to do the same for
JACK -
once again, there is one header, one API and something is either in
or out, or modified. LV2's glorious anarchy means that there is no
social necessity for any convergent effort at all.
Of course there is, multiple extensions for the same thing really sucks
for everybody involved. That is the social necessity. If you think
some kind of fascist design dictatorship of LV2 solves this better than
evolution, I direct you to Linus' recently famous comments on lkml about
this one ;)
You say it's easier to modify Jack and LADSPA than LV2. This is so
wrong it hurts. How do you add functionality to LADSPA? You fight
endlessly on this list and nothing gets done. It's happened countless
times before. How do you do it for LV2? YOU JUST DO IT! It is
provably easier, because the actual task is the same, except there is no
bureaucratic overhead.
If you really wish to argue this point, then I will present a simple
challenge: design and implement ramped control ports for LADSPA, and I
will do so for LV2. The winner is whoever gets it working and
implemented without breaking any standard - that is, gets it working in
the real world. You would obviously be insane to accept this challenge,
because actually improving LADSPA is so insanely hard it's basically
impossible, and there is no barrier whatsoever to actually improving
LV2. I'd be done by the time you even get a reply to your first email
about it in the ensuing never-ending discussion that goes nowhere. Your
assumption is so false as to be almost completely backwards. LV2 is,
literally, a LADSPA that has been minimally modified so it can actually
be improved easily. That's the whole point.
people can do
whatever the hell they want (good!) and nobody else need care (bad!).
You can't dictate care. People care because they need the features.
Duh.
ok, so people don't agree yet on how to do plugin
API feature X ...
then we need a mechanism that does more to force us to actually come
up with solutions. LV2 doesn't do anything to force this, possibly by
design.
How exactly do you propose to force people to solve these problems?
Come over to my house and put a gun to my head?
You can hint that ways of "forcing" everyone to conform to some gigantic
arbitrary specification is needed all you like, but the reality that LV2
actually exists and is useful and gets better all the time proves you to
be wrong. Bad solutions to imagined problems using common fallacies
(appeal to (non-existent) authority).
its no suprise, therefore, that people who might feel
a
pressing need for this or that don't do anything about it, because its
not actually clear to them that it will be a "solution" at all.
Clearly false. Why isn't it clear? There's obvious hooks for you to
implement new functionality, many examples of how to do so, and - hey -
if you do it, you can get the whole thing really actually working,
without having to piss away all your time arguing on mailing lists about
something that doesn't even exist yet. Again you're painting reality
with a completely inverted brush - it's clear with LV2 that your
solution will be an actual solution, because you can actually get it
working and deploy it in the real world - guaranteed. Is this clear
with LADSPA? Hardly. The situation is pretty much the exact opposite -
it's not really worth it spending the effort to try and extend LADSPA,
because everyone is going to disagree anyway, your efforts will never
hit the real world, and it won't be a solution. Trying to extend LADSPA
is a complete waste of time in the real world, and trying to extend LV2
is not. No sense in even bothering to argue otherwise, since the former
does not happen, and the latter does all the time. Might as well argue
the sky isn't blue.
-dr