Attack/decay algorithm question

[Digital Larry]

I've been messing around with the MAXX instruction recently, doing a peak detector for a customer's auto-wah. I finally realized that this instruction includes a low pass filter in it. Many of the discussions about the coefficient simply say "long" or "short" and while it's most likely obvious that this coefficient is the same that you would use with a RDAX/WRAX pair, I thought I'd supply some helpful equations for the literal minded amongst you.

Assuming the decay time of the filter is how long it takes to go from 1.0 to 1/e, which is about 36.8%...

c = e^(-1/t) where t is the fall time in SAMPLES.

Suppose you want this to be 100 msec. That's 3277 samples at 32768 Hz fs, so c = 0.999695
For 50 msec, c = 0.9993897

So there's going to be a practical maximum rise time imposed by the quantization of that coefficient. I haven't figured out what it is but the above examples are getting close.

That was just background information. The discussion here is how to go about making an attack/decay filter so the rise time is slowed down a bit compared to just using the peak detector on its own.

One way is to run the attack LPF in series into the decay peak detector/LPF.
The other way would be to drive both of those filters from the same source and then use MAXX to pick the max, and use a coefficient of 1.0 in order to simply follow the decay filter on the way down.

I think putting them in series would delay the transition from attack to decay a bit. Maybe even double it?
Anyone done this? Is there a general preference for how to go about this?

thx,

DL

[frank]

RMS detector, you can adjust the LP coefficient used for averaging to control attack/decay time

The FXCore sample auto-wah code I did should be able to be used as a template for some FV-1 code. http://experimentalnoize.com/manuals/FX ... to_wah.fxc

[Digital Larry]

Thanks Frank! Another question on MAXX:

I get why you'd use C = 1.0 or 0 < C < 1.0 but I'm having a hard time imagining the application for C < 0 or C > 1.0 UNLESS it was simply used for some kind of comparison without subsequently writing the value back to the same register.

DL

[frank]

The reason we allowed for C < 0 and C > 1.0 is simply because it was already defined for that range in the instruction field (note the other instructions in that group are all S1.14) and it was easier to allow it as well. Someone may some day discover a use for C in those ranges but honestly it was a matter of avoiding adding more gates and complexity to the core.

[Digital Larry]

Makes sense!

Thx.

DL