Oversampling with poly~

Sep 15, 2009 at 11:04am

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

#45453
Sep 15, 2009 at 1:43pm

just found these vb.objects maybe the [mxj vb.chebycoeff] would do well.

#163877
Sep 15, 2009 at 2:06pm

actually i just tried vb.cheby~ which seems to do the trick nicely!

ta,

oli

#163878
Sep 16, 2009 at 10:59am

cascade~ provides a steeper slope.

It would be nice if uncle ’74 could introduce a specific antialiasing low-pass filter object for this purpose.

#163879
Sep 16, 2009 at 3:25pm

as soon as you work in higher than 48 khz sr, you´ll get in
trouble with all of these filters.

#163880
Sep 16, 2009 at 3:29pm
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?

#163881
Sep 16, 2009 at 3:45pm

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

http://www.cycling74.com/forums/index.php?t=msg&goto=180996&rid=5063&S=4110fed8e0e4a662d541fedf0af558b2#msg_180996

Smile

#163882
Sep 16, 2009 at 4:03pm
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

#163883
Sep 16, 2009 at 7:32pm
oli larkin wrote on Wed, 16 September 2009 10:03
Quote:
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

#163884
Sep 16, 2009 at 7:38pm
Mike S wrote on Wed, 16 September 2009 17:45
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

Smile

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.

.

#163885
Sep 16, 2009 at 7:45pm

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

#163886
Sep 16, 2009 at 10:38pm

wait wait…

#163887
Sep 16, 2009 at 10:57pm

Ok it looks like (to be cynical) you’re both wrong Very Happy
Note that the aliasing at 44.1—>44.1 is a “flaw” from cycle~ not from our downsampling algorithms

#163888
Sep 16, 2009 at 11:14pm
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

#163889
Sep 17, 2009 at 1:57am

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

.

#163890
Sep 17, 2009 at 9:40pm

oooooooohhh…..

#163891
Sep 18, 2009 at 1:27pm
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”

http://www-crca.ucsd.edu/~msp/techniques/latest/book-html/node194.html

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

#163892
Sep 18, 2009 at 2:16pm

Hi,

do you know the Miller Puckette Pd Raw Filter Pack, ported to Max/Msp by Barry Threw ?

Could be useful…

http://www.barrythrew.com/2008/03/28/maxmsp-raw-filter-pack/

All the best

Alessandro Fogar

#163893
Sep 18, 2009 at 8:37pm
Matthew Aidekman wrote on Thu, 17 September 2009 23:40
oooooooohhh…..

you will get your dinner.

i was talking to [cycle~].

-110

#163894
Jun 8, 2010 at 10:27pm

here you go…

Attachments:
  1. oversampling.zip
#163897

You must be logged in to reply to this topic.