>From a practical point of view Roger is absolutely right about filters with and without FFTs but my physics and DSP background prevents me from letting it pass without a clarification about the theory.
Don't blame the math. All of the common linear filters can be represented in a mathematically equivalent form using FFTs. That means if you do it right you should get the same results. The artifacts usually come from using intuition to invent filters in FFT (spectra) space rather than going back to filter theory and doing the math. FFT space has its quirks and intuition seldom helps work with them. Also the FFT solution is usually slower for a variety of reasons. The latency is also longer because you often need more data points before you can calculate. latency is not usually not a problem for Audacity filters because doing anything real time like pitch tracking or something.
The only real reason to use an FFT is because it is so general. The same tool can implement a large variety of filters. In one of my previous lives we used FFT's heavily for filtering (and taking derivatives and lots of other math you wouldn't have guessed could be done with Fourier transforms.) We did it because the application already required a high performance FFT box which was figuratively glued onto the side of the CPU. It was worth the investment in understanding how to translate algorithms to FFT space because the result was usually much faster. Besides in the spectrometer world there is always some math geek around who hasn't forgotten complex analysis that you can recruit to do the heavy lifting.
Responding to some recent messages about sample-at-a-time processing and
filters, it's a common misconception that the proper way to filter a
signal is to take FFTs, manipulate the signal in the frequency domain,
and inverse FFT back to a signal. This often leads to artifacts and poor
quality. Nyquist has a lot of built-in IIR filters that can be used
individually or in combination.
You can also process samples in XLISP. I tried to give some helpful
guidance in the manual at the end of the "More Examples" chapter in the
section "DSP in Lisp". If anyone wants to offer better text or tell me
what was confusing, I'd be happy to expand or correct the text.
I agree the XLISP backtrace is kind of confusing, but it's really pretty
simple: the backtrace is just info from the runtime stack, starting with
the most recently called function and working backward. Each function is
printed in two parts: The heading "Function: " precedes the name of the
function, and the heading "Arguments:" heads a list of arguments passed
to the function. The function is usually something like
#<Closure-REVERB-MONO: #45ba50>, but you can probably guess that this
means a call to the function declared as REVERB-MONO. The arguments are
printed one per line, but in many cases, lines wrap, so it takes some
careful reading to parse them.
The backtrace is made uglier by the fact that functions like COND, LET,
and SETF all appear. The arguments to these functions are lists that get
interpreted as code. So often, you'll see lots of code in the backtrace.
This can actually help figure out exactly how you reached the error, but
again, it can take some careful reading to interpret this.
I find the backtrace facility indispensable, so if you are ignoring it
because it looks too ugly, probably you should take a closer look.
In any case, you'll be happy to hear that SAL has much prettier
backtraces with line numbers and argument names; maybe we'll get that
into Audacity before too long.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Audacity-nyquist mailing list