New Antialiasing Technique?


#10

Some random unfinished and unproven Sunday ideas for anti-aliased oscillators. They could be wrong, or not beneficial in practice, but maybe inspiring somehow?

  • representing the pre-integrated wave in integer can perfectly recover from overflow if the playback speed is limited, and avoid the need for double precision floating point. Ultimately floating point representation is not an advantage, only the number of mantissa bits matter. In floating point, the accuracy will drop towards the end of the table, while integer results in a constant accuracy.

  • the pre-integrated wavetable concept could also extend to a 2D (or 3D) summed area table

  • complex oscillator waveforms could be obtained from a set of octave-stacked DPW oscillators. A DPW oscillator only deviates at one single sample from the straight function (at the transition). When the phase difference of each oscillator is 180 degrees compared to the corresponding higher octave, there is really only a single transition at a frequency one octave higher than the top octave across all octave-stacked oscillators.
    x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.
    .x...x...x...x...x...x...x...x..
    ...x.......x.......x.......x....
    .......x...............x........
    ...............x................

    This could lead to a massive reduction in computation. The tricky part is dealing with changing frequencies, jumping the top octave to the first below nyquist.

  • noise shaping the oscillator period? When the period time is an integral number of samples, the alias frequencies align with the desired spectrum. Now that does not produce the desired frequency, but this could be seen as an application of noise-shaped quantization.

  • Cancelling aliases with another oscillator? Cancelling the first order aliases would already be a significant improvement. Perhaps an approximation could be created with an SSB frequency shifter?


#11

Sure it does, in fact my problem is that i've been coding JSFX plugins for quite a long time and i'm somewhat addicted to doubles.

I think that second order pre-integration can work with 32bit floats for non modulated dpw oscillators (w stands for waveform or wavetable here). As you stated, the phase change is steady and the 1/delta_phase factor is not a problem.

But as far as i experimented it won't work for phase modulated dpw oscillators (or distortions).
The problem is that the phase is modulated we get factor of the form 1 / (delta_phase + delta_modulation)
which can lead to division by 0 (or something very small = > accuracy issues).

I'm not very confident with my abilities to handle/combine integer divisions to get high precision fixed point arithmetic.

Maybe, 1st order DPW and 4x oversampling with floats will be the solution for anti-aliasing phase modulated wave tables and distortions. That will be my first try.

I'll certainly experiment all these in a month or two.

I just ordered my axoloti :package: and i already plan all that...

By the way, i've spent half my week end browsing this forum :books: and i'd like to thank all its contributors :smiley:


#12

Yes but, like MIP MAPs, it does not handle anisotropy well (texture in perspective)


#13

I think that BLEPs are that kind of oscillators ?...?
[Edit]
oops, I misunderstood,
by first order, you mean first reflection (not aliasing of first order discontinuity) ?
The problem will be to control the phases of the cancelling signal.

Another idea is to use a tuned comb filter that attenuates what's between harmonics.


#14

I started to experiment with pre integrated wavetables.
My goal is to make an antialiased wavetable object capable of phase modulation.

I did not achieved to make a 2nd order integration. 32 bits are not enough and i had artefacts in the low pitches (ill values due to divisions by small numbers).

Anyway, here is an implementation of the first order DP wavetable with phase modulation.

At the moment, the pre-integrated polynomial wavetable is hard coded.
I wanted to see if it can be implemented on the Axoloti and if it is efficient. In fact it seems to be.
I use a float division along with fixed point operations.

It is a first order DPW, so the antialiasing is not perfect. It will need x2 or x4 oversampling for extreme
modulation or when used for distortion.

The object:
Wave3.axo (13.3 KB)
A simple patch:
Wave3.axp (3.0 KB)


#15

Awesome @SmashedTransistors

Definatly going to try it out. I have made many different wavetable subpatches, but they all use a lot of DSP. So I look forward to try a dedicated object :wink:

I will get back to you on it.

I have made a wavetable morph subpatch that morphs between 4 waves. You can try it out here:


#16

@SmashedTransistors

Ok, tested the patch, seems like it is working pretty well. No disconnects or any odd behaviour.

But I think you can all ready make phase modulation on wavetables as it is now. Use the drj/osc/phasor_pm_pr_b from DrJustice to drive the table. ANd modulate the phase input...

Probably not a efficient as a dedicated object. Look forward to see how the object you are working on will develop, as I am addicted to wavetables :wink:


#17

Hi jaffasplaffa,

sorry, i was so busy experimenting that i did not took time to try your patch, i'll do it tomorrow.

Directly driving a wavetable with a modulated phase will produce aliasing for high pitch or heavy modulation.
Aliasing is what i am fighting.

My first goal here is to adapt an anti aliasing method I already used in JSFX plugin's.
Once I find the best way to implement it on the Axoloti I will certainly make different objects (oscillators and distortions).

So this evening, i experimented 2nd order differentiation with 32 bit integers, even with optimisations.
~ 1900 cycles, inaudible at high pitch aliasing but i had glitches in certain conditions (low frequency and deep phase modulation).

I tried using some 64bit integers (the STM32F4 has 32bx32b -> 64b mul and mulad) for the most critical sections of code. ~ 3000 cycles but it was not enough... again glitches when using slow and deep phase modulation.

So, for the moment, i won't try to use 2nd degree.

The first degree DPW is around 1200 cycles, I will try to use some oversampling.


#18

Hey man :slight_smile:

Sorry, I am not so much into the coding language, som I dunt understand some of the stuff you say. But I find it interesting to test new ways of using wavetables :slight_smile:

Loo forward to see what you come up with :wink:


#19

Here is a practical example of aliasing vs antialiasing:
https://soundcloud.com/thierry-rochebois-1/pre-integrated-wave-table-antialiasing-test
It is a glissando.
The first time, wavetable with linear interpolation.
the second time, the same wavetable with a 3rd order pre-Integration and DPW.


#20

Wow huge difference! Sounds VERY clean, the second one. I look forward to your final wavetable object.

One thing I'd like to suggest is to keep the system "open". By that I mean it would be super nice that the object is not locked to a specific size wavetable. For example @thetechnobear 's WT object is nice, cause you can use it with any size, just set number of waves and the size for each wave and you are good to go:


#21

I get your point @jaffasplaffa, I'll follow your advice when i will implement wavetable objects.

At the moment, I'm in an investigation phase.
I investigate practical use of Differentiated Polynomials on the Axoloti :

  • polynomial order ?
  • numerical problems / accuracy / ill conditions (div by 0)...
  • float, fixed point or mix ?
  • oversampling ?
  • usage:
    • wavetable
    • distortion
    • phase modulated wavetables
  • CPU load

Here are two simple and practical examples of Differentiated Polynomials used for distortion.

Here is a first order differentiated polynomial HardClipper:
DPHardClip.axo (1.9 KB)

and a first order differentiated polynomial SoftClipper:
DPSoftClip.axo (1.8 KB)
~740 cycles

I tried many combinations of int32_t and floats and in this case, using floats gave me the best CPU counts. Maybe because the FPU has lots of registers that helps the compiler to optimize the code...

PS I tried to go the Github / contribution way with no success so i post them here.


#22

Haven't had a chance to test any of these objects, yet, but if I may go back to something I mentioned earlier..

Do you think it would be possible to create an Axoloti patch capable of recording in realtime, then pre-process the recording into a wavetable suitable for anti-aliased DPW playback?

a|x


#23

Hi @toneburst,
I think that it is possible.
I think that the steps would be:

  • usual steps:
    • sample
    • loop (with cross-faded envelopes or crossing point / cycle detection)
    • after those steps we have v[] the table of values for one cycle
  • preparation / pre integration steps:
    • DC remove on v[]
    • calc of dv[] (delta values dv[i] = v[i+1] - v[i])
    • calc of first order integrated table Iv[] (Iv[i+1] = Iv[i] + v[i] + 0.5*dv[i])

The preparation steps are not too complicated (as compared to FFT bandlimiting used in MIPMAPing).

After this preparation, i think that the tables could be used like the static table I've hardcoded in wave3.axo

In the next days, i think that i will experiment with oversampling because to me, first order DPW should be complemented by x2 or x4 oversampling for high quality results.


#24

Yes I see there are many things to take in to consideration. Sorry, I can't help you with the technical stuff, seems like a great project. Thanks for taking my words into consideration. Still looking much forward to play around with your finished object :wink: The oversampling/better quality idea sounds really great :slight_smile:


#25

Wow. I've been reading Thierry's axoloti work again, and I love this work: sounds great, definitely over my head, and I was google searching for BLEPs and DPWs in hopes I could learn something and apply it to my own work (and maybe one day get stuff happening on Axoloti, too).

I didn't think I would run across this (first?) SmashedTransistors post, saying 'I'm new here'. I kind of am too, as I keep busy and can only revisit axo places now and then. But I think I can answer the OP question.

Because I'm Chris from Airwindows, and I'm the one who did Slew2 :slight_smile:

It is NOT antialiasing, not really. I'm not nearly as good at antialiasing as Thierry. What's in Slew2 is a weird sort of technique for crudely oversampling a waveform and then doing weird things to downsample it back, and specifically what happened in Slew2 was accidental. It's a slew clipper, nothing more, but it interacted strangely with the 'antialiasing' that's not really antialiasing, and produced a big cancellation node right at Nyquist. Fun but I don't think there's anything in there that'll apply to real antialiasing (I'm better at wordlength reduction, still working out things about antialiasing).

I could open source (MIT license) Slew2 if you like, though the 'antialiasing' is a bit sad. But it did produce Slew2, so that was kind of interesting. I expect if you run sweeps and things through it, it will freak out in weird ways like the other plugins of that generation: I ended up going with a minimal-calculations model and putting all my attention on word length, and just doing plugins which don't challenge Nyquist so much. Of course if you're building raw oscillators you can't do that :smile:

oh, and of course Olivier is right, it wouldn't work as a general anti-aliasing solution for digital oscillators.

Anyway I just had to reply, to say, surprise! I am here, and already a big fan of Thierry's work. Who knew that my experiments would start such a discussion? I too am interested in the answers. Maybe I'll end up with real antialiasing after all :heart_eyes:


#26

Hi Chris, great to see you around this forum, and hoping to see (hear) something of yours in axoloti land one day.
I'm also a great fan of Thierry's (@SmashedTransistors) axoloti achievements. I'm no coder, only a happy user, and I can't thank enough all you guys that provide us amazing / useful objects for our patching adventures.


#27

That Skew2, does look interesting :slight_smile:


#28

And a big thank you to @johannes that provides us with such a versatile environment !


#29

Hi @chrisj

I hope so, this is really nice to have code running out of a PC with almost no latency.

Lots of people, from companies and academics, focus on "Virtual Analog" stuff. I'm not a big fan of this, and this is great to see people experimenting with new ideas. There is a lot of stuff to experiment with non linear "filters".