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