Hello,

Some time ago I did an expander/compressor/limiter abstraction. It proved to serve well, therefore I'd like to share it now. It is done with an experimental technique using an analytic signal, hence the term quadrature compander, in short [qompander~] for the abstraction. It is just a mono, single band compander. Fast response is it's major characteristic.

The abstraction uses two objects specific to Pd extended: [expr] and [cyclone/pow~]. A help patch is included, with test signals and some demo presets which should give an impression of the compander's possibilities.

Illustrated documentation is at http://www.katjaas.nl/compander/compander.html

qompander~.pd and qompander~-help.pd are in the attached zip file.

Katja

update: as Maelstorm indicated, [expr] is in vanilla Pd. However, I found yet another Pd extended object in my patch, [iemlib/peakenv~]. I will soon upload a vanilla version of the compander.

http://www.pdpatchrepo.info/hurleur/qompander.zip

can you explain this 'analytic signal' process? I'm interested in compressor design in the digital domain.

Thanks

Just so you know, [expr] is included in vanilla, and you can also replace [pow~] with [expr~ pow($v2, $v1] (inlets reversed). Doing it that way will make both vanilla and extended compatible.

btw, your page is quite nice. I'm looking forward to trying this thing out.

vanilla-compatible version of [qompander~]

Maelstorm, I have always overlooked [expr] in vanilla Pd. Thanks for your hint. I replaced [cyclone/pow~] with [expr] to make [qompander~] vanilla-compatible, as you pointed out. Then I found [iemlib/peakenv~] in my abstraction. This is replaced by more [expr] and [fexpr~].

But, since the patch with [fexpr~] is considerable more CPU-intensive, the old Pd extended compatible version is conserved under the existing name [qompander~] and the vanilla compatible version, attached to this message, is called [vqompander~].

Katja

http://www.pdpatchrepo.info/hurleur/vqompander.zip

Arif, I collected info on analytic signals (also called complex signals) on my page

http://www.katjaas.nl/hilbert/hilbert.html

If you are interested in compressor design in the digital domain, you should probably treat my technique as a curiosity, because it is highly experimental. I just modeled [qompander~] according to my needs, which are: fast response, expander/compressor/limiter in one operation.

The zexy library in Pd extended has [limiter~] which also does compression so you could have a look at it's source code as well.

Katja

Thanks katjav.

Over my head as per usual. but thank you so much for the pointers nonetheless

great thanks

i wonder why you don't use a simpler non phase confusing technique like in my attachment
it's heart is an self made peakenv~ with hold
currently it only normalises every signal to an amplitude of 1 but this can easily be changed

but well i don't really understand what your transform does
for me it isn't more than a complex way to make a peakenv~ with a short hold

http://www.pdpatchrepo.info/hurleur/slur-compander-idea.pd

Hey Slur,

Thanks for your feedback. You are completely right, the quadrature compander is a complex way to make a peakenv~ with a short hold.

Because the quadrature compander operates with amplitudes instead of absoluted sample values, it even needs no hold time at all, and only a very short decaytime if so desired. Sure I have compared this with regular peak-hold-and-decay method.

In practice, the quadrature method served some of my purposes better. Like superfast compression/limiting/noise suppression for microphone input in a noisy live situation. And with extreme settings for compander factor and dBpoint, it is effective in cutting sharp amplitude decay to beats, without distortion. The complex signal method definitely produces artefacts, but in many cases my signal profits from the treatment. If a regular compander is a hifi set, the quadrature compander is a guitar amp.

Katja

well faster than my peakenv in the example patch can't be because it is sample accurate (well as i don't understand the hilbertransform maybe it can predict the future?
also this idea was to just replace the whole olli transform + peakenv with a peakenv with hold and then feed its signal through the same shaping function like in your quadrature compander
or at least replace the peakenv in the qc with one with hold

but i didn't test how cpu intensive the fexpr solution is..

p.s. your use of one sample delay might be not so samplerate independent

those are the versions i imagined
sqompander is yours only with a hold peakenv
and sompander is the version with only the hold peakenv

now someone needs to analyse and compare all 3 against each other

http://www.pdpatchrepo.info/hurleur/sompander~.pd

those are the versions i imagined
sqompander is yours only with a hold peakenv
and sompander is the version with only the hold peakenv

now someone needs to analyse and compare all 3 against each other

http://www.pdpatchrepo.info/hurleur/sompander~.pd

well... first test show
sompander is crap because it introduces clipping in attack sections
sqompander uses 30% more cpu than qompander
... in the best case..
the worst cases are random and prolonged jumps up to 200% which means 160% more than qompander

this could maybe reduced slightly through using + instead of * for the hold counter

...damn

http://www.pdpatchrepo.info/hurleur/slur-is-compandering.pd

Slur, with 'fast' I just mean qompander's response and recovery time can be set very short without harmonic distortion.

With a samplevalue-peak-hold-and-decay method like in sompander, you need to delay the original signal, say with 64 samples (exact amount is not very critical) to get rid of that clipping in the attack. I've learned that from zexy/limiter~'s help patch.

With the amplitude-peak-envelope method in qompander, there is an artefact in the attack as well. But since the amplitude is under control, it does not clip. In the 'worst' case it adds some extra punch, I do not hate that!. That is why I leave the artefact there, and do not cut 64 samples of the attack. For the decay part, a more or less similar reasoning holds. Times can be very short with little or no harmonic distortion. It can manipulate dynamics to the extreme, like a producer's tool.

I appreciate your suggestions, Slur. It would be great if we could together invent the uebercompander~.

Attached is my non-quadrature compander~ which has some elements of limiter~. It has a lot in common with sompander~ as well. I found that both qompander~ and compander~ do not produce a sound so clean as limiter~. I wonder why that is. limiter~ does oversampling of the analysed signal but I doubt whether this makes the difference. Anyway, limiter~ does not have that smooth compander curve, it's hard-knee compression/limiting.

Katja

http://www.pdpatchrepo.info/hurleur/compander~.pd

Slur, with 'fast' I just mean qompander's response and recovery time can be set very short without harmonic distortion.

With a samplevalue-peak-hold-and-decay method like in sompander, you need to delay the original signal, say with 64 samples (exact amount is not very critical) to get rid of that clipping in the attack. I've learned that from zexy/limiter~'s help patch.

With the amplitude-peak-envelope method in qompander, there is an artefact in the attack as well. But since the amplitude is under control, it does not clip. In the 'worst' case it adds some extra punch, I do not hate that!. That is why I leave the artefact there, and do not cut 64 samples of the attack. For the decay part, a more or less similar reasoning holds. Times can be very short with little or no harmonic distortion. It can manipulate dynamics to the extreme, like a producer's tool.

I appreciate your suggestions, Slur. It would be great if we could together invent the uebercompander~.

Attached is my non-quadrature compander~ which has some elements of limiter~. It has a lot in common with sompander~ as well. I found that both qompander~ and compander~ do not produce a sound so clean as limiter~. I wonder why that is. limiter~ does oversampling of the analysed signal but I doubt whether this makes the difference. Anyway, limiter~ does not have that smooth compander curve, it's hard-knee compression/limiting.

Katja

http://www.pdpatchrepo.info/hurleur/compander~.pd

well you could always multiply the input signal for limiter~ and then scale back and shape its output with whatever curve you want

what features should this übercompander have?
i dont think that i'm good enough to extend what you can do
but thanks for asking

i like to put a noisereduce from hardoffs diy2 as the first thing after a adc~
dont know/understand what it does tho

funny hold in your compander... you know there is no need to do weird fexpr (like i did) or similar to do a peakenv_hold~ because it is already in extended
there is no need to do any division by zero protection because /~ and expr / output 0 when a /0 occurs and if we have a 0 amplitude it doesn't matter

also i would like a stronger attenuation... but i think i can add this myself like the peakenv_hold~

and a little performance improvement could be done through removing all time independent functions like clip and doing the mapping through a tabread4~ after the lop~... but i guess the array should be in the db domain or it would get far too large if we want to account for as large as 200db

well well.. and i just wanted to write: there needs no ubercompander... maybe some peakenvhold... but thats enough i think

i did some qompandering and found some weirdness: see the attached patch

also the clip after pd pyth~ could be replaced by a max~ 1e-5 or just been thrown out altogether (like in my last post)
and the help patch should be named qompander-help~ not qompander~-help

thats all for today.. bye

http://www.pdpatchrepo.info/hurleur/slur-is-qompandering.pd

@slur said:

and the help patch should be named qompander-help~ not qompander~-help

Why? There's nothing wrong with that.

Thanks for testing Slur. Your patch shows that qompander~ can not handle excessive DC steps properly. Interesting matter. I have checked that compander~ the not-quadrature version can not handle this as well. It is not the DC level of say 200 dB itself (amplitude 100000 times unity) which is the problem, but the steps, the discontinuities. Although this is not regular use of a compander, the problem points to subtle but irritating artifacts which I could not reproduce in test conditions but which I heard in real life sound processing. I also checked limiter~ against your test conditions. Limiter~ can handle this. Now I am beginning to believe that limiter~'s convolution routine is crucial. After all, such extreme DC steps like in your test patch would be smoothened with convolution.

So, possibly we need limiter~'s convolution combined with qompander~'s curve and amplitude method but compensated for the phase distortion, to get fast and good quality noise reduction / compression / limiting. Can we do a FIR filter with Pd objects?

[clip~ 1e-05 100] can be replaced by [max~ 1e-05] that's right. The minimum value is there to prevent instability with very small numbers division which is more than a theoretical problem. The help patch name is qompander~-help otherwise Pd can not find that patch from the right-click menu.

Katja

@katjav said:

Can we do a FIR filter with Pd objects?

You can do them with [rzero~] and [czero~]. You should be able to do them with [fexpr~] as well, though my guess is it would be more cpu intensive.