polyBLEP Martin Finke library

[elanhickler]

This code is a little bloated and lacks negative frequency and phase modulation support.

Also, it lacks hard sync which requires some explanation to implement.

It also does not implement a more important form of polyBLEP which allows fixing of ANY discontinuity thereby allowing antialiasing of all forms of modulation (I think). Tale suggested having a 2-sample delay on the signal to do polyBLEP on hard sync, and I think, maybe you need a 2-sample-delay for arbitrary waveform antialiasing.

Here's a PDF for implementing antialiasing of arbitrary signals (I think): http://dafx16.vutbr.cz/dafxpapers/18-DAFx-16_paper_33-PN.pdf

Here's a discussion on REAPER forum about PolyBLEP: https://forum.cockos.com/showthread.php?t=108288

Here's a discussion on hard sync: https://www.kvraudio.com/forum/viewtopic.php?p=5944009

Here's more in depth explanation of such antialiasing techniques: https://www.yofiel.com/software/cycling-74-patches/antialiased-oscillators#yToc-2

I'm asking if I could pay Tale to implement arbitrary waveform polyBLEP antialiasing because my oscilloscope music algorithms can have a lot of ugly discontinuities and oversampling + anti-aliasing filter only helps so much. If we could antialias arbitrary waveforms, that would be so amazing.

PolyBLEP is the perfect way to antialias waveforms in my opinion. This is because it does not have gibbs, it has just nice soft curves, yet at low frequency you get sharp waveforms and at high frequency you start to get a transition to sinewave. I think having a perfect fourier series waveform (with gibbs) is musically unecessary, not useful, and just creates extra high frequencies that no one needs. PolyBLEP waveforms sound warm, more analog, I think.

There's some neat tricks I learned about antialiasing as well.

PolyBLEP supports oscillator frequencies pretty perfectly up to frequencies of 3/12 samplerate. Once you pass that mark, you start getting significant transition to sinewave up to 4/12 sr. Once you hit 4/12 * sr frequency it would be better to crossfade to a sinewave, the only issue is that you start losing amplitude around that time so you need to somehow compensate, rather than hard switch to sinewave.

One important key to this: At EXACTLY 4/12*sr frequency, you will see all aliasing artifacts/harmonics converge to a single point, and that is why transition to sinewave exactly at that frequency is desirable, because you basically have a sinewave right then and there.

[RobinSchmidt]

yes, i have just grabbed it for later reference and perhaps comparison, when i implement such things myself

PolyBLEP supports oscillator frequencies pretty perfectly up to frequencies of 3/12samplerate

3/12 = 1/4, right? so, with 2x oversampling, we should be pretty much set? ...which is a reasonable factor to use anyway for various other reasons. i have to look at the paper(s)...

[RobinSchmidt]

i once implemented a full MinBLEP based on this paper (i guess, it counts as a classic today):

https://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

but this is sooo long ago (somewhere in the legacy code) - and yes, it has ringing (although, only post-ringing, since it's a MinBlep, not just a blep - or LinBlep (for linear-phase), as they are sometimes called). ...however, these new and shorter transition functions seem more practical

[elanhickler]

no longer relevant

[RobinSchmidt]

this thread: https://www.kvraudio.com/forum/viewtopic.php?p=5944009 is actually still very relevant. i guess, i have just figured out myself what mystran mentions as alternative implementation at the bottom of his first reply. i may look into the partial-sample stepping approach later as well. ... i have saved the link.

at first, i totally underestimated the complexity of handling the resets properly. i expected it to be simple and was boldly trying to implement a driver with two-way sync completely with waveform generation and blep. it turned out, that even just handling the phasors for one-way sync properly is actually quite tricky indeed and i had to take a step back and figure out that first...also, at some point, we may want to support negative frequencies in the oscs....which complicates matters further. but i think, we have a good starting point now