Call for help regarding anti-aliasing

DSP, Plug-in and Host development discussion.
KVRer
3 posts since 3 May, 2021

Post Mon May 03, 2021 1:49 pm

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.
Hello everyone!

I am a programmer who knows practically nothing about DSP.
I tried to generate some digital sounds.
I thought how hard can it be?
Needless to say, the sounds did not sound right.
I found out that this is due to what you DSP folks call "aliasing".
Actually, I found out that there is a whole science and a whole world out there behind that stuff that I initially approached as "how hard can it be?"
So, now I am in this weird situation where I am trying to find a solution to make my stuff work without knowing enough about the subject.

So, I need the help of some people who are very knowledgeable about DSP in order to understand things. I need to have some long, involved discussions.

I came up with a solution by myself, which currently only works for square waves, and achieves results that are identical to polynomial anti-aliasing (PolyBLEP,) but even if I am to keep working on it and extend it to work for any waveform, I will still need help.

I have prepared a document which contains a few words about myself and what I am looking for. It also contains some audio files, waveforms, and frequency analysis to show how my "empirical" algorithm compares to PolyBLEP.

It can be found here:
https://docs.google.com/document/d/1SMF ... sp=sharing (https://docs.google.com/document/d/1SMFQ3T0F8yHiXNxmq8tEhGMVtuIhMLzOAs-BFiIAQkE/edit?usp=sharing)

If you would be interested in having some discussions with a programmer who is practically ignorant of DSP, to enlighten him about DSP, please respond here, or send me an e-mail. My e-mail address is michael at michael dot gr.

Cheers,
Michael.

KVRist
40 posts since 5 Jul, 2018 from Cambridge, UK

Post Tue May 04, 2021 4:23 am

You said that polynomial anti-aliasing "requires a custom-made algorithm for each type of waveform".

Particular waveforms are often used as examples because they have a small number of features (e.g. a sawtooth contains a single jump, or a triangle wave contains two ramps). But if you have many such features, you just apply similar aliasing-reduction to each of them.

Here's a sketch (roughly) explaining how things like BLEP reduce aliasing - perhaps you can compare this to your scheme, and see if there's some common ground:
poly-bl-illustration-small.png
This illustration includes jumps and ramps, but you can extend this to any other features you want.
You do not have the required permissions to view the files attached to this post.
Last edited by signalsmith on Tue May 04, 2021 8:22 am, edited 1 time in total.

KVRAF
6309 posts since 12 Feb, 2006 from Helsinki, Finland

Post Tue May 04, 2021 4:54 am

It is possible to write (quite efficient) BLEP-code (whether polynomial or otherwise) that takes an arbitrary array of piecewise polynomial segments up to some fixed order. You can do things like let the user edit cubic-splines in a graphical editor and then play them back as BLEP-waveforms just fine.

The basic idea is that your oscillator keeps track of the index of the current segment, then when incrementing the phase check whether you reached the end point of the current segment. If this is the case, then you solve all the non-zero derivatives for both the current segment and the next segment at the transition point, subtract the two to get the BLEP gains, insert the relevant BLEPs into the output buffer, then increment the segment index and repeat (in case the frequency is high enough that you skipped whole segments within a single sample) until the phase is within the current segment.

If you only have a small fixed set of waveforms, then hard-coding allows you to optimize stuff like only computing the discontinuities and derivatives that are known to be non-zero for this particular waveform, but other than that the performance hit of a well-designed fully general BLEP oscillator is a lot less than you'd think.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

KVRer

Topic Starter

3 posts since 3 May, 2021

Post Tue May 04, 2021 11:23 am

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.
signalsmith wrote:
Tue May 04, 2021 4:23 am
...
Thank you for your response.
And that infographic looks really good!
Unfortunately, there is some distance between what you are describing and what I understand PolyBLEP is; also, what you are describing does not agree with the PolyBLEP implementation that I have in my hands, either in terms of how the waveform looks, or in terms of what the code does. So, I do not know what to do with it.
(I have this: https://github.com/martinfinke/PolyBLEP (https://github.com/martinfinke/PolyBLEP) discussed here: http://www.martin-finke.de/blog/article ... scillator/ (http://www.martin-finke.de/blog/articles/audio-plugins-018-polyblep-oscillator/) and it simply smoothens the edges using some math which to me is voodoo magic.)

KVRer

Topic Starter

3 posts since 3 May, 2021

Post Tue May 04, 2021 11:48 am

mystran wrote:
Tue May 04, 2021 4:54 am
It is possible to write (quite efficient) BLEP-code (whether polynomial or otherwise) that takes an arbitrary array of piecewise polynomial segments up to some fixed order. You can do things like let the user edit cubic-splines in a graphical editor and then play them back as BLEP-waveforms just fine.
Yes, my algorithm currently only works with straight line segments, but I was just reading up on cubic interpolation, so that's probably going to be the next step after I have solved the aliasing problem.
mystran wrote:
Tue May 04, 2021 4:54 am
solve all the non-zero derivatives for both the current segment and the next segment at the transition point, subtract the two to get the BLEP gains, insert the relevant BLEPs into the output buffer
Well, you are speaking an unknown language to me right there. Even if we assume that I understand what derivatives are, that I can find the non-zero ones, and that I can somehow do that "solve" thing to them, still, I have no idea what you mean by "subtract the two to get the BLEP gains, and insert the relevant BLEPs."
What two?
What are BLEP gains?
Exactly what is the nature of the entities that you are referring to as "the BLEPs"?
How can I tell which ones of them are the "relevant" ones?
Also, I see no mention of BLAMP, but that's also lurking there and needs to be dealt with, no?
mystran wrote:
Tue May 04, 2021 4:54 am
If you only have a small fixed set of waveforms, then hard-coding allows you to optimize stuff like only computing the discontinuities and derivatives that are known to be non-zero for this particular waveform
That's a very interesting insight, thank you!
I did not think of that.
So, is there some sample code somewhere which computes all the "discontinuities and derivatives" indiscriminately, so that it might work with any waveform instead of a limited set of predefined waveforms?

KVRAF
6309 posts since 12 Feb, 2006 from Helsinki, Finland

Post Tue May 04, 2021 12:37 pm

MikeNakis wrote:
Tue May 04, 2021 11:48 am
Well, you are speaking an unknown language to me right there. Even if we assume that I understand what derivatives are, that I can find the non-zero ones, and that I can somehow do that "solve" thing to them, still, I have no idea what you mean by "subtract the two to get the BLEP gains, and insert the relevant BLEPs."
Some amount of math is sort of unavoidable when it comes to DSP: derivatives come from calculus.

A "BLEP" is a band-limited step. If we subtract the naive step, we get just the "BLEP residue". The integral (or "anti-derivative") is sometimes called "BLAMP" and is the difference between a naive and a band-limited unit-change in the first derivative (rate of change). We can also similarly compute BLEPs for higher order derivatives (in theory; numerically it gets more challenging for higher orders, but the first few can be done just fine).

Now, one of the useful properties of a polynomial is that it only has a finite number of non-zero derivatives. For example a constant-function has none, a linear function has one (it's first derivative is a constant function), a quadratic has two (the first derivative is a linear function, which then has a constant derivative), a cubic has three (the first derivative is a quadratic) and so on.

When you jump from one polynomial segment to another, you can solve (using calculus) all the non-zero derivatives (in addition to any actual step) for both segments at the transition point (after solving for the exact transition point) and then compute the difference. This is basically something like a power-series representation of the discontinuity. We can then use these differences (=BLEP gains) to scale the "BLEP residues" that need to be subtracted in order to remove just the aliasing part of the signal.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
KVRian
881 posts since 31 Dec, 2008

Post Tue May 04, 2021 1:46 pm

MikeNakis wrote:
Tue May 04, 2021 11:23 am
signalsmith wrote:
Tue May 04, 2021 4:23 am
...
Unfortunately, there is some distance between what you are describing and what I understand PolyBLEP is; also, what you are describing does not agree with the PolyBLEP implementation that I have in my hands, either in terms of how the waveform looks, or in terms of what the code does. So, I do not know what to do with it.
PolyBLEP typically does it's smoothing only within the two samples before and after the jump (discontinuity). May be thats whats confusing you when you compare it to the graphics above which may appear to do it in more than 2 samples, which indeed is in general what other more heavy BLEP methods work like (say MinBLEP).

Return to “DSP and Plug-in Development”