"Orchid XP v2" <voi### [at] devnull> schrieb im Newsbeitrag 
news:42ff3fac$1@news.povray.org...
>>>>How does it sound? :)
>>>
>>>With a fixed cutoff frequency... almost inaudable. But if you *sweep* the 
>>>cutoff frequency, it sounds mostly like a phaser.
>>
>>
>> Nice, i like to 'explore' a sound with filters like that, afterwards
>> it's easier to identify the different sources from which the sound is 
>> built
>
> 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 =)
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.


>>>FIR filters are much easier to design, and can give a more exact 
>>>frequency responce.
>>
>> i especially was stunned by the idea that you can make up an arbitrary
>> freq.-response and get the corresponding filter-kernel by FFT-ing it.
>
> 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..)


> Of course, the numbers you put into an inverse FFT are for frequency 
> *bands*. So while the whole band is guaranteed to total up to the number 
> you demand, individual frequencies within that band might be above or 
> below the requested gain... herein lies the complexity of designing FIRs. 
> It's not as simple as it looks. ;-)
>
> [Of course, usually the answer is just "use more points"... :-/  ]

the power of brute force :D


>>>IIR filters are harder to design, and don't give quite such exact 
>>>frequency characteristics... but they run *much* faster!
>>
>> yes, the feedback-idea behind IIRs is cool. i have to learn more about
>> that some time.
>
> 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..

> (Close enough that a 5-pole Butterworth IIR filter utterly kicks bottom 
> compared to any 5-point FIR you could design. But different enough that a 
> very big FIR filter works better, if you have the CPU power.)
>
>>>Anyway, I learned everything I know here:
>>>http://www.dspguide.com/
>>
>>
>> i know this book, it's a real gem, i have never seen the basics of
>> convolution, fft, etc. explained clearer than in this one
>
> I have played with the FFT a lot. This book explains *why* it does some of 
> the strange things it does...

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.

>> or briefly said: i think polar coords.
>> would be more useful than rectangular coordinates
>
> Yes, you're exactly right.
>
> I only used grid cordinates because it looks cooler. ;-)
> Now, if this were the s-domain...
hehe ;)

> [Side note: Actually, if you take away the gridlines, it's quite hard to 
> see the zero next to the front pole. It just looks like a patch of shadow 
> that shouldn't exist. With the gridlines there, you can see that it's 
> actually a dip in the surface.]

Post a reply to this message