Howdy, I'm giving a try at how to implement a compressor as a Pd patch. This is what I came up with, it needs cyclone 0.3! ==> compression~.zip

I'm using rms average to detect the gain level and rampsmooth~ to perform attack/release. I wouldn't know how to do it in Vanilla...

Seems rough and rudimentary. It's more of an intuitive approach, as I don't know much about compressor design.

I'm hoping to get feedback from you people on how to implement a compressor in Pd as a patch and how and why this approach is "ok" and can be improved, or if it's all terribly wrong.

Are there any other attempts to implement compession in Pd out there?

Thanks
Cheers

@porres Explanation and patch from @katjav is now updated for Vanilla....... http://www.katjaas.nl/compander/compander.html
The main problem in the digital domain is knowing the power of the signal in advance so as to reduce it according to that power. It can be done but introduces a delay to the signal that will be disturbing in a live environment, or it is not done and a fast attack will get through the compressor.
That looks (no delay) to be the case with the cyclone abstraction.
It can be acceptable..... analogue compressors have an "attack" control that controls the delay before compression, but in the digital domain you normally have no choice.
She has solved that problem.
David.

@porres you can try my compressor/expander abstraction dynamics.zip It uses the same Olli Niemitalo's quadrature transformer from @katjav for peak detection and an amplitudes lookup table. The fexpr~ works like cyclone/rampsmooth~

@whale-av "The main problem in the digital domain is knowing the power of the signal in advance so as to reduce it according to that power. It can be done but introduces a delay to the signal that will be disturbing in a live environment"

It can be done without a delay, the main problem is how to set attack and release times seperatly. It can be done with a slew filter like [cyclone/rampsmooth~] or something like [fexpr~ max($f2, min($f3, ($x1-$y1[-1])))+$y1[-1] ] in vanilla. If you don't need separate attack/release parameters, you could just use a lowpass filter. This filter also acts as the averaging filter for the amplitude detection, so there is no need to average the amplitude beforehand like in @porres patch.
Of cause, very short attack/release times would induce distortion, but this is often desired as the "characteristic sound" of a compressor.

@porres And I forgot that [limiter~] from the zexy library was a lightweight, easy to use compressor back in the days of extended. The compressor settings were buried in a sub-patch in the help file. It might not be updated for 64-bit though.
@solipp Thank you for the correction.
David.

it's messy, but possible, to use a single sample delay with clipped feedback to generate a typical compressor envelope. i don't have this patched up in an intelligible way but i could clean it up if anyone is interested.

Not sure if this is of any use, but someone sent me this a while ago: http://designingsound.org/2013/06/tutorial-a-compressor-in-pure-data/

I never really got the hang of using it though. But it is Vanilla!

also worth mentioning is compressor.mmb~ from https://github.com/dotmmb/mmb This one has a soft knee function implemented but it needs some externals.

@LarsXI thats what's happening in the fexpr~ i mentioned above. slewfilter.pd