antialiasing by upsampling with poly~ (need more documentation?)
Hi.
I've been looking at antialiasing different waveform oscillators, or results of freq modulation, etc., and I made a realization that I was not able to find any existing documentation about - so it's either not documented, or else included somewhere that I just couldn't find.
I was using upsampling in poly~ to experiment with antialiasing filters in order to try and get an oscillator or a process to be as aliasing free as tri~, saw~, and rect~. I was getting pretty good results at very high up sampling rates such as 16x and more, and then for some reason I tried the same thing without any filtering in the poly~ patch (just upsampling the poly~ that contained a phasor~ with >0.5 square wave generator for example), and lo and behold I was STILL getting good antialiasing results!
I had no idea that poly~ had built-in antialiasing filters, and I'm guessing that there are lots of other people who don't know this because I found no documentation on it. I've scoured the forums in search of antialiasing ideas, and found posts in the last few years where people are still talking about putting antialiasing filters into a poly~ patch, with no mention of the built-in ones.
Then I stumbled on a response to the thread "antialiasing for Fm" from 2012 where Peter McCulloch says, "Poly~ now has built-in high-quality resampling filters, so you get the anti-aliasing filtering on poly~'s output."
This is excellent news, but shouldn't this be in the reference page for poly~, or in the help file or some topic of antialiasing? It took me 12 years to learn about this, and that was really by accident. :-)
So, maybe I'm the only one who didn't know, but here are some screen shots and the patch with poly~ abstraction that I used.
256 times up sampling gives very good results at midi pitch 127 - almost as good as rect~!
16 times up sampling is excellent up to about midi pitch 84, so way better than no antialiasing.
--
IMHO, there should be something about the built-in altialiasing in the poly~ help patch, under the resampling tab or else a new "antialiasing" tab. And it should also be in the reference for poly~ included with the up message description. I would also expect it to be mentioned in the "Filter Tutorial 3: Analog-Style Synthesis" in the part about "The many aliases of digital oscillators", because using tri~, saw~ and rect~ is great, but as soon as you modulate or waveshape, you may generate freqs above nyquist and so need your own antialiasing...
Would love to hear what others think of this.
best,
Tom
i think it is good that the built-in filter is not too promiment, as built-in things have the disadvantage that you do not exactly know what it does (and also because you do not learn anything from using it.)
regarding your attempt to create an antialiased square wave: it is relatively useless to use upsampling for that, you could as well use a lowpassfilter on the waveform at 44 kHz and get the same result.
using filters to bandlimit audio only works when a higher samplingrate is the cause of aliasing, but not for generators.
Thanks for your input, Roman.
But are you saying that you don't think people should learn about the built-in antialiasing filter so that they are forced to make their own redundant one? I don't see how that makes for better learning...
As for lowpass filtering a square wave at 44.1k and getting the same result as upsampling, I suggest that you actually try it and see for yourself. You'll understand that once the waveform has been generated it's too late; the frequencies above the nyquist have already folded down into the below nyquist range, and no amount of filtering can get rid of them...
Which is why waveform generators, shapers or modulators can absolutely benefit from upsampling and filtering. Because if you upsample high enough, you can actually filter out most of the excess spectral content that would have folded down at the original sample rate. It's cpu intensive, but effective.
-Tom
well, actually i might agree with the idea that it could be denoted in the helpfile, but for the opposite reason than you: the resampling filter is ON by default, which means that after the feature had been introduced, poly~ now works different and might break one´s patch. :(
or in other words: i would prefer if it would be OFF by default to give you upwards compatibility. and as a result, it then would also be required (and make more sense) to present it in the helpfile.
from those who know to build custom filters themselves i somehow expect that they read the reference page of the object (where this information is not missing.) helpfiles are never "complete" or perfect.
"You'll understand that once the waveform has been generated it's too late"
...and that is exactly why you need to do it inside the generator already (using methods like minBlep, additive synthesis, or wavetable sets) and not with an unsymetric post filter of unknown properties.
where of course for something with multiple fm/am/pm/pd functions with many operators this quickly gets too complicated and it is never excluded to combine all these methods.
how much CPU does up 256 need compared to rect~? :)
you can probably use a lot of cos~ to make a squarewave with that CPU, far more than required for 12,5 kHz.
Hi Roman.
The objective is not to use oversampling in place of rect~, tri~ and saw~ which do a very good job of antialiasing, but just to demonstrate the efficacy of the antialiasing filters in poly~ by using a square wave as an example. Rect~, tri~ and saw~ are of course WAY more efficient than the upsampling method, with no question ! The use case of the upsampling method is more for modulation synthesis or wave shaping/distortion synthesis or the like which can easily generate frequencies way above nyquist, even if you use antialiased waveforms at the start. So I'm not interested so much in generators as in modifiers. And as you said yourself, band limited waveforms, additive synthesis and wavetable sets apply to generators, and are complicated to the point of not being practical for modulation and wave shaping.
What I want is to be able to develop synthesis any way I like and get rid of as much of the antialiasing as I can as simply as possible - even if it means taking a hit in the cpu department.
To get back to the documentation, which was the point of my original post, I found NO documentation mentioning built-in antialiasing in poly~ , neither in the help, the reference pages, or tutorials on the subject. If I just missed it, and if you can point me to this documentation, please do.
best,
Tom
agreed, their docs can always use more pointers and cross-referenced linkage.
consider submitting your statement here:
IMHO, there should be something about the built-in altialiasing in the poly~ help patch, under the resampling tab or else a new "antialiasing" tab. And it should also be in the reference for poly~ included with the up message description. I would also expect it to be mentioned in the "Filter Tutorial 3: Analog-Style Synthesis" in the part about "The many aliases of digital oscillators", because using tri~, saw~ and rect~ is great, but as soon as you modulate or waveshape, you may generate freqs above nyquist and so need your own antialiasing...
to the support-request form here: https://cycling74.com/support/contact
(or even just email to them... unless maybe a c74 employee answers here that they've seen it, maybe they have)
i've known about poly~ upsampling from 'Examples/gen/gen~.moogladder', built by Pete Dowling. it's one of my favorite filters to use and it highlights how far just a little bit(pun intended) can go when utilizing poly~ for that. it works well.
i wish they'd also make a tutorial on how to upsample and zero-pad nicely in gen~(i've seen Graham Wakefield post examples on forums and discord but would love these various things consolidated into a proper tutorial on the subject). so i can agree with both Roman and Tom here, haha :D
"I found NO documentation mentioning built-in antialiasing in poly~"
you said it would not be mentioned in the reference, but it is:
https://docs.cycling74.com/max8/refpages/poly~#resampling
i for one think it should be off by default (for exmple in case someone misses the notion in the reference ) - and it would be nice to know the exact specs of the filter.
regarding the modulation stuff, this is often a mystery to me anyway how you had to calculate the sidebands, so i usually go by trial and error. the folding at nyquist is quite welcome during these tests, as you can hear what happens, then later you need to remove it of course.
upsampling 256 times is out of the question in practice. you you rather implement polyblep (or something more modern and expensive) in MSP or use additive approaches with, say, 32 poly voices.
the latter has the benefit that you can still modulate anything in it at samplerate, there is no filter runtime delay and nothing one needed to know before in order to execute the amplification values.
it is still quite expensive with 32 voices...
one of the strategies to avoid upsampling is to bandlimit each FM operator individually before they interact. but then you quickly run at another wall.
(did you know that in some DACs an ideal rect wave causes voltage amplitudes of close to +14db? perfect for destroying your tweeters. luckily someone invented the lowpassfilter in 1895)
Thanks @👽It W∆s ∆lienz👽
I wanted to open the discussion up to the whole group, but I will go ahead and take it elsewhere... :-)
--
@ROMAN THILENIUS
This thread was simply about the documentation of poly~ antialiasing filtering, and not a general conversation about antialiasing methods and their effectiveness or efficiency. Maybe you should start a new thread about that if you want. In any case, I will go find another place to make my documentation suggestions where I have more chance of getting a response from cycling74 people.
-Tom