29 Jan
2005
29 Jan
'05
8:03 p.m.
On Sat, Jan 29, 2005 at 04:56:43PM -0500, Eric Dantan Rzewnicki wrote:
denormals anyone?
Denormals are not so difficult to get rid of, unless you are
a purist and want to preserve every bit of precision that a
float (or double) can give. Normal signal levels are around
unity, and in most cases you are not interested in things below
-300 dB, so just adding 1e-15 at strategic places will do.
Ahha! there. It's decided. I don't need to go
back to school to get a
comp sci degree. Fons said so. ;)
Not so fast young man :-) Formal education is seldom wasted. In comp
sci courses you will learn interesting things such as discrete
maths, graph algorithms and complexity analysis. I was commenting
on a growing breed of IT specialists who know everything about 'patterns'
and methodology but will not recognise a two's complement negative number
if they stumble over it. I know, as I have to interview them when they
apply for a job at ASP.
Are there some bodies of knowledge in published works
that are more
appropriate for the would be linux audio developer than other texts
intended for the general programmer?
Everything related to the topics I listed before. Even if a book,paper
or whatever is not directly applicable to what you want to do, and even
if you don't understand everything in it, you will pick up things and
remember them. It's a slow process in the beginning, but one that will
reach a critical mass at some point.
For algorithms in general, Donald Knuth's series 'The Art of Computer
Programming' is still my bible. Don't be put off by the low-level style
of programming used in these books, you're learning _algorithms_, not a
language. In general, a lot of books on algorithms published in the 80's
and 90's are much more interesting that today's focus on methodology
and tools.
Currently I'm reading the linux-audio-dev archives
... I'm learning, but
it's slow since the discussions between Paul Davis, David Olofson,
Jaroslav, Benno, etc., etc. from back in 1999 include them working out
what these design patterns would be. I can see hints of elements of
ladspa and jack and dssi and alsa that evolved over the past 6 years and
it's very interesting to me to read these discussions. But, at the rate
I'm going I'll never catch up to the current state of affairs without
quiting my day job and devoting myself full time to this study. I would
love to do that, but it just ain't practical.
What you are doing is probably very useful, and you _will_ catch up.
At some point, you will start writing things, and from that point
everything will go faster. And you don't need to learn everything
before you start writing.
There are lots of things you can just use before you fully understand
how they work, and that is even the very reason why they exist (and doing
so is part of software engineering in general, and something you need to
learn).
Using JACK is not difficult, nor is writing a LADSPA plugin if you
have some examples. You will bite the dust a number of times, but
that's a fast way of learning, in particular if there is a friendly
list to help you back on your feet when required.
I've read K&R and Harbison and Steele ... so I
have a decent grasp of
the syntax of C. I use python and bash at work and at home, so I'm
beginning to learn a little bit of how to program. But, I don't know
where to go to learn "linux audio development".
As I said, it's a mix of disciplines, not something you can learn as
a single package.
I'm pretty sure that many of the authors active in LAD started of
in a similar way, and in fact, so did I. My formal training
is in music, maths and audio engineering, no IT or programming at
all. At some point I switched my career from audio engineering to
computers and electronics. I was lucky and dropped right from
the start into real-time and multithreading stuff. As for Linux,
I'm a newbie - two years next week.
--
FA