Re: [LAU] Linux Audio podcast. episode003: commenting replies

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Fons Adriaensen <fons@...>
Cc: linux-audio-user <linux-audio-user@...>
Date: Sunday, August 18, 2013 - 2:29 am

--001a11c2047aa00c3904e42f9795
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 17, 2013 at 3:00 PM, Fons Adriaensen wrote:

> On Fri, Aug 16, 2013 at 09:53:13AM -0700, J. Liles wrote:

I completely agree. But I really think this is a more general problem. Most
plugins are crap. That's a fact. LADSPA, LV2, VST, AU, whatever. Most of
them are ununique, incomplete, poorly thought out, devoid of QA, etc. I
think it would be generous to say that 10% of plugins are useful. But since
when are we talking about plugins?

There are a few reasons for this:

1) they are easy to write.
2) they never die.
3) users often can't tell the difference between a good one and a bad one
(not being a jerk here--but it's not like people are doing rigorous ABX
testing on this stuff. You add a shiny Calf plugin to a mix and you think
it makes a difference. Half the time it could be a no-op or badly degrade
the sound an and few people would notice the difference).

The reason for #2 is that for some reason nobody writes about or reviews
them in any meaningful way (no frequency analysis, denormal testing, CPU
load figures, etc.) and each individual user has to go through and discover
which ones are usable and which ones aren't. The other part of the problem
is that (at least LADSPA) plugins are distributed in huge batches, all
together in one .so with say 5 usable plugins and 30 that either do
nothing, crash the host, or make horrible tweater destroying noises. This
prevents distros from e.g. filtering out the crap plugins based on package
installation stats.

It's so bad that I've considered just doing an audit myself and repackaging
the say 20 LADSPA plugins that are of any use--but being lumped together in
an .so with a bunch of crap makes this a pain. Perhaps a community run wiki
review/rating/whitelist system would be more effective (users could choose
to only use 2+ star plugins or whatnot).

There's a whole different problem of branding/marketing and the
misconception that there are even enough unique DSP tasks that anyone would
require 100s of plugins. The truth is, anyone only needs a handful of basic
plugins: the rest is permutations.

But I don't think this discussion was ever really about hardcore DSP
programming. 90% of applications is user interface. And anybody can learn
anything. Everybody starts somehwere. As charming as it may be to think of
you this way, Fons, I doubt that even you were born already being a DSP
guru.

--001a11c2047aa00c3904e42f9795
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=
On Sat, Aug 17, 2013 at 3:00 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Fri, Aug 16, 2013 at 09=
:53:13AM -0700, J. Liles wrote:

> 4) Do it your own damn self. I'm dead serious here. This is

This is also how we get EQ plugins that

* reduce you S/N to 50 dB or less when given LF input,
* become unstable for some settings of the controls,
=C2=A0 or when you move them too fast (good way to blow up
=C2=A0 your tweeters),
* display a graphical frequency response which is not
=C2=A0 the actual one, in some cases not even close,

and dynamic processors that

* claim an attack time of less than a millisecond but
=C2=A0 are insensitive to much slower variations in level,
* are completely unusable if you care a bit about signal
=C2=A0 quality,

and autotuners that massacre your signal, and all sorts
of processors with controls that are usable over less
than five percent of their range and/or produce massive
thumps when moved, etc. etc.

These are not 'bugs' that can be put right by a few
patches. This is would-be developers who do know just
enough about programming to modify some example code,
but little or nothing about audio nor DSP, and who
naively implement some equations from a textbook (in
the best case) or some web page (in most cases) without
even a hint of understanding what it does. This is why
at least 70% of all LADSPA plugins ever developed are
completely useless.

Sure, not all programming is DSP, and for most 'big'
audio-related apps the DSP parts may just be a tiny
fraction of the code. But in many cases the same
careless attitude is prevalent when developing the
non-DSP parts.

One-liners are usually little more than peptalk
promoted by the prevailing topdogs, and I tend to
ignore them. But there is one that is IHMO very
wrong, and that's the popular 'release early'
(and often). Please don't. Make at least sure your
stuff works. Test it. Measure it. On nice aspect
of free software development is that you can work
without company policies, quality and marketing
departments, and supervisors looking over your
shoulder. Which in the end means that you, the
developer, and only you, have to assume your
responsability.I completely agree. But I r=
eally think this is a more general problem. Most plugins are crap. That&#39=
;s a fact. LADSPA, LV2, VST, AU, whatever. Most of them are ununique, incom=
plete, poorly thought out, devoid of QA, etc. I think it would be generous =
to say that 10% of plugins are useful. But since when are we talking about =
plugins?
There are a few reasons for this:1) they =
are easy to write.2) they never die.3) users =
often can't tell the difference between a good one and a bad one (not b=
eing a jerk here--but it's not like people are doing rigorous ABX testi=
ng on this stuff. You add a shiny Calf plugin to a mix and you think it mak=
es a difference. Half the time it could be a no-op or badly degrade the sou=
nd an and few people would notice the difference).
The reason for #2 is that for some reason nobody =
writes about or reviews them in any meaningful way (no frequency analysis, =
denormal testing, CPU load figures, etc.) and each individual user has to g=
o through and discover which ones are usable and which ones aren't. The=
other part of the problem is that (at least LADSPA) plugins are distribute=
d in huge batches, all together in one .so with say 5 usable plugins and 30=
that either do nothing, crash the host, or make horrible tweater destroyin=
g noises. This prevents distros from e.g. filtering out the crap plugins ba=
sed on package installation stats.
It's so bad that I've considered just doing an audit=
myself and repackaging the say 20 LADSPA plugins that are of any use--but =
being lumped together in an .so with a bunch of crap makes this a pain. Per=
haps a community run wiki review/rating/whitelist system would be more effe=
ctive (users could choose to only use 2+ star plugins or whatnot).
There's a whole different problem of branding/marketing =
and the misconception that there are even enough unique DSP tasks that anyo=
ne would require 100s of plugins. The truth is, anyone only needs a handful=
of basic plugins: the rest is permutations.
But I don't think this discussion was ever re=
ally about hardcore DSP programming. 90% of applications is user interface.=
And anybody can learn anything. Everybody starts somehwere. As charming as=
it may be to think of you this way, Fons, I doubt that even you were born =
already being a DSP guru.

--001a11c2047aa00c3904e42f9795--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] Linux Audio podcast. episode003: commenting replies, Louigi Verona, (Thu Aug 15, 11:23 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Leonardo Palomares, (Fri Aug 16, 5:58 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sat Aug 17, 10:00 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, J. Liles, (Sun Aug 18, 2:29 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sun Aug 18, 11:25 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Harry van Haaren, (Thu Aug 15, 11:42 am)