ODP: Filters

[Ethan Duni]

>i would! i built something similar (no filters yet though), except it really
>was
>additive i.e. no ifft. and definitely not real time. so there's no problem
>with 
>harmonics not becoming "harmonic". the filter contour just affects the gain
>of 
>each harmonic, so adding a filter becomes just a simple multiplication per 
>harmonic. 

-the harmonic distortion i was referring to wasn't in the filter.. it
actually comes up more when you are trying to pitch-shift some signal with
an FFT.  if you just shift the whole spectrum up by a given amount the
harmonic relationships in the signal can get distorted.  e.g., say you have
some signal that is 100Hz + 200Hz.  now you FFT it and shift it by 50Hz.
now you have 150Hz and 250Hz; uh oh! so much for that second harmonic.. not
really a complicated problem, and if you are doing purely additive synthesis
(i.e., just filling a frequency-domain array from scratch), it's easy enough
to avoid, but i thought i'd mention it anyway.. 

>the main problem with the FFT-based implementation is, afaik, that each
>"window"
>of the FFT don't have a 1:1 correspondence to frequency. i.e.: at 44.1KHZ,
>if 
>you take a sample of 512 samples, then each sample corresponds to approx. 43
>HZ 
>(iirc) and I THINK it is linear?? can't remember for sure. increasing the
>window
>size helps, but for each band you are increasing/decreasing a frequency
>RANGE 
>and not a frequency per se - i guess this is why you have the "harmonic" 
>problems? 

-isn't it 86Hz per frequency-domain data point at 44.1KHz with 512 samples
(half of the frequencies being negative- meaning above the nyquist
frequency)?  and yeah, i think it is linear.  this also brings up the issue
of frequency resolution vs. time resolution.  you need bigger windows to get
better frequency accuracy, but in doing so you can only define the
frequencies over the period of the window.  i've seen the Heisenberg
Uncertainty Principle applied to this problem to show that delta t times
delta f is greater than or equal to the inverse of (i think) 4 pi.  this is
all to say that you can only define frequency exactly over infinite time and
as you approach instantaneity (smaller and smaller time intervals), your
frequency resolution goes to hell.  This all is a bummer for music
applications because of course we'd like our sounds to be very fluid and
dynamic, but this screws the accuracy of the frequencies in the transform..
there are some advanced and sneaky workarounds for this, but i'm not really
familiar with them.. anyone?

>note that I'm not real familiar 
>with the iFFT math (it's simpler than FFT math, right?) 

-i think that computationally it's very similar.. 

>but doing it as
>straight
>sines can be very precise, allowing specific detuning, etc. (which is
>included 
>in the program I wrote) phase doesn't matter at this point, although I did 
>include it :) also, given some memory it can be very fast. you can use a
>kind of
>"phase accumulator" (at least this is what I though you guys meant when you
>were
>first talking about it) where you divide 2pi by the number of samples per
>cycle 
>(yes, this can be a fraction) giving you the increment to phase, which is
>then 
>fed into a sine function (there are several ways to speed this up, i think,
>one 
>way is lookup tables, but there are many others - you can trade accuracy for
>
>speed here if desired). one more multiplication per harmonic gives you
>filter, 
>just like the FFT version. i don't know if it's simpler or more complex, but
>
>it's different.

-that's an interesting approach.. i'd speculate that this would be more
efficient for the case of smaller numbers of constituent frequencies, but
i'd think an ifft would be better for more complicated stuff.. you'd
acutally need more than one multiplication per harmonic for the filter; the
frequency response of the filter could be achieved this way, but with the
FFT method you are using an array of complex numbers that represents  both
the frequency and phase response of the filter in question (although if you
are looking to implement a perfectly phase-distortion-free filter, this
isn't a problem :])

>a preview of the (dos) version of this program is at 
>http://members.xoom.com/elev8. it's early and is a VERY simple additive
>synth 
>with no filters. i wrote it to send basic waveforms to my prophet 3000
>sampler, 
>which has nice cem3387 analog filters....
>
>anyway, i plan to add modulations (envs, lfos, etc), a formant filter which
>will
>have several models that are mathematically pure as well as a user-definable
>
>X-band graphic EQ. as well as other waveforms for the additive engine (this 
>won't work for the formant filter, at the moment). the k5000 formant filter
>is a
>128-band graphic EQ. an FFT-based system might work better here, since
>that's 
>kind of what it is, for non-sinewave base waveform. 

-uh-oh, we're dangerously close to wavelet analysis here :]  
and isn't the k5000's formant filter FFT-based (or rather iFFT; i'm not sure
the data has ever left the frequency domain at that point)? 

>but maybe an FFT-type 
>analyzer might give me a good harmonic list here, which I could use to add 
>together instead.. anyway this is heavy into additive. although they are
>very 
>related.

-you know, i like this idea.. i'm thinking that, from an oscillator point of
view, having arbitrary basis functions (perhaps even different functions for
a given harmonic?) would let you produce a wider variety of waveforms, and
then use an FFT-style filter after the fact (hey, the filter won't know you
cheated and didn't start with sines).  though at this point, i'm seriously
wondering if moving the whole thing into a Wavelet Transform based system
wouldn't work better to this end.. guess i'll have to go learn more about
them.. 

>one more advantage of this is that I plan to have FM-style feedback loops 
>available as well i.e. in addition to the envelopes for each harmonic, the 
>harmonics themselves can be used as modulation sources, which could modulate
>
>volume of other harmonics for instance or pitch (FM) of another harmonic.
>i'm 
>planning to allow phase mod too for those casio CZ-style patches :) 

-another good idea.