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

[Tom Wiltshire]

Don’t forget the golden rule on 8-bit processors:

“Don’t do hard sums!”

Look-up tables for anything even remotely taxing are essential. Then it’s just a question of working out how much accuracy you need in the table (both bit depth and table length) and whether you can manage with a simple table or whether it makes sense to interpolate. Even just reading two entries, summing and downshifting to create an extra table entry in-between every other one can help a lot - after all, you just doubled the effective size of the table.

Sometimes it is better to have excessive accuracy in the look-up table, especially if that gets you to a round number of bytes (e.g. using 16 bits when you only need 12). That would be my approach with these reciprocals. This also helps when interpolating, since you’re not introducing further error by having heavily quantised data to interpolate from.

Frankly, the errors introduced by simple linear interpolation have only very rarely been the cause of my worries. Usually the other limitations are more significant.

==================
       Electric Druid
Synth & Stompbox DIY
==================

> On 2 Jul 2018, at 06:59, rsdio at audiobanshee.com wrote:
> 
> I didn’t look at any of this in detail. Does the Arduino sketch use interpolation of pre-computed table data? If so, wouldn’t that add distortion? ... and potentially aliasing?
> 
> Brian
> 
> 
> On Jun 28, 2018, at 4:00 AM, rburnett at richieburnett.co.uk wrote:
>> 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
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy