@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.

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.

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.

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.

@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.

@rph-r Pipes and redirection don't work with [command] (or shell) which is why I went with the trick using tee, down to how they quote things for safety reasons, everything after the command is quoted and what you run in that case is exec echo "'bla' >> ~/bli.txt" The lniked thread shows how to work around that limitation with the goal of logging to a text file which seems to be what you are attempting to accomplish? Or is this just a test for something else? Going with Tcl can provide more elegant solutions but if this is for the same project as your other thread you might not have the gui for tcl?

Edit: Might be able to work around this quirk with eval , quick test suggests not but I did not explore it deeply. Command substitution also can not be used with [command].

@rph-r [shell] is fairly limited and has been replaced by [command] which also has limits but far fewer. This thread should offer some insights into the quirks and limitations of [command].

@rph-r For easy printing to the console without backslashes you can use my pdlog plugin/abstraction, it should work just fine on bela assuming you are running pd's gui which I assume you are since you mention printing to the console but don't know much about bela so possibly not. This plugin has the advantage of being able to also print proper error message that come up in red as well as debug and fatal messages. Just drop the files anywhere in your path. This should also be more efficient than alternate vanilla ways of removing those backslashes assuming I actually understand how pd works, offloads it all onto the gui thread which is pd's only other thread unless you use [pd~]
pdlog.zip

Edit: It could possibly hiccup in some situations when trying to print tcl's special symbols (\, $ and the like) but I have never had any issues. An escaped space causes Tcl to make a sublist so the symbol asd\ f comes out in Tcl as {asd {f}} and I went the easy path to flatten it using join which supposedly could cause problems on those symbols. I think it is safe but I was warned about it so I am warning you about it. I think since no processing of the list is being done and we can't use { and } in pd we are safe.

@Element-S said:

I love the Matrix 12 filter implentation, mind blowingly good.

I have been meaning to update that for awhile now, greatly improved the resonance and distortion characteristics but need to put in some time to cut some of those improvements so cpu usage is sane, there is a balance in there somewhere. Will see about finishing it up tonight/tomorrow and will upload it in the polemix thread.

somethin in the class of the Pultec EPQ-1

I kind of like that idea, the fixed frequency bands of the EQP1/MEQ5/old passive EQs and mixers has always appealed to me, I like the workflow. I might play with this, maybe have something up next weekend. Never dawned on me to implement a passive mixer with all of their quirks and limitations in pd, would be a nice break from the DAW and its endless tweaking, getting the cross talk between channels right might be a trick and is a must to make its simple switched left/center/right panning work. Sounds like a fun project, 1930s style studio in pd.

@flextUser just stumbled on my old tcl files with notes about adding menus and menu items so here they are if you still need them. Just the basic Tk menu commands work, I could have sworn pd required you to jump through some hoops.

add new menu:

.menubar insert <index> command -label <label> -command {<command>}

add new menu item to an existing menu:

.menubar.<menu> insert <index> command -label <label> -command {<command>}

Edit: And the popup menu.

set old_args [info args ::pdtk_canvas::create_popup]
set old_body [info body ::pdtk_canvas::create_popup]
rename ::pdtk_canvas::create_popup ""

append old_body {$popupid add command -label <label>}

proc ::pdtk_canvas::create_popup "$old_args" "$old_body"
unset old_args
unset old_body

If memory serves the roundabout way here was because there were some headaches with getting the proper $popupid value so exploiting the everything is a string nature of Tcl was the easier path. Not sure if that was because of my ignorance or actually the case.