[sdiy] Stupid Lookup Table Tricks - BLEPs when you can't divide (and can barely multiply)

[rburnett at richieburnett.co.uk]

Neat!  The quality is not bad but there is still quite a bit of audible 
aliasing even with the corrections enabled.

I think the problem is that your LUT of reciprocal values really needs a 
lot more resolution.  It returns the same value for large ranges of 
input index.  This heavily quantizes the positioning of the polyBLEP 
corrections and ultimately limits their effectiveness for the 
anti-aliasing.

You're only seeing about 20dB reduction in aliasing, and should be able 
to do much better than this in practice.  But I think the implementation 
is being limited by the resolution of the reciprocal lookup.

The neat thing about polyBLEP is that the correction curves are simple 
functions, so you would ideally calculate these on a more capable 
platform, instead of using a pre-calculated lookup table.  Then you are 
only limited to the numerical precision of the calculations and not the 
number of entries in a LUT.  But I understand your motivations for doing 
it this way to see if it can be made to work :-)

FWIW, if you just want to generate anti-aliased sawtooths and pulse 
waveforms on a low-end 8-bit platform without oscillator-sync, then the 
best option is probably just to use wavetables.  You store a whole load 
of sawtooth renderings generated by additive synthesis with 
progressively less harmonics in a lookup table.  Every time you go up by 
one octave in pitch you switch to the next waveform from the table.  
Square an pulse can be generated by taking the difference of two 
phase-shifted sawtooths.

-Richie,


On 2018-06-28 01:14, Gordonjcp wrote:
> Why would you pick an avr8 to do bandlimited oscillators?
> 
> Because folk say it won't work, that's why!
> 
> https://github.com/ErroneousBosh/slttblep