>>Yes... I'm currently building a realtime Java IIR filter system which will 
>>hopefully let me filter arbitrary sounds and see what happens... [This is 
>>assuming it ever works!]
> 
> 
> Oh nice, you could do a nice z-plane-GUI to position the poles and zeros
> in Realtime, too =)

Yeah, something like that. ;-)

In my lunch break at work, I built a little thing out of Tcl then allows 
you to pick pole and zero coordinates, and then launches GNUplot and 
graphs it for you. :-D (Sadly, GNUplot itself can't create filters with 
an arbitrary number of poles because there's no looping capabilities.)

It could then also spit out the IIR coeficients, and even get GNUplot to 
graph the impulse and frequency responce. (Again, GNUplot can't run the 
filter to get the impulse responce because that requires looping. As 
would doing an FFT. So Tcl does that and writes it to file, than GNUplot 
graphs it.)

I'm currently attempting to do the same thing with Java...


Another advantage of IIRs over FIRs is that you can *change* the 
frequency responce quickly and easily - just gotta change a handful of 
coeficients. (An FIR would require an entire FFT step for this!) Plus 
they can emulate the old analogue synthesiser sound. (All analogue 
filters are IIRs!)

In fact, IIRs are *so* fast that it's quicker to take a pure sawtooth 
tone and IIR filter it down than it is to calculate half a dozen sine 
waves from the Fourier series and add them all together... [Well, in 
trueth, there will be come crossover point at which one becomes better 
than the other. But I wouldn't think it would take too long to reach!]

> another possible way would be to write a VST-plugin in C, and use it
> with a VST-Host-application. Tha advantage is, that you can focus on the
> audiofilter part of the code, the disadvantage that you need a host-
> application to use the plugin.

Much bigger problem: that would require C. ;-)

>>Indeed. It looks so complicated, but it's really so simple... I love it 
>>when that happens in mathematics! ;-)
> 
> 
> yes, me too :)
> some time ago i had the idea to use the deconvolution idea (that is also
> described a bit in the 'dspguide') to undo the blur in photos that is
> the result from jiggling the camera during the exposure. I think if you
> knew the motion of the camera you could guess a blurring filterkernel
> from that, which can emulate the camwiggling. now just use to deconvolution
> on the blurred image with that filterkernel and perhaps you can regain
> most of it's original sharpness back (that is, what the noise didn't eat..)

...and the ADC quantinization noise, and the JPEG compression. ;-)

You could probably *improve* the image significantly. However, if the 
original convolution actually _eliminated_ any frequencies, you aren't 
going to get them back, no matter /how/ high the gain. Deconvolution is 
effectively passing the signal through a filter who's frequency responce 
is the reciprocol of the first one - and taking the reciprocol of zero 
isn't wise. ;-)

>>From FIRs we know that longer impulse responce = better. So you would 
>>imagine that an *infinite* impulse responce would be the best! :-D
>>
>>But, alas, feedback can only create certain waveforms. In particular, the 
>>impulse responce for a "perfect" low-pass filter would be an infinite sinc 
>>function - basically a sine wave that decays as the reciprocol of time. 
>>Using IIRs, I can make a sine wave that decays *exponentially* with 
>>time... which is close... but not *quite* the same...
> 
> 
> ah, thanks for the explanation. That sounds like an interesting
> optimization-task to tune the IIR-coefficients though i fear someone
> has already done this before me..

As I said, it's all down to pole-zero plots. (The incredible thing is 
that somebody figured out that if you take the problem and put it 
through the Laplace transform, it becomes very much simpler!)

> Another book which i really like is
>   'Digital Filters' from R.W. Hamming, Dover Publications
> it's also a small introductory book, which is a bit more focused on the
> math behind it than the dspguide, but still gets the ideas across in a
> great way so that it's directly applicable on realworld-problems.
> If you don't know it already have a look at it.

Thanks for the tip.

Post a reply to this message