Q: band limited difference curve

[antto]

sadly i abandoned this idea, i tried things but the approximations were either poor or very complex/heavy
i still wish something like that could be done tho

so maybe not "BLDC" alone, but a combination of that plus 2x oversampling.. to hide the ugliness above nyquist

[matt42]

Maybe I misunderstood the idea, but it seemed the residual function (difference curve) is for a fixed frequency as it covers the full cycle of the waveform? Is that right? Where as the for blep/blamp we only need the residual of the discontinuity.

So, where as for blep you can apply the same residual regardless of the frequency, but with BLDC the difference curve would be frequency dependant. Or perhaps I misunderstood the whole thing

EDIT:

i still wish something like that could be done tho

I think it is a solved problem: BLEP/BLAMP

[antto]

Maybe I misunderstood the idea, but it seemed the residual function (difference curve) is for a fixed frequency as it covers the full cycle of the waveform? Is that right? Where as the for blep/blamp we only need the residual of the discontinuity.

So, where as for blep you can apply the same residual regardless of the frequency, but with BLDC the difference curve would be frequency dependant. Or perhaps I misunderstood the whole thing

see the first post, the idea was that on one hand you have a naive sawtooth(phase) function, and on the other you have a bandlimited_sawtooth(phase, H) function which simply adds H sinewaves together to construct your sawtooth
then i subtract those two functions and call the result "BLDC" and its approximation thus has a H parameter

maybe i should've given up looking for an approximation and went the "LUT" way instead..

[matt42]

see the first post, the idea was that on one hand you have a naive sawtooth(phase) function, and on the other you have a bandlimited_sawtooth(phase, H) function which simply adds H sinewaves together to construct your sawtooth
then i subtract those two functions and call the result "BLDC" and its approximation thus has a H parameter

OK, thanks I think I understand better now. I would say that coming up with a decent function for a single value of H isn't so easy, but coming up with an algo for arbitrary values of H will be really tough. Compare that to polyblep or something where you just need to integrate a triangular function (piecewise integration of straight lines)

maybe i should've given up looking for an approximation and went the "LUT" way instead..

Perhaps, but I guess you arrive at something somewhat equivalent to wavetable synthesis?

[Z1202]

The BLEP function is Si(x) (called "Sine integral"). Even though the integral itself can't be taken analytically, from the point of view of computation this function is as "computable" as sin(x) or sinc(x). The thing is that typical modern CPUs can't compute sin(x) and software needs to use a special routine (e.g. from the standard library) to do that. In the same way there are routines to compute Si(x). Or it can be tabulated. The BLEP residual can be then computed by simply subtracting the step function from Si(x). However, to be practically implementable it needs to be windowed to make it time-limited.

The residual of the complete sawtooth OTOH is (as it was already noted here) frequency-dependent, which means the table will be frequency-dependent. Note that it is simply equal to the sum of BLEP residuals spaced at the sawtooth period's distance.

[mystran]

The BLEP function is Si(x) (called "Sine integral"). Even though the integral itself can't be taken analytically, from the point of view of computation this function is as "computable" as sin(x) or sinc(x). The thing is that typical modern CPUs can't compute sin(x) and software needs to use a special routine (e.g. from the standard library) to do that. In the same way there are routines to compute Si(x). Or it can be tabulated. The BLEP residual can be then computed by simply subtracting the step function from Si(x). However, to be practically implementable it needs to be windowed to make it time-limited.

The problem with windowing analytically integrated sinc though is that windowing works best when the spectrum looks like a brickwall step with two flat regions. Every additional integration adds a 6dB/oct low-pass slope to a sharp high-pass filter that results in a "spike" in the spectrum around the cutoff point, which degrades the performance of a post-integration windowed design quite a bit for every additional integral... in my experience making the result essentially useless.

That's the main reason I still personally generate all my BLEPs by numerically integrating a windowed sinc. While I also have code for doing the integration analytically, the performance after windowing just isn't there. I suppose applying a window that you can analytically integrate with the rest of it could work, but never tried that.

[matt42]

Don't know how useful it would be, but keeping a set of difference curve tables could be a means of data compressing regular wave tables.

[Chaotikmind]

The BLEP function is Si(x) (called "Sine integral"). Even though the integral itself can't be taken analytically, from the point of view of computation this function is as "computable" as sin(x) or sinc(x). The thing is that typical modern CPUs can't compute sin(x) and software needs to use a special routine (e.g. from the standard library) to do that.

Noway FSIN & FSINCOS were added to the 387 series of coprocessors...
it's a long time that is not anymore computed in software.

[Z1202]

The BLEP function is Si(x) (called "Sine integral"). Even though the integral itself can't be taken analytically, from the point of view of computation this function is as "computable" as sin(x) or sinc(x). The thing is that typical modern CPUs can't compute sin(x) and software needs to use a special routine (e.g. from the standard library) to do that.

Noway FSIN & FSINCOS were added to the 387 series of coprocessors...
it's a long time that is not anymore computed in software.

I fear this info may be a little outdated (along with 387 FPU). For one, IIRC, on Win64 one even can't use FPU, because it's not handled correctly by the OS during context switching anymore. Also, I'm not sure whether FPU is well maintained on the hardware level, in the sense of performance, or is it just a compatibility-ensuring inefficient implementation. At any rate it seems that sinf(x) in MSVC x64 is not 387-based anymore.

[Z1202]

The problem with windowing analytically integrated sinc though is that windowing works best when the spectrum looks like a brickwall step with two flat regions. Every additional integration adds a 6dB/oct low-pass slope to a sharp high-pass filter that results in a "spike" in the spectrum around the cutoff point, which degrades the performance of a post-integration windowed design quite a bit for every additional integral... in my experience making the result essentially useless.

Interesting observation. Didn't notice this in my experiments, but that was a very long time ago, so I'm not sure if I missed the poor qualities of BLAMP spectra, or whether my window choice was good enough to offset the effect you're mentioning.

I mean, if you're integrating a windowed BLEP residual, you're also e.g. increasing the relative amplitude of the "aliasing" in the audible range, since the integration boosts lower frequencies. So the question is, which effect is stronger and that might depend on the window size and shape.

[Chaotikmind]

The BLEP function is Si(x) (called "Sine integral"). Even though the integral itself can't be taken analytically, from the point of view of computation this function is as "computable" as sin(x) or sinc(x). The thing is that typical modern CPUs can't compute sin(x) and software needs to use a special routine (e.g. from the standard library) to do that.

Noway FSIN & FSINCOS were added to the 387 series of coprocessors...
it's a long time that is not anymore computed in software.

I fear this info may be a little outdated (along with 387 FPU). For one, IIRC, on Win64 one even can't use FPU, because it's not handled correctly by the OS during context switching anymore. Also, I'm not sure whether FPU is well maintained on the hardware level, in the sense of performance, or is it just a compatibility-ensuring inefficient implementation. At any rate it seems that sinf(x) in MSVC x64 is not 387-based anymore.

It is more an OS related issue, anyway you got me curious and i checked it, indeed it is compiled to a shitload of instructions...
Didn't realize it was an issue until right now ...

Edit: the best case scenario seems to be when FMA3 instruction set is used.

[mystran]

For one, IIRC, on Win64 one even can't use FPU, because it's not handled correctly by the OS during context switching anymore.

Not true. It works perfectly fine, it's just that compilers don't normally use it, except for extended precision. Since the instructions that save/restore SSE state also save/restore the legacy FPU state, it would actually take additional effort for the OS to explicitly NOT support the legacy FPU.

Also, I'm not sure whether FPU is well maintained on the hardware level, in the sense of performance, or is it just a compatibility-ensuring inefficient implementation. At any rate it seems that sinf(x) in MSVC x64 is not 387-based anymore.

I checked Agner's charts and most modern desktop processors take 50-100 cycles or so to do FSIN. Atom takes a whole lot more... and then you add whatever overhead you get from moving your data from the SSE unit to the x87 when rest of your FPU code is on the SSE unit.. and you can't SIMD... so like... realistically for high performance algorithms you almost certainly want to use a software implementation.

[Z1202]

I mean, if you're integrating a windowed BLEP residual, you're also e.g. increasing the relative amplitude of the "aliasing" in the audible range, since the integration boosts lower frequencies. So the question is, which effect is stronger and that might depend on the window size and shape.

Although, upon further thinking, it seems that the "low-frequency" content is always strictly harmonic, so even if it distorts the low-frequency spectrum, it won't create any inharmonic components. Not sure how large the distortion could get though.

[mystran]

I mean, if you're integrating a windowed BLEP residual, you're also e.g. increasing the relative amplitude of the "aliasing" in the audible range, since the integration boosts lower frequencies. So the question is, which effect is stronger and that might depend on the window size and shape.

Although, upon further thinking, it seems that the "low-frequency" content is always strictly harmonic, so even if it distorts the low-frequency spectrum, it won't create any inharmonic components. Not sure how large the distortion could get though.

Since the "BLEP residue" is essentially "pure aliasing" at the base processing sampling rate, the question for numerical integration is whether the oversampling factor of the (windowed) BLEP kernel is sufficiently high that it well approximates the continuous time kernel... ie. whether the remaining aliasing from sampling the BLEP residue at some high oversampling factor is still meaningful. This aliasing will certainly be boosted during integration.

The big problems however tend to be either harmonic amplitude mismatch just slightly above the cutoff point (ie. aliasing doesn't cancel sufficiently well; personally I've never managed to get reasonable results with analytic approaches here) or step-discontinuities at the beginning/end of the window higher-order BLEP due to repeated numerical integration (which can be mitigated by using a window with better continuity at the end-points.. up to a point anyway).

[Z1202]

Since the "BLEP residue" is essentially "pure aliasing" at the base processing sampling rate, the question for numerical integration is whether the oversampling factor of the (windowed) BLEP kernel is sufficiently high that it well approximates the continuous time kernel... ie. whether the remaining aliasing from sampling the BLEP residue at some high oversampling factor is still meaningful. This aliasing will certainly be boosted during integration.

Oh, I didn't mean that aliasing. I was assuming that integration is done offline with very high precision (I mean, the time-domain resolution)

The big problems however tend to be either harmonic amplitude mismatch just slightly above the cutoff point (ie. aliasing doesn't cancel sufficiently well; personally I've never managed to get reasonable results with analytic approaches here) or step-discontinuities at the beginning/end of the window higher-order BLEP due to repeated numerical integration (which can be mitigated by using a window with better continuity at the end-points.. up to a point anyway).

Hmmm, to get good response at the cutoff you need a long window (just by the Heisenberg principle). However, I wonder how critical is that. E.g. if the software is running at 88kHz or above (which is reasonable to mitigate the prewarping BLT artifacts and reduce the aliasing from nonlinearities at least a bit), you have quite a lot of headroom below Nyquist.