Invisible wrote:
> Mike Raiford wrote:
> 
>> According to the book, my thinking was sound. You take an iFFT of the 
>> arbitrary filter, apply a Hamming or Blackmann window to the shifted 
>> and zero-padded filter kernel. Then you execute the filter by 
>> convolution, or FFT convolution. Depending on the size of the filter 
>> kernel you've generated. Bigger means FFT is more advantageous.
>>
>> That's for FIR filters.
> 
> Not quite...
> 
> Let's say you want to build a band-pass filter. It passes 100 Hz 
> unchanged, but it filters out everything else. A "perfect" version of 
> this filter is very simple - and very impossible. Its impulse response 
> would simply by a 100 Hz sinewave extending an infinite distance into 
> the past and into the future.

Right, no way that could ever work.

> It should be completely obvious that no filter real-world filter can 
> possibly react to inputs that haven't happened yet - but that is what 
> this design calls for. (It is a "non-causal filter".)
> 
> Anyway, if you build an FIR by simply taking that infinite sinewave and 
> chopping the ends off to make it finite, you've just truncated the 
> impulse response. And that distorts the frequency response. The longer 
> the IR is, the less the distortion - and the more arithmetic your 
> digital filter is going to have to do when you run it.
> 
> If, instead of just chopping the ends off, you use a Blackmann window... 
> Well, you're multiplying the IR by the window. Multiplication in the 
> time domain is convolution in the frequency domain. The frequency 
> spectrum of a Blackmann window is such that this convolution is 
> essentially a blurring operation. It blurs out the small ripples, 
> without destroying the peak at 100 Hz which we'd like to keep. (It does 
> widen it slightly though.)
> 

Right... once you've chosen the frequencies to pass, you can then obtain 
the impulse response by an iFFT, and applying the window. Depending on 
the number of points the filter's frequency response will be an 
approximation of the desired frequency response.

> Anyway, coming back to general filter design...
> 
> - You figure out what frequency response you want, and how many points 
> you've going to use. (Note that before and after the inverse-FFT, the 
> number of "points" remains the same.)
> 
> - Obviously more points give you more control over the frequency 
> response; you've got more control points to move. It also means less 
> rippling between the centers of those control points.
> 
> - Take your desired frequency response. Take the inverse-FFT. Now 
> multiply that by your chosen windowing function.
> 
> - You now have your filter kernel.
> 
> Notice there's no zero-padding here. (I think you're possibly confused 
> by the guide's suggestion that you can zero-pad the IR before taking an 
> FFT in order to get better frequency resolution so you can see what your 
> filter's "real" frequency response is - this does not exactly match what 
> you originally requested because the IR is finite.)

You'd want to zero pad the kernel for FFT convolution though, right?

> Anyway, you can now "run" the filter in two ways: Take the convolution 
> of the kernel and your signal, or do an FFT-convolution.
> 
> To do an FFT-convolution, you want the filter's frequency response (not 
> its impulse response). Chop your input signal into blocks, zero-pad each 
> block, FFT, multiply, inverse-FFT, overlap consecutive blocks to build 
> an output signal. You're done.
> 
> (It strikes me that if you were trying to do this "real time", the 
> blocking would necessarily add some latency to the system that a 
> convolution implementation wouldn't have...)

Yeah, there would be a bit of latency I would expect.

FWIW, a long time ago I fooled around with an emulation project for the 
MT-32 sound module, which has a resonant low-pass filter.  With a few 
multiplies and a few adds per cycle, it would filter in realtime pretty 
easily. I didn't understand the theory behind it, but the code looked 
deceptively simple... Until I found the code for calculating the 
coefficients. I found the same filter code on Gamedev.net. From the 
looks of it, it's simply a 6-pole Chebyshev filter. The coefficients 
were generated by what appeared to be the z-transform you were 
discussing earlier. The resonance parameter is apparently is how much 
ripple was allowed in the passband. More ripple = bigger spike at the 
cut-off frequency.

Other interesting things about the module itself: It's essentially 
subtractive synthesis combined with PCM samples. Each patch could 
contain up to 4 partials: 2 pairs. Each pair had a ring modulator. If 
one side of the modulator was unconnected (no partial) it would simply 
generate white noise. IIRC, it had a few different waveforms, including 
the PCM "waveform."

-- 
~Mike

Post a reply to this message