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

On Sat, 2013-08-17 at 22:00 +0000, Fons Adriaensen 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.

That is what I meant when I mentioned that even free as in beer software
that comes with a disclaimer has to provide a little bit of quality. I
disagree that this is important for those audio apps you mentioned, but
it's important for software that has to do with privacy and security.
Sure, a plugin that has tendencies to kill tweeters should be removed
from repositories, or better, never should be available by a repository,
but as long as such software was released with no ill intend, the
disclaimer is a fair way to mention risks and self-responsibility of the
users.

I completely agree that such software can't be fixed and I'm thinking of
software that is less complicated than fourier synthesis. When I
programmed the C64 I didn't fix the programs I wrote as a beginner, when
I became a good coder, I wrote completely new programs. Being a good
coder does mean that you have to keep it rolling. If you would give me a
C64 today I wouldn't be able to write good software anymore. IOW users
can't become coders, when they aren't willing to program regularly. It
should be ok just to be a user. It even should be ok when some people
give absolutely nothing back to the free software community, our
societies are huge and somebody could take from the software community
and give by e.g. doing the shopping for physically disabled people.

Real live is more than just free software, artists should know this.

Regards,
Ralf

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Aug 18 20:15:02 2013