DSP Robotics Support

Here's something I devised sometime last year, it's probably not remotely original. I bumped ito it again the other day and had a "how on earth does this work / what on earth was I thinking??" moment! But I reckon it's quite neat so thought I'd pass it on, might be useful ...

It relates to interpolating DSP processess that have suffered from being hopped, for example envelope generators. Whenever you use 'hop' in DSP code it inevitably generates steps in your output shape - bigger the hop, bigger the steps. Sometimes this doesn't matter, but if it does you can use slewing or interpolating techniques, after the hopped setction, to smooth it out again.

Attached is a very low-cpu-cost method of producing a truly straight-line (linear) interpolation between the steps.


In the attached I've tagged on the more traditional slew-rate-limiter method as well, which you can switch to for comparison. The slew-rate-limiter method produces characteristic bumps between each step sample, whereas my linear method makes perfect straight lines.


To help you with unravelling it all ... The variable "diff" calculates the difference between consecutive steps (4096 samples between them in this case); divide this difference by the hop size (4096), and a perfect ramp is restored by simply accumulating the 4096 'diff' values, during the remaining 4095 samples between each hop. You can hopefully see that accumulating 4096 * (1/4096) = 1, thus generating an accurate linear ramp between between adjacent steps.

It's very efficient because all the calculations are done inside the 4096 hopped section, and the ramp restoration (back in real time) is achieved using a solitary 'add' : interpOut + diff.

Keeps me off the streets ...

H

Wow!

I too had that “How on earth does this work” moment when I saw the schematic in action. So I worked it out then re-read your explanation more carefully. This seems SO clever to me that you can achieve that linear interpolation with just one add at sample rate outside the hopped loop.

I also like the fact that when the ramp resets, the reset-to-zero time is determined by the hop size. This means that for a sawtooth LFO controlling audio parameters the reset could be made less sudden and therefore less prone to producing clicks.

You deserve a prize!

Careful! By comparing it through a scope, you fall to a trap.

The scope only display a few pixels, not nearly all incoming samples. Imagine it like a hop as well. In reality the line will either not look that linear, although better than the staircase, or the dsp module IS calculating each sample instead of only each 4096th.

Also, your code ignores discontinuities. The saw wave would start at -1, after having reached +1. So the two samples at that position would read +1, -1
Your code introduces a delay of 4096 samples, before -1 is reached after +1

Not sure, if these are important points, but they are for sure existing, and I don't think they should be ignored

That's interesting !

But i saw a little problem, over time your maximum value raise and finish to be greater to 1.
I just added a min max value module to check it.

Well at hop 4096 it make no so much sense to optimize but divide take more cpu than multiply,
Maybe multiply with 0.000244141 ?

Yes, some valid observations. I remember noticing the accumulating error when I first devised this ... that'll be rounding errors, that will

Only suitable really for use with poly stuff anyway, where such errors won't be of significance because you don't hold keys down for 10 minutes. (Omg you don't, do you ??) I made yesterdays demo in blue just because it's more forum-friendly that way (- no complication of MIDI keing or anything). Same kind of code.

Nor would I choose to use it with hop(4096) .. ditto! In practice I've used it with envelope code at (64) or (128), where any sample lag, compared with exponential methods, tends to be insignificant.

Btw one other disadvantage of slew-limiter maths is that it can lead to Denorm cpu log-jams ( .. see elsewhere), I can't see that happening with linear interpolation.

Anyways .. here's an Envelope-type version using the same principal. No accumulation error.
Hit <SPACE BAR> to key it ...

H

HughBanton wrote:Only suitable really for use with poly stuff anyway, where such errors won't be of significance because you don't hold keys down for 10 minutes. (Omg you don't, do you ??) I made yesterdays demo in blue just because it's more forum-friendly that way (- no complication of MIDI keing or anything). Same kind of code.

Nor would I choose to use it with hop(4096) .. ditto! In practice I've used it with envelope code at (64) or (128), where any sample lag, compared with exponential methods, tends to be insignificant.

I thought so, too. That's why I said that I'm not sure how important those points really are. But, all who know me understand, that I couldn't NOT point to it

Had a light-bulb moment this morning, while I was sitting on the .. stairs.

The drift caused by rounding can be completely eliminated quite simply :
The two outputs, stepOut & interpOut, should always be == immediately before each new level is calculated; therefore it follows that we can write interpOut = count inside the hopped loop and that will clamp the two together. Negligible extra load.

Not needed for envelope processes of course, which will be regularly zero'd automatically.

Here's a revised version of the original with the ramp. This one can be run continuously in blue after all, should you need something similar.

H

HughBanton wrote: This one can be run continuously in blue after all, should you need something similar.

I confess I didn’t notice the drift when I first laid eyes on this.
However your fix is perfect, simple and uses virtually no more CPU.

Bravo!!

Edit: I incorporated the point that Tepeix made so the multiplication factor is calculated just once at stage(0) instead of 10 times per second at 44100. As per Tesco… every little helps.

Wouldnt it be just more simple to write:

float div = 0.000244140625; // 1/1496

and remove the whole division fiasco all together?

adamszabo wrote:Wouldnt it be just more simple to write:

float div = 0.000244140625; // 1/1496

and remove the whole division fiasco all together?

You clearly like typing in huge numbers Adam!

My thought was that if you change the hop number, the multiplier would have to be re-calculated and entered.
And what about the precision? If you make the division in DSP it takes one sample period just once and handles any rounding internally.