Peak Detection Release/Decay

[Perfect Human Interface]

I'm working on something that utilizes peak detection right now. I have a couple of "peak detectors" made by others (one by cytosonic and one by Trog) that do their job well, and even have built-in "decay" settings I can tweak, but I've found that these decay in a logarithmic scale when I take a 0-1 range output from them. If I convert the value to dB scale it decays linearly but then the values are dB scaled (i.e. 50% would be at -6 in a 0 to -48 scale rather than right in the middle).

What I want is to be able to have a linear 0-1 scale output that also decays linearly. In addition to that, I'd also like to add a similar "attack" function. What would be the best way to go about this? Should the peak detection codes themselves be re-written? (Both are in Assembler which I unfortunately know nothing about at this time.) I know there are some other ways to "slide" between values... I've always just cheated and used the de-zipper primitive in the past for "smoothing" stuff but that won't work here since I'd need separate attack/decay parameters.

So I'm just looking for some advice/direction on what the best approach may be here. TIA.

[KG_is_back]

most envelope detectors are based on applying 1-pole lowpass on a absolute value of the signal. 1-pole lowpass naturally has exponential decay ( 1, 0.5, 0.25, 0.125,... or similar). You can create linear decay by treating the attack and release coeficients as constants rather than like coeficients.
code would look somehow like this:

Code: Select all

normin=abs(in);
c=attack&(normin>out)+release&(normin<out); //note: the c is zero if normin=out
out=out+c;


However, this algorithm has a flaw - if input is held, the output will oscillate around this value possibly failing to reach it (as it can only add or subtract value equal to attack or release). If you choose big attack and release coeficients the precision of peak detection will be poor.

one fix might be:

Code: Select all

normin=abs(in);
c=attack&(normin>out)+release&(normin<out);
c=c+(normin-out-c)&(abs(normin-out)<abs(c)); //I do not know if the absolute values are really necessary
out=out+c;


now if the step to reach exact peak value is smaller than the actual coefficient (the 'c') the exact value of difference will be used for the coefficient. Therefore if input is held on a value the output will reach it and hold it.

Problem of linear attack and release is, that it is not defined in "length" but rather in "angle" at witch the output decays.

[Perfect Human Interface]

However, this algorithm has a flaw - if input is held, the output will oscillate around this value possibly failing to reach it (as it can only add or subtract value equal to attack or release).

I see. The peak detectors I was using seem to do this as well though. They'll fluctuate a bit with a sine input, quite rapidly at low release settings.

If you choose big attack and release coeficients the precision of peak detection will be poor.

Hmm... but that seems inherent to what you're doing. If you have long attack/release you're intentionally sacrificing precision for smoothness, no?

So what I observe is that the current peak detectors will fluctuate a lot with a sine input but the higher the release coefficient the more the fluctuation is reduced, which is logical.

I'm not sure how the method you suggested would differ in this. But maybe the "fix" will indeed be just that.

I probably should have started off with understanding just how basic peak detection works.