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.2DaT wrote:Yes, your implementation seems more advanced (and complicated) than implementation in this topic.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).
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.
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.