[LAU] Linux Audio podcast. episode003: commenting replies

J. Liles malnourite at gmail.com
Sun Aug 18 02:29:25 UTC 2013

On Sat, Aug 17, 2013 at 3:00 PM, Fons Adriaensen <fons at 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
> > how users become developers.
> 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,
>   or when you move them too fast (good way to blow up
>   your tweeters),
> * display a graphical frequency response which is not
>   the actual one, in some cases not even close,
> and dynamic processors that
> * claim an attack time of less than a millisecond but
>   are insensitive to much slower variations in level,
> * are completely unusable if you care a bit about signal
>   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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20130817/d2ff9e10/attachment.html>

More information about the Linux-audio-user mailing list