I am looking for a compressor with adjustable knee (in dB).
@porres maybe an updated version of else/compress~ ?

I want to offer an actual good compiled object for compression... just not in my table right now, but it's on the shopping list

@trummerschlunk Here is an equation I have had in my notes for ages but never tried. Can't test it right now so untested, I do have a tendency to screw up the order of operations when converting to pd but I think I got it. Threshold and knee are in decibels supposedly.
kcomp.pd

And the equation: O = I+(( 1/R-1 )( I-T+K/2 )^2) /2K.

No attack/decay because I have never figured out a way to handle them in pd which I was happy with so when doing compression I implement those on a case by case basis. Would be interested to hear the thoughts of others regarding methods.

Edit: That [inlet~] is envelope in, not raw audio. Or is it? My brain is sluggish today. I am fairly certain it is. I mostly posted it in hope of getting some discussion going on implementing compression, never been happy with our options here but it may meet your needs with a little work.

Almost had this all sorted out, then I crashed pd and lost most of it, thankfully I accidentally hit ctrl-s instead of ctrl-a not too long ago. Redoing that stuff will be for tomorrow. But I am still stuck on a good way to implement Attack and release, so wondering what people can offer there, looking for vanilla ways because I am trying to improve my sorely lacking vanilla audio manipulation skills, preferably ways other than [slop~] since I can't quite wrap my head around it and am looking towards developing my skills with the nuts and bolts.

Remembered that the mmb abstractions has a compressor with knee, not quite sure if knee is dbs though, have not put too much time into examining that patch yet. https://github.com/dotmmb/mmb

Also, there is an error in my patching of the equation above on the ratio, possibly more but even in [expr~] I can not get that equation to work, I got it here on the forum but can't locate the ancient thread it came form at the moment.

Getting there.
kcomp1.pd

Not sure if it actually lines up with the numbers, I cheated and have not measured or done the math; my quick test of a few settings against the plot of a different compressor showed it to line up fairly well but who knows. Got some ideas for the attack/decay to try out and once those are sorted I will concern myself with the details.

Edit: That [- 0] should be a [- 1] and the [*~ 0,5] shouldn't be there. forgot to undo a few tests, it is just a very round about [*~] like that. But I think I got the attack/release sorted out and seems to be working well, will upload it after I give it a once over with fresh eyes.

Possibly complete, at least working. Curious for some feedback, not completely certain everything works as it should but I haven't really put the time into running measurements yet. The smoothing filter will probably be improved and another detection mode added and eventually I will probably switch to using some externals for some of it but probably done with this for a couple weeks beyond the slight tweak/fix. No help file yet, threshold, gain and knee are in dbs, ratio is ratio and everything else is in ms. It can take startup args, look in [pd $0args] for the flags.
kcomp~.pd

A question, what is a digital compressor supposed to do for inputs beyond the -1 to 1 audio range? In the analog world we always have limits imposed by the components and the power supply, we know what the maximums are, but not in digital. As this compressor stands things out of the -1 to 1 range do not work as I would like or expect from my analog sensibility. My instinct says too put an upsampled clipper on the input but I am curious as to what is considered proper in the digital world.

Edit: Just realized I forgot to test the abstraction after some changes and adding creation args, hopefully no stupid errors like last night. No time to test now.

@oid Analogue world sometimes semi-soft clips as you say... especially on magnetic tape, but in the digital world you cannot clip without distortion. So maybe add metering and an input gain.
If you add expansion to your compressor then you should add output metering and gain reduction as the final stage
Some digital compressors also mimic old analogue compressors and add "makeup" gain after the compressor, but that I find hard to work with in a live environment. In the studio it can be useful.
A meter showing the gain reduction of the compressor would also be a nice touch.... visual confirmation of the depth of the effect.
David.

@oid said:

hopefully no stupid errors like last night. No time to test now.

And first object after the inlet is a [*~ 0] that I forgot to delete, really doing a great job at being consistent with this one. And it turns out the attack does nothing and the release affects overall response instead of just release despite this being copy and pasted directly from the patch where I have been developing it and where the attack and release work properly. Would love an explanation as to why, guessing one of those bugs that goes away after restarting pd but which is the bug, the working one or the not working one?

@whale-av Analog world always clips and will do it hard but may do it soft for awhile before it gets to hard. it is limited by the power supply and circuitry. In an analog compressor the gain computer will never see a signal greater than it was designed for, the circuitry before it will just clip it back down to size if you feed it a ridiculously large signal. With this compressor in its current state you can feed it a -200 - 200 signal and it will happily do its job and a very different job than that analog compressor in the same situation which would clip the signal back down to its limits and then let you compress that heavily distorted signal to a level manageable by what ever gear the compressor is running into. We can use this compressor to compress ridiculously large signals to manageable levels but you will probably get aliasing from the heavy gain reduction; upsampled clipping on the input alleviates that, if executed well can help manage troublesome peaks and reduce lookahead/delay of the signal as well.

Not sure if I will make a ui for this, I am trying to keep it generic enough that people can use it to make the compressor they want with it instead of use my idea of a compressor which would lack things like reassuring visual confirmations or knees and would be made fun of by all the other compressors. It is mostly an exercise to get better with the audio side of pd, but I have considered doing a ui so maybe there is a gain reduction meter in the future.

@oid All true. Pd is somewhat exceptional in its dynamic range. Most digital gear is 24-bit, so way less.
Some digital mixers show "0dB" at 18dB below clipping, but not all...
24bit gives 144dB range.... Pd 1528dB...
David.

Sat down to wrap this up yesterday and realized I only implemented the part of the compressor for the knees, so threw that in and refined some things as well. But, sticking the curves together is evading me.

The knee curves and the curve outside the knee are inverted, one goes from 1 to 0 and the other from 0 to 1. The math says you need to add the input to the output but the bottom graph is what you get from that. I can get those knees in every orientation but the right one, it just keeps evading me. This seems a fairly simple thing and I am pretty sure I have done this sort of thing before but I can not quite get it. A nudge in the right direction would be appreciated. Here is the paper I have been working off if you care to look.
https://www.eecs.qmul.ac.uk/~josh/documents/2012/GiannoulisMassbergReiss-dynamicrangecompression-JAES2012.pdf

Dividing the output by the input almost gets me there (no clue why I cut that out, just forgot?) but it needs to be scaled properly, tweaking the (1/R-1) part of the equation should be able to provide that. Seems like I should be able to rework the other part of the equation to make this work but I can't work it. I wish I still had my old graphing calc.

Success?

Not thrilled about those kinks at the transitions but they probably don't matter much and that is using a bit more knee than one would generally use, with common settings things are pretty good. I am guessing this is why the mmb compressor goes about the knee in a more complicated fashion and interpolates instead of just using the [pow 2], still has some kink but less. Perhaps I will play with that at a later date but the next hurdle is attempting to make this switchable between upwards and downwards compression without duplicating everything, I think I can swing it. Will upload it (without upward compression) tomorrow after I do some more testing, think I have had enough stupid oversights and errors for one thread.

Anyone know of any papers on implementing upwards compression? Don't think I need anything but curious to see what has been done.

Edit: actually the kink is mostly because the knee there goes beyond the the threshold, this equation uses W/2 and W*2 for the knee's limits, that pic was T=-12 and W=10, (10*2)-(10/2)=15db knee. Knee smooths up nicely as long as it is smaller than threshold. The mmb way causes the ratio to effectively start increasing once knee width exceeds threshold where mine does not start affecting ratio until you exceed waveform peak. Interesting tradeoffs, I think I might keep the kinks, if they become audible it means you really should be adjusting your threshold and ratio, not your knee. The mmb method sort of gives you this weird area where threshold, ratio and knee all become the same thing.

@FFW I have never been able to make the move to software for this task, tried a few times and I always end up getting out the graph paper and colored pencils instead. I should just ebay a ti-89 or the like, assuming they are not going for ridiculous prices. Should be noted, this reply was done before the edit, I actually wrote it before you posted.

@oid https://www.geogebra.org/graphing