sample-at-a-time processing and Nyquist/XLISP Backtrace

Email lists > Developing Nyquist plug-ins for Audacity

Thread: sample-at-a-time processing and Nyquist/XLISP Backtrace

Search this list only Search all lists
sample-at-a-time processing and Nyquist/XLISP Backtrace
United States	2008-02-11 11:17:42
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-nyquistlists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/audaci ty-nyquist

Re: sample-at-a-time processing and Nyquist/XLISP Backtrace
	2008-02-11 12:04:42

>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. On Feb 11, 2008 12:17 PM, Roger Dannenberg < rbdcs.cmu.edu">rbdcs.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-nyquistlists.sourceforge.net">Audacity-nyquistlists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/audacity-nyquist -- Steve Morris barbershopstevegmail.com">barbershopstevegmail.com Bass: Unnamed quintet Bass: Sounds Of Concord

[1-2]

about | contact Other archives ( Real Estate discussion Medical topics )

Mailing lists