Oversampling with poly~
here's a patch to demo oversampling using poly~. Im using a 3 pole LP butterworth filter from jamoma @ 15khz but i'd like to replace it with something more portable. Does anyone have any tips for what filter to use for this task?
cheers,
oli
just found these vb.objects maybe the [mxj vb.chebycoeff] would do well.
actually i just tried vb.cheby~ which seems to do the trick nicely!
ta,
oli
cascade~ provides a steeper slope.
It would be nice if uncle '74 could introduce a specific antialiasing low-pass filter object for this purpose.
as soon as you work in higher than 48 khz sr, you´ll get in
trouble with all of these filters.
Quote:as soon as you work in higher than 48 khz sr, you´ll get in
trouble with all of these filters.
could you elaborate?
no, roman's style is condescension
i imagine he'll probably tell you to google it, or perhaps offer an explanation if you're lucky
-110
edit - would quite like your input on a little mod of your patch
Quote:edit - would quite like your input on a little mod of your patch
i tried your patch, i didn't know about cross~ thanks! The helpfile doesn't mention what filter it uses, but i guess it's something like a butterworth or linkwitz riley. Need to do some comparisons.
by the way, my patch was strictly for demoing the idea of oversampling. I think that you would probably want to try more efficient solutions, especially on a polyphonic synth, although it depends on your computer power and how much else is going on.
With this thread i was hoping someone with some knowledge of filter theorem might join in and say you want a third order butterworth like object X for this purpose because ... Suppose i should just go and read JOS or something.
oli
oli larkin wrote on Wed, 16 September 2009 10:03Quote:edit - would quite like your input on a little mod of your patch
Suppose i should just go and read JOS or something.
For anti-aliasing when resampling JOS and co use a windowed sinc interpolation which does both the interpolation and the filtering at once. The sinc function is a perfect brick wall, but is infinite, so windowing it makes it an FIR - you window with a Kaiser window - and the filter length, alpha value for the Kaiser window and sampling of the sinc function combine to give cutoff freq, slope and rejection band attenuation.
I recently made a (fairly expensive) buffer playback object to avoid aliasing with high playback speeds. I think in this case however you could use a fixed FIR filter though that would perform pretty well and be much less expensive, and implement with buffir~. I have an external that calculates the windowed sinc function somewhere I think. If you want remind me about it and I'll send it in your direction....
Regards,
Alex
Mike S wrote on Wed, 16 September 2009 17:45no, roman's style is condescension
i imagine he'll probably tell you to google it, or perhaps offer an explanation if you're lucky
-110
edit - would quite like your input on a little mod of your patch
i simply exspect to be asked at least three times before i will.
-111
edit: sorry i didnt mean to ignore that one. will answer here
now, the other thread is too f*cked up.
.
official answer - part I
there is one main error in all of these examples.
by using a pole/zere or FIR filter you will do something to the
upsampled signal which is completely unwanted, those filters will
filter also between the output samples.
i wish i had a patch or a link to a good graphic on the net which
demonstrates it but i dont have one.
lets try it with text.
imagine a 4*upsampled generator which produces 12 samples:
4 5 6 7 4 5 2 2 1 0 0 3
we now want to go out of our poly~ test up 4, i.e. downsample /4.
if we dont do anything, poly~ will output this:
4 4 1
the effect of generating the signal at 368 kHz is zero here -
except in a situation where there are more than one nonlinear
signal processes inside (for example a cycle~ running through a
comb~ - then you will still have a slightly more accurate result
compared to not-upsampled.)
now, what happens if we use biquad?
4 5 6 7 4 5 2 2 1 0 0 3
anyone who can explain why we should be biquadding the 7 with the 4 gets a free beer!
for an antialiasing filter we should make sure that the samples are
only filtered in groups of 4, not _between the output samples.
so that
4 5 6 7, 4 5 2 2, 1 0 0 3
will end up as 3 samples which represent the upsampled signal as accurate as possible.
if you do that by simply taking the mean of them
5.5, 3.25, 2.
you are closer to the original *4 signal compared to the
4, 4, 1
you´ll get otherwise from poly~.
of course "4 5 2 2" is an extreme example - a musical signal probably looks
more like this:
0.992 0.98 0.971 0.944, ...
official answer - part II
there is absolutely no reason to remove >nyquist content from the _upsampled
signal. _if you want to use such filters as a quick and dirty solution then
you do it _outside the poly.
-110
wait wait...
Ok it looks like (to be cynical) you're both wrong
Note that the aliasing at 44.1--->44.1 is a "flaw" from cycle~ not from our downsampling algorithms
Roman Thilenius wrote on Wed, 16 September 2009 13:45
official answer - part I
there is one main error in all of these examples.
by using a pole/zere or FIR filter you will do something to the
upsampled signal which is completely unwanted, those filters will
filter also between the output samples.
I think that is the point - you PRE-filter the signal to remove content that will alias, then a simple drop sample method will work fine to give you a lower sample rate version.
I don't really understand what you're going on about in your post. The method you describe is unfamiliar to me. The method of low-pass filtering a signal before downsampling with a drop sample technique is theoretically sound and will work.
So what's the problem? Can you provide any more detailed reference to what you're suggesting, or is it your own technique?
Regards,
Alex
haha matthew, maybe we´re not all wrong, maybe we´re all right!
the method i proposed is required in another context btw, not
for the usual 88 to 44 conversion, i have lost the track a bit.
the method alex describes (FIR inside sinc) is the industry standard
and works, the point i was trying to make was only that using biquad
is not exactly the same.
so so, cycle~. again. to bed with no dinner.
-110
.
oooooooohhh.....
Quote:official answer - part II
there is absolutely no reason to remove >nyquist content from the _upsampled
signal. _if you want to use such filters as a quick and dirty solution then
you do it _outside the poly.
i think you're wrong here, although I didn't understand part I either. From Miller Puckette's Book:
"As a first line of defense against foldover, we can synthesize the waveform at a much higher sample rate, apply a low-pass filter whose cutoff frequency is set to the Nyquist frequency (for the original sample rate), then down-sample"
if you down sample and then filter, you get bad aliasing, see attached patch.
Alex -- I be quite interested in the external you mentioned
oli
Hi,
do you know the Miller Puckette Pd Raw Filter Pack, ported to Max/Msp by Barry Threw ?
Could be useful...
All the best
Alessandro Fogar
Matthew Aidekman wrote on Thu, 17 September 2009 23:40oooooooohhh.....
you will get your dinner.
i was talking to [cycle~].
-110