[PD] bandlimited wavetables for pd vanilla

[Claude Heiland-Allen]

Hi Roman,

On 13/02/15 10:32, Roman Haefeli wrote:
> Very nice. Having band-limitation for free waveforms is awesome. I still
> have to dig into it, especially in order to understand how the filtering
> is done.
>
> My two cents:
>
> * You say you learned from OpenGL. Does that mean you applied filters
> initially designed to avoid aliasing in scaled images?

No - I use FFT filtering for periodic waveforms (ie, no windowing 
necessary).

The gain is 1 for frequencies from 0 to SR/4, then it ramps linearly 
down to 0 at SR/2.  The ramp is intended to avoid sudden changes in 
amplitude of harmonics when moving through the wave tables - but the 
linear interpolation mentioned below might take care of that anyway.

I'll do some tests later today (but if you want to get there first the 
ramp is somewhere in "bl-gen-abs~.pd", perhaps try making it 1 all the 
way to SR/2).

> It seems to me
> that they are too 'tight' for audio. With higher notes the perceived
> volume is reduced. Without any proof, I suspect it cuts off more of the
> harmonics than actually necessary.
>
> * Does multiplying the number of tables cause a penalty in memory only,
> or also in CPU usage? Obviously, you need more CPU time to calculate the
> tables, but once they're calculated, does it require more CPU to have
> more tables?

The tables are at powers of two (plus 3 extra wrapped guard points for 
tabread4~) - adapting it to have more in-between tables would be awkward 
because afaik Pd only does powers of two as block sizes, so FFT 
filtering wouldn't be possible.

And more tables do consume more CPU - there is some simple maths and a 
[tabread4~] running all the time for each wavetable level (because you 
can't switch or change table target at audio rate, I silence all but 2 
of them, with the remaining pair being interpolated) - the per-table 
work is in "bl-tabread4-abs~.pd".

> I'd like to have a version with many more tables (so that
> one could get lower notes without the higher harmonics being cut-off).

Try the ramp adjustment I mentioned above first, it might be that I 
messed up there.  There's also an offset in the index generation, [-~ 1] 
somewhere after the [log~ 2] in "bl-tabread4~.pd", changing this to [-~ 
0.5] or even [-~ 0] should brighten the sound but risks audible aliasing.

In any case, the largest table has 2048+3 points, which corresponds to 
oscillators below around 22Hz at typical sample rates.

Perhaps you just need to copy a larger table region - inlet arguments to 
[bl-gen~] are source table, length in samples, and offset in samples. 
Offset should be at least 1, for tabread4~ guard points, and the table 
should have at least 3 more points than the supplied length for the same 
reason.  For smoothest results, the source table should be 
[tabosc4~]-ready (ie, power of 2 plus 3 with the last 3 points the same 
as the first 3 points).


Claude

> On Thu, 2015-02-12 at 16:06 +0000, Claude Heiland-Allen wrote:
>> Hi all,
>>
>> Today I implemented bandlimited wavetables in Pd vanilla using the idea
>> behind mipmapping in OpenGL (ie, generate many filtered and downsampled
>> versions of a source, use the most appropriate version(s) by a function
>> of the derivative of the lookup index).
>>
>> More info and full source (quick start tutorial: bl-example.pd):
>>
>> https://gitorious.org/maximus/pd-bl
>>
>> License: same as Pd vanilla.
>>
>> Advantages over other implementations:
>> * Can generate wavetables from any waveform stored in a table.
>>
>> Disadvantages:
>> * The higher harmonics are reduced compared to an optimal method.

-- 
http://mathr.co.uk