Shortest pulse width to support

[synthpark]

Hi there!
What is the shortest pulse width to support in a modern synthesizer VST?

5%, 10%? I wonder what a Juno 60 could do. I know that a Prophet 5 can be reduced down to 0, but aliasing will start to be present with some straight forward technique. Limiting it to 10% makes life much easier, but could be not "state of the art".

regards

[2DaT]

5%, 10%? I wonder what a Juno 60 could do. I know that a Prophet 5 can be reduced down to 0, but aliasing will start to be present with some straight forward technique.

0%
There is no such problem if you use BLEPs with subsample precision (it can go from 0 to 1 and back to 0 within 1 sample).

[S0lo]

You can go down to a pure band-limited pulse given that your doing proper anti-aliasing, or BLEPS etc....

Pure pulses are heavily under utilized. Going lower than that is not sonically very useful IMHO.

[synthpark]

Thank you!

Is there any paper which describes BLEPS the most forward way?
It cannot be a simple filter, rather some sort of replacement technique.
Then I wonder whether the algorithm must look somewhat in the future
which can turn out to be problematic together with certain modulation.

Synthpark

[mystran]

Is there any paper which describes BLEPS the most forward way?
It cannot be a simple filter, rather some sort of replacement technique.
Then I wonder whether the algorithm must look somewhat in the future
which can turn out to be problematic together with certain modulation.

Not sure if there are any really great papers, but the basic idea is that only the discontinuities cause aliasing, so if we can solve the exact (sub-sample) position and magnitude of the discontinuities, we can subtract a pre-computed "BLEP residue" (scaled appropriately) from the naive waveform to cancel out the aliasing.

The "BLEP residue" can be computed by subtracting the trivial step from a band-limited step. The band-limited step can be obtained by integrating a highly oversampled brick-wall FIR low-pass, which can then be decomposed into branches similar to a poly-phase interpolator to obtain non-oversampled residues at different sub-sample offsets (which can then be further interpolated at run-time to obtain the intermediate position). This is all normally done as a preprocess, with the final results stored in a lookup table.

At run-time when generating the waveform, you then generate the naive waveform and check for discontinuities. For every detected discontinuity (and you certainly should detect them all), you solve the position and magnitude, then fetch and scale the relevant BLEP and mix it into the output buffer. Since you usually want the BLEPs to be linear-phase, you mix the naive waveform into the buffer with half the BLEP length worth of delay. This essentially gives you some "lookahead" but the algorithm itself can still process one sample at a time and even though several BLEPs might overlap, you can simply mix them into the output one at a time as you come across the discontinuities (which means it's relatively easy to do things like hard-sync oscillators with master and slave modulated separately, etc).

Since there are a lot of moving parts (ie. the BLEP residue computation, residue interpolation, the output buffer mixing, the actual oscillator logic) you might find it useful to first look at my old PolyBLEP tutorial (viewtopic.php?t=398553) which uses simple 2-sample polynomial "BLEPs" to avoid most of the complexity with the actual residues (and just tries to show how to solve the discontinuities), while still demonstrating the general structure of the algorithm (ie. how to solve the position) in such a way that longer BLEPs can be integrated in a fairly easy way... and even as is provides WAY better quality than naive oscillators.

[S0lo]

Thank you!

Is there any paper which describes BLEPS the most forward way?
It cannot be a simple filter, rather some sort of replacement technique.
Then I wonder whether the algorithm must look somewhat in the future
which can turn out to be problematic together with certain modulation.

Synthpark

https://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

Also Google for MinBLEP.

[mystran]

Thank you!

Is there any paper which describes BLEPS the most forward way?
It cannot be a simple filter, rather some sort of replacement technique.
Then I wonder whether the algorithm must look somewhat in the future
which can turn out to be problematic together with certain modulation.

Synthpark

https://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

Also Google for MinBLEP.

Just ignore everything about "minimum-phase" though. It sounds great at first, but it only causes additional problems without really solving any.

[e-crooner]

The quarter pulse option found on some synths already sounds pretty thin and nasal to me, but still musically useful for some sounds.
If you have a continuous PW knob, it would be strange to limit its range to 10%, though.

[vortico]

To my memory, all of the Eurorack analog oscillator modules I own go to 0% (and 100%) pulse width. However, when implementing square waves in software, I limit at 1% or so, because I've gotten several user complaints that "There's no sound at all coming from this oscillator! The software is broken!" In my personal opinion, I actually prefer this because when playing live or with enormous patches (when you can only afford 1% of brainpower solving problems like these), it's often hard to figure out that the reason there's no sound is because the PW knob is hard-left.

[S0lo]

Thank you!

Is there any paper which describes BLEPS the most forward way?
It cannot be a simple filter, rather some sort of replacement technique.
Then I wonder whether the algorithm must look somewhat in the future
which can turn out to be problematic together with certain modulation.

Synthpark

https://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.pdf

Also Google for MinBLEP.

Just ignore everything about "minimum-phase" though. It sounds great at first, but it only causes additional problems without really solving any.

Would be interesting to elaborate on "Why is that so?". As I'm aware of more than a few well known devs/synths that use minimum-phase. Synths like Hive, DUNE 2, Lush-101, Softube modular, Bazille, Karma FX to name a few all use some form of either minBLEP or minimum-phase filters for waveform generation. At least thats what clearly apparent when you look at the waveforms.

[mystran]

Just ignore everything about "minimum-phase" though. It sounds great at first, but it only causes additional problems without really solving any.

Would be interesting to elaborate on "Why is that so?". As I'm aware of more than a few well known devs/synths that use minimum-phase. Synths like Hive, DUNE 2, Lush-101, Softube modular, Bazille, Karma FX to name a few all use some form of either minBLEP or minimum-phase filters for waveform generation. At least thats what clearly apparent when you look at the waveforms.

First of all, you should usually not draw too many conclusions about the exact oscillator waveforms by looking at the output of some plugin, because there are any number of reasons why the phase of the oscillators might have undergone some phase-distortion later in the signal chain. As an obvious example, if oversampling is involved and minimum-phase filters are used for resampling (and that's pretty common), then those will tend to give you ripple that looks like minBLEPs no matter what. It is entirely possible that some of these use minBLEPs, but it is also entirely possible that none of them do. [edit: I'm not familiar with the internals of these particular synths (and even if I did, I probably wouldn't be at liberty to discuss the specifics), but what I can say is that none of those synths that I do know something about use minBLEPs where as some of them do use linear-phase BLEPs]

As for the reason to avoid minBLEPs: because the latency of minimum-phase filters is frequency dependent. In practice this means that whatever fixed latency you assume, you'll end up with DC offsets that that vary depending on frequency, modulation, sync-phase, etc. While you can high-pass filter these out in steady-state, you'll usually need to put the DC blocker cutoff higher than what you would otherwise use and even then you're usually left with some CV bleed with fast modulation. If you're trying to model analogs, it also makes it impossible to match the low-frequency behaviour which is usually far from negligible (since it usually modulates non-linearities further down the signal chain). You can minimise the problems to some extent by choosing a "best guess" latency value, but if you're going to have to compensate anyway, then in most cases you might just as well use linear-phase.

If you understand how to implement linear-phase BLEPs correctly and still decide to go with minBLEPs instead, then I can certainly respect such a choice. Even then, I just like to remind people that if the motivation is to avoid having to deal with the latency (which was the motivation in the original paper) then minBLEPs won't save them, because the latency is still there, but now you can't properly compensate for it anymore.

[mystran]

I should also add that if you ever want to do triangles (let alone higher-degree polynomial segments), you can quite quickly run into numerical issues with multiple integration even with linear-phase kernels and the situation with minimum-phase kernels is usually much worse as you can't rely on symmetries to cancel out errors. You have been warned.

[2DaT]

Just ignore everything about "minimum-phase" though. It sounds great at first, but it only causes additional problems without really solving any.

I wonder why this idea of min-phasing even came up. At best it wins maybe a few samples of latency. But even with linear phase BLEPs, it's about 8-16 samples of latency @ 44.1k. It's a negligible amount for keys, because midi jitter is way more than that.

Of course when there are feedback loops between oscillators - it matters, but minBleps won't save you here either.

[mystran]

Just ignore everything about "minimum-phase" though. It sounds great at first, but it only causes additional problems without really solving any.

I wonder why this idea of min-phasing even came up.

From the original BLEP paper:

Also, the windowed-sinc approximation is complicated by having to look ahead to place impulse centers. This lookahead comes about because the windowed sinc is symmetric, placing the bulk of its energy in the middle. This problem goes away if we consider the windowed sinc as an FIR filter, construct a minimum-phase filter with the same amplitude response, and use that instead.

So I believe the idea was to just ignore the minimum-phase latency, but as it turns out, that doesn't really work that well in practice. It also turns out that once you structure your code to deal with arbitrary overlaps of BLEPs (ie. you'll have to mix into a "delay buffer" anyway, or at least any other option is really inefficient), mixing in the naive waveform with an offset becomes a trivial matter, but this might not have been obvious at the time the paper was written.

[mystran]

I feel like a lot of misconceptions about BLEPs (especially early on) can be explained by a processing model where every discontinuity starts the playback of a "BLEP voice" which you then track and process sample at a time, concurrently with the naive waveform and other overlapping BLEPs.

It is important to understand that this is NOT what you want to do.

In practice, what you actually want to do is process the whole BLEP in bulk as soon as you find a discontinuity. In order to do this, you need an output buffer where you can mix into the future (ie. we "stamp" the BLEP into the buffer and then forget about it). This buffer always has space (at least) for the current processing block plus one full BLEP length. The "tail" then becomes the initial contents of the output buffer for the next block, similar to overlap-add FFT convolution.

Once you assume this type of processing model the whole thing is actually pretty simple and the "lookahead" is really just a matter of adding an offset to where you mix your naive waveform.