Hi folks.

This took a supprisingly long time to render... not entirely sure why. 
The mosiac preview was fast enough; I guess it's just AA slowing it down.

Anyway, the (z-domain) transfer function for a 2-pole notch-reject filter...

Post a reply to this message

Attachments:
Download 'z1.jpg' (45 KB)

Preview of image 'z1.jpg'

"Orchid XP v2" <voi### [at] devnull> schrieb im Newsbeitrag 
news:42ff1a86@news.povray.org...
> Hi folks.
>
> This took a supprisingly long time to render... not entirely sure why.
> The mosiac preview was fast enough; I guess it's just AA slowing it down.
>
> Anyway, the (z-domain) transfer function for a 2-pole notch-reject 
> filter...


Cool, i like filter design and this stuff, though i'm still at FIR-filters
and haven't played with z-transforms yet.
How does it sound? :)

Thies

Post a reply to this message

> Cool, i like filter design and this stuff, though i'm still at FIR-filters
> and haven't played with z-transforms yet.
> How does it sound? :)

With a fixed cutoff frequency... almost inaudable. But if you *sweep* 
the cutoff frequency, it sounds mostly like a phaser.

FIR filters are much easier to design, and can give a more exact 
frequency responce.

IIR filters are harder to design, and don't give quite such exact 
frequency characteristics... but they run *much* faster! (For example, 
the above filter requires 5 multiplies and 4 additions per sample to 
filter a signal. A 5-point FIR couldn't possibly produce such a narrow 
reject band.)

Anyway, I learned everything I know here:
http://www.dspguide.com/

Enjoy. ;-)

Post a reply to this message

"Orchid XP v2" <voi### [at] devnull> schrieb im Newsbeitrag 
news:42ff2459$1@news.povray.org...
>> Cool, i like filter design and this stuff, though i'm still at 
>> FIR-filters
>> and haven't played with z-transforms yet.
>> 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

> 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.

> IIR filters are harder to design, and don't give quite such exact 
> frequency characteristics... but they run *much* faster! (For example, the 
> above filter requires 5 multiplies and 4 additions per sample to filter a 
> signal. A 5-point FIR couldn't possibly produce such a narrow reject 
> band.)

yes, the feedback-idea behind IIRs is cool. i have to learn more about
that some time.

> 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
> Enjoy. ;-)
Thanks, i have :)


i just had an idea for your picture, i think it would be nice to
have circles around the origin of the complex plane, especially
the unitcircle, that would be useful for stability analysis, etc..
(you probably know more about that than i). and perhaps radial rays
so that you can see the angle. or briefly said: i think polar coords.
would be more useful than rectangular coordinates

Thies

Post a reply to this message

>>>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!]

>>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! ;-)

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"... :-/  ]

>>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...

(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...

> 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...


[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

Orchid XP v2 nous apporta ses lumieres en ce 2005-08-14 06:18:
> Hi folks.
> 
> This took a supprisingly long time to render... not entirely sure why. 
> The mosiac preview was fast enough; I guess it's just AA slowing it down.
> 
> Anyway, the (z-domain) transfer function for a 2-pole notch-reject 
> filter...
> 
> ------------------------------------------------------------------------
> 
Isosurface with prety big gradients = slow.

Alain

Post a reply to this message

>> This took a supprisingly long time to render... not entirely sure why. 
>>
> Isosurface with prety big gradients = slow.

Well, yes... POV-Ray wanted me to use max_gradient 2860 or something. 
But I actually used 120, which seems to work perfectly. (Clearly the 
steepest part of the function is nowhere near the surface...)

I imagine the poles create the high gradient...

(Note that this is actually the *logarithm* of the transfer function, if 
you want to be technical about it.)

Post a reply to this message

"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

>>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

"Orchid XP v2" <voi### [at] devnull> schrieb im Newsbeitrag 
news:42ff61ca$1@news.povray.org...
>>>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...

a realtime update of the impulse- and freq.response would be very cool.
Be sure to post someting in p.o-t about it, when you've made progress


> 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!)

that's definately a good argument to use them in virtual analog 
synthesizers.
i wonder if we would choose the FIR-sound as more 'natural' if analog
filters sounded like FIRs or if it's really because we sense the sound
itself as more pleasing to the ear..


> 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!]

that brings us to additive synthesis. I remember there actually was a
hardwaresynth that took this approach and could generate the first 64
harmonics in realtime AFAIR and control each harmonic with it's own
envelope but apparently it sounded not too different or special to get
wide attention. I think the main problem was that it's not easy to
make an easy interface to control so many oscs in parallel in a way
that gives interesting results. Without noise to spice it up it
sounded rather sterile.

>>>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. ;-)

yeah, that's the problem. I think i should just try it to see if
the zeros in the freq-response of a realworldcase render deconvolution
useless or not.


>>>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!)

yes, the laplace transform is really a cool idea.
Take a differential equation and get an algebraic equation in return,
it's always great to find such unexpected relations in math.
where would we be now without all those 17th/18th century
mathematicians...? :D

Post a reply to this message