Better polybleps polynomials

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

2DaT wrote:
mystran wrote: The implementation strategy I presented in this thread has no limits on overlapping BLEPs whatsoever. The basic idea is simply to buffer the output far enough into the future that you can fit a complete BLEP in the buffer [which in the example code is just 2 samples, because of the simple poly-kernel], then process as naive, except whenever you see a step-discontinuity (which can happen multiple times per sample, obviously) you mix a BLEP into the buffered output (the whole thing right on the spot).
Yes, your implementation seems more advanced (and complicated) than implementation in this topic.

However, i still see no usage for polyBleps for high quilaty oscillators. Transition band for 2-4 sample filter is too wide for my tastes.

I use 16 samples long, 64x linear interpolation, linear phase blep with blackman window. :)
Yes. The above implementation I linked is actually based on tabulated BLEP code, just simplified quite a bit to make it easier to understand. Basically all you need to do is replace the single-sample delay with a buffer and you can mix longer BLEPs from tables instead. The code on which that one was based on does various waveforms (eg PWM triangles, polynomial sine-approximations, couple of pulse-variants, etc) and runs two oscillators interleaved for hard-sync (this way it's quite simple to handle multiple sync-triggers per sample, even if it might be somewhat academic really; it'd be possible to run analytic ring-mod as well, but I haven't actually implemented that one except in a simple saw-only prototype), but the whole thing would be a little complex for a forum post, hence the simplifications.

In practice, I typically use 16 or 32 taps (depending on whether or not the oscillator is running oversampled), with Nuttall window (trading a bit of transition width for more attenuation over Blackman) and 4096 branches nearest-sample (using FFT to generate the tables, to avoid time-domain numerical issues; not sure if there's much performance difference one way or another though, mostly it just simplifies implementation with multiple derivatives). With the actual "insert BLEP here" function factored out of the main oscillator code though, it's easy to experiment with variations though.

Post

It seems iota we have genuinely arrived at the same solution through different routes, except I decided to use four samples at lower Fcs and oversample at higher Fcs, our polynomial is derived the same way.

I like the idea of buffering the samples.

Post

And actually there is a problem in my implementation in that sync sets the phase half way through a pulse, instead of at the beginning. So it actually works with sync, but for the wrong reason. :) the code is here:

http://www.yofiel.com/software/cycling- ... scillators

Post

oh. It's true if you look at my code only, it appears it uses two samples. But the constant sr/2 is actually 4 samples. This is because the phase accumulator works in the range -1 to +1, rather than 0 to 1, for proper FM phase generation. We did have a debate on the Reaktor forums about that topic about 12 years ago, which has since been deleted. But if you think about it, its' required, and most people don't do it because FM generates very similar results with a 0-1 phase accumulator. So the SR constant which appears to set it to 2 samples is actually setting it to four samples, because it was previously scaled for a phase accumulator in the -1 to +1 range.

Post Reply

Return to “DSP and Plugin Development”