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
