Better polybleps polynomials

[itoa]

Any idea how to construct a good polyblep ponynomial? Currently I use 2 points quadratic: 2 * (t - t^2/2 - 0.5) -@2x oversampling. I've seen that e.g. Monark uses 7th order, 4 points polynomial. I wonder how do they derived this. Is this a cos approximation, where should I start?

[Smashed Transistors]

I think that tabulated bleps are a better option if you deal with more than two points.

[aciddose]

That depends upon several things. For example it is quite clear that monark uses varied edge slopes on their waveforms. Given that you have enough tables and that these tables are long enough, there is potentially a point given frequent random access patterns where a polynomial becomes more efficient.

Especially when you're dynamically modulating the shape of the polynomial.

(Also note a polynomial computation can be SIMD optimized quite trivially compared to a table look-up + interpolation.)

Of course if you are using a single table around 16 words in length (16 samples * 4 bytes = 64 bytes) it should fit when aligned in a single cache line.

Also of note that a polynomial need not produce the sharp cutoff we would typically require from a single stage FIR (blep table) for example when the complete synthesizer is oversampled. The decimating interpolation can be applied once at the output and in such a case the polynomial need only be "as good as" the final FIR filter at the oversampled rate.

[itoa]

No, haven't noticed this, its a symmetrical 4 points 7th order polyblep macro - phase in -> blep out. All waveforms are derived from saw.
I spent some time on this ensemble. There is nothing extraordinary in VCOs - pure mathematical waveforms modulated with some 'drifters'.

Ok, my intuition tells me that ideal polyblep shape is cosine. (Additive synthesis confirms this Am I right ? So the polynomial should approximate this.

[aciddose]

My last edit added the most useful point.

If the whole process is oversampled we would be more interested in a monotonically decaying function than the slope or stopband level at a particular point.

(Monotonically decaying = no upward ripples, just a constant decay)

The passband edge should also be very important to us... That is the ability of the filter to avoid modifying the passband near the edge as much as possible.

Are you sure they're generating only the ramp waveform? There must be an incredible amount of oversampling applied in that case.

[aciddose]

As far as your thoughts regarding cosine... Have a look at Fourier transforms of various windows.

Whether we're talking about applying this as an edge of a waveform or as an envelope applied to minimize the 'click' of the attack of a sine or for the typical use in Fourier transforms, the raised cosine "Hann" window is obviously not the best choice. There are a lot of other options to take into account and which one is best depends entirely upon which properties you are interested in.

[itoa]

Thanks,

I can accept a 'sudden drop' above say.. 15Khz (7 @2x sr). I achieved this with 'careful' sine saturation, but its not the case since I want to do hard sync and other stuff.

as for Monark:

I owe Reaktor and spent some time on this ensemble.
- Everything runs @2x samplerate, except the filter (that is blackbox - core cell) that runs @6x.
- Pulse = 2 saws. The saw polyblep: https://www.desmos.com/calculator/htfpu4fylh. Triangle uses another one... Haven't checked this yet
- The whole magic comes from filter. Seems its a TPT Ladder with single tanh saturator (symmetrical). If you bypass the filter all you have is a perfect mix of perfect wave shapes modulated with some random drifts.

[2DaT]

Thanks,

I can accept a 'sudden drop' above say.. 15Khz (7 @2x sr). I achieved this with 'careful' sine saturation, but its not the case since I want to do hard sync and other stuff.

As far as i know, the implementation of polybleps abuses that fact, that two bleps never overlap. This is easily doable when you limit highest frequency of your oscillator, so 2 transitions never occur closely. However, in case of hard sync, transitions can be closer than 1 sample, thus making your elegant polyblep implementation useless.

[itoa]

Still have no idea how to construct the polynomial :/.

The point is I want to avoid minblep spikes, they don't always play nice with my nonlinearities, but most probably I will achieve the same or better results with post filtered minbleps (like 2 short fir filters in series).

[mystran]

Thanks,

I can accept a 'sudden drop' above say.. 15Khz (7 @2x sr). I achieved this with 'careful' sine saturation, but its not the case since I want to do hard sync and other stuff.

As far as i know, the implementation of polybleps abuses that fact, that two bleps never overlap.

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).

[aciddose]

Still have no idea how to construct the polynomial :/.

The point is I want to avoid minblep spikes, they don't always play nice with my nonlinearities, but most probably I will achieve the same or better results with post filtered minbleps (like 2 short fir filters in series).

I can't help you with the polynomial stuff as all of my use cases have made tables a far better choice.

As for post-filtering, this involves a very complex phase shifting filter and you may find by the time you end up with anything useful the polynomial + filter have become far more expensive than the preprocessed table. (Similar to the problem with generating a 3db/o filter.)

One of the major advantages of a table is that you can apply any sort of filter, phase correction or other techniques used to minimize Gibbs phenomenon such as the lanczos sigma.

http://en.wikipedia.org/wiki/Sigma_approximation

With a polynomial you're facing the much harder to tackle Runge's phenomenon.

http://en.wikipedia.org/wiki/Runge%27s_phenomenon

[Tale]

I don't really know how to construct polyblep ponynomials... but meanwhile I have added a graph of this one to my old polyBLEP comparison topic.



This one looks (and sounds) pretty good, although the difference with the other, lower order ponynomials gets less when you oversample.

[2DaT]

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.

There is slight rolloff near nyquist due to frequency wrap of filter.





By the way, maybe it's possible to reuse some calculations in piecewise "in between samples" approximations of large blep, making it more efficient than oversampled linear interpolation.

[itoa]

I ended up with tanh(sin(x) * c), with c = f(freq). I set it so: roll off starts at 10Kz, -20db @20Khz and -60db aliasing @16 Khz.
All waveforms are derived from this. Plays nice with my nonlinearities and I like its sound. I don't need hard sync.

[Z1202]

Thanks,

I can accept a 'sudden drop' above say.. 15Khz (7 @2x sr). I achieved this with 'careful' sine saturation, but its not the case since I want to do hard sync and other stuff.

As far as i know, the implementation of polybleps abuses that fact, that two bleps never overlap.

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).

Poly- or Table-BLEPs, having a buffer to compensate the latency is, at least theoretically, a good idea. Otherwise, as soon as the frequency is not constant, you mispredict the BLEP position, which affects the mathematical correctness of the whole thing. In extreme cases of FM you might even begin to generate a BLEP, which is not there.
As the overlapping goes, this is naturally not a limitation of PolyBLEP (or any BLEP), and is much easier addressed, if you apply the residuals technique (IIRC, mentioned in quite a number of various sources, so I'm not gonna further elaborate on this here).