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.

On Feb 11, 2008 12:17 PM, Roger Dannenberg <rbd@cs.cmu.edu> wrote:

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.

NEXT TOPIC:

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.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________

Audacity-nyquist mailing list

Audacity-nyquist@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/audacity-nyquist

--

Steve Morris

barbershopsteve@gmail.com

Bass: Unnamed quintet

Bass: Sounds Of Concord