Slew Rate Limiter

kirkagur · 28 Nov 2010

I like it! 😀

trogluddite · 28 Nov 2010

...or...

streamin x; streamin limit; streamout y;

y=y+min(limit,max(0-limit,x-y));

The toolbox one is strange, as far as I can tell it's not a slew limiter at all, it's a basic low pass filter.

tor · 28 Nov 2010

It was a slew rate limiter on the attack part of the envelope I did not implement on the first upload of my compressor. It caused it to jump to quicly at short timing and slowly increasin amplitudes. He he.. now I know the technical term of it to.

Slowly learning each day 😉

Jay · 30 Nov 2010

Cool stuff Bootsy! this is most useful, thanks 🙂

Best Regards

theun · 1 Dec 2010

@ bootsy Thanks for pointing out the misbehavior of the stock slew rate limiter. I used the stock module in a number of designs without realizing it did something else than expected 😉 Your code does exactly what I would expect, anyway, so thanks!

@ trogluddite your code gives exactly the same output as bootsy's, however written this way the code translates easily into a very efficient asm (slightly optimized):

streamin in;streamin limit;streamout out;float F0=0; movaps xmm0,F0; subps xmm0,limit; movaps xmm1,in; subps xmm1,out; maxps xmm0,xmm1; minps xmm0,limit; addps xmm0,out; movaps out,xmm0;

For those interested, I attched the osm (slew limiter only)

trogluddite · 1 Dec 2010

theun wrote: your code gives exactly the same output as bootsy's

Yup, the definition of slew limiting doesn't leave much room for 'artistic' interpretation!

Nice asm optimisation - not a wasted cycle/register/variable in sight (well, I did make it easy for you 😈 ) Illustrates well the first law of ASM optimising - always optimise the hell out of the code first (Oh, how I learned that the hard way).

robrokken · 20 Jul 2011

I understand this is for parameters? How much different is this from something that would be applied during gain reduction, or like an opamp/vca type deal? I was thinking of trying to smooth the waveform a bit or at least make gain transitions a bit smoother.

EDIT: Now i actually look at the term LIMITER. I think I was confusing it with a slew rate. My hopes were to smooth some of the transients in audio as well as just general smoothing.

trogluddite · 20 Jul 2011

Yes, definitely more useful for control signals - though most of the time, the regular de-zipper will use less CPU. Can be handy where you need exact control over the rate of change though - e.g. some filter designs can become unstable if the cutoff frequency is changed too quickly. On audio, the effect can be a little odd - low level signals will not be changed, whereas higher level signals will lose their transients and begin to sound low-pass filtered. Maybe a little similar to an amp that is struggling to provide enough gain, or where the power supply rails are starting to 'sag' under the load.

infuzion · 20 Jul 2011

robrokken wrote: I understand this is for parameters? How much different is this from something that would be applied during gain reduction, or like an opamp/vca type deal?

Was that you posting on KVR? 😉 BTW, de-zipper = LPF

trogluddite wrote: ...though most of the time, the regular de-zipper will use less CPU. Can be handy where you need exact control over the rate of change though - e.g. some filter designs can become unstable if the cutoff frequency is changed too quickly...

Wow trogluddite, you are a walking audio encyclopedia! I'm surprised you don't put more up on the WiKi, or write a book.... (for other visitors in the forum) SM's de-zipper = LPF, but if you had the code, you can adjust the rate, so that is the same effect then?

trogluddite · 20 Jul 2011

infuzion wrote: SM's de-zipper = LPF

Not quite - it seems more like a linear ramp if you check it out on a scope. I think that's why it's so fast - it seems to work out the 'slope' of the ramp when there's a value change, and then go to sleep once it reaches the target. I tested it against an LPF a while ago because I had a schematic with dozens of the little buggers. It's extremely economical as long as the input value doesn't change too often, but there was quite a CPU spike at the moment of 'activation', making a basic LPF faster if the input value is changing lots. So, great for smoothing the odd knob waggle, but not always so effective for smoothing, say, a stream modulation source.

infuzion wrote: Wow trogluddite, you are a walking audio encyclopedia!

I believe 'anally retentive' would have been a certain Mr. Freud's classfication! 😉

infuzion wrote: I'm surprised you don't put more up on the WiKi, or write a book...

Saving myself something to do when I retire! and Wiki editing just takes me too long - I just can't help myself being a 'precious' perfectionist about every goddamned little formatting tweak.

(the above points may possibly have some bearing on my current lack of a GF, LOL!)

robrokken · 20 Jul 2011

Using pink noise and span, I do see a rollof in the high end when at a near min value, this may be of some use! Now its just gonna take some calibration so that it kinda works all the time, but not too much... just right.

Here is the waveshape for anyone interested:

Leslie147 · 5 Jan 2012

Looking back at some of my oldest efforts with SM, I recalled that the 'De-zipper' module in a much earlier version of SM had not been locked so it could be opened up. Its effect on a square wave is very similar to the current 'De-zipper' module supplied with SM, which looks exponential. See the attached .osm.

Looking inside the (upper) box reveals a relatively-complicated arrangement including a sample-and-hold, a timer, a couple of SR latches, a selector and a piece of code that I don't understand - it looks as though it would output the first sample of the input signal and then repeat its own output signal thereafter! ... which can't be right. There's also an unused input and a commented line of code, which I also don't understand.

Chris