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.