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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
