Hi, anyone know of any good patches or objects for compression in Pd? thanks
Hi
On Tue, 2010-05-18 at 02:57 -0400, Alexandre Porres wrote:
Hi, anyone know of any good patches or objects for compression in Pd? thanks
zexy comes with [limiter~]
I also tried to implement a compressor as an abstraction. You can either download it here http://www.netpd.org/Dynlib (rcomp) and un-netpd-ize it. Or you can alternatively take the version included in pdmtl called 'fx.compressor~.pd'. It's in the svn-repos/abstractions/pdmtl.
Roman
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?
On Tue, May 18, 2010 at 5:54 AM, Roman Haefeli reduzierer@yahoo.de wrote:
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?
That sounds like parallel (or New York) compression, which is far from being wrong. It allows for an increase in RMS without affecting the source's transient response, and in many cases this technique is far superior to series compression. A fair majority of rock/pop records of the past quarter century have had parallel compression applied to the drum bus.
In the box, latency has to be compensated for though, so you will have to delay the source to properly mix with the compressed output. You can simply send the 'dry' signal through the same compression with a 1:1 ratio and high threshold to achieve this.
On Tue, 2010-05-18 at 07:28 -0400, chris clepper wrote:
On Tue, May 18, 2010 at 5:54 AM, Roman Haefeli reduzierer@yahoo.de wrote:
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?That sounds like parallel (or New York) compression, which is far from being wrong. It allows for an increase in RMS without affecting the source's transient response, and in many cases this technique is far superior to series compression. A fair majority of rock/pop records of the past quarter century have had parallel compression applied to the drum bus.
In the box, latency has to be compensated for though, so you will have to delay the source to properly mix with the compressed output. You can simply send the 'dry' signal through the same compression with a 1:1 ratio and high threshold to achieve this.
I don't fully understand that last sentence: why sending the dry signal through a compression (which makes it not dry anymore) and how does threshold matter, when the ratio is 1:1 (which is basically the same as sending the signal not through a compressor at all) ?
Ok. I stand corrected. Thanks for the link. I was definitely wrong by saying, that it doesn't make sense to mix the dry signal with the compressed signal. Indeed, the effect is different from just 'destroying' the effect of the compressor (which is - simply said - lowering the output gain the higher the input gain is). With parallel compression the ratio between input and output gain above threshold is not linear anymore, but tends towards 1:1 the louder the input signal is. Or in other words: the ratio is dependent on the input gain.
Roman
I made a saturator compressor (a non linear compressor) a few years ago
http://puredata.info/Members/saturno/saturator-non-linear-compressor http://puredata.info/Members/saturno/saturator.zip/view
It's an external.
Paulo
On 18/05/2010 10:28, Roman Haefeli wrote:
On Tue, 2010-05-18 at 07:28 -0400, chris clepper wrote:
On Tue, May 18, 2010 at 5:54 AM, Roman Haefelireduzierer@yahoo.de wrote:
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?That sounds like parallel (or New York) compression, which is far from being wrong. It allows for an increase in RMS without affecting the source's transient response, and in many cases this technique is far superior to series compression. A fair majority of rock/pop records of the past quarter century have had parallel compression applied to the drum bus.
In the box, latency has to be compensated for though, so you will have to delay the source to properly mix with the compressed output. You can simply send the 'dry' signal through the same compression with a 1:1 ratio and high threshold to achieve this.
I don't fully understand that last sentence: why sending the dry signal through a compression (which makes it not dry anymore) and how does threshold matter, when the ratio is 1:1 (which is basically the same as sending the signal not through a compressor at all) ?
Ok. I stand corrected. Thanks for the link. I was definitely wrong by saying, that it doesn't make sense to mix the dry signal with the compressed signal. Indeed, the effect is different from just 'destroying' the effect of the compressor (which is - simply said - lowering the output gain the higher the input gain is). With parallel compression the ratio between input and output gain above threshold is not linear anymore, but tends towards 1:1 the louder the input signal is. Or in other words: the ratio is dependent on the input gain.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, May 18, 2010 at 11:21:53AM -0300, Paulo Casaes wrote:
I made a saturator compressor (a non linear compressor) a few years ago
http://puredata.info/Members/saturno/saturator-non-linear-compressor http://puredata.info/Members/saturno/saturator.zip/view
It's an external.
And to add another one: The rj library of abstractions has e_scompress.pd as a very simple compressor and e_dynproc.pd which is a dynamics processor that can be used as compressor, limiter, expander or noisegate depending on the settings. Both have sidechains. e_dynproc also has a dry/wet regulator, but it doesn't delay the dry signal. I guess, I'll change that after having read this thread. :)
And btw. the rj library has a new home now: It's now available at rjdj's github page: http://github.com/rjdj/rjlib as a git repo for forking and as a tar.gz/zip download.
Ciao
Frank
On 18 May 2010 14:28, Roman Haefeli reduzierer@yahoo.de wrote:
On Tue, 2010-05-18 at 07:28 -0400, chris clepper wrote:
On Tue, May 18, 2010 at 5:54 AM, Roman Haefeli reduzierer@yahoo.de wrote:
It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay).
[SNIP]
In the box, latency has to be compensated for though, so you will have to delay the source to properly mix with the compressed output. You can simply send the 'dry' signal through the same compression with a 1:1 ratio and high threshold to achieve this.
I don't fully understand that last sentence: why sending the dry signal through a compression (which makes it not dry anymore) and how does threshold matter, when the ratio is 1:1 (which is basically the same as sending the signal not through a compressor at all) ? ;
The point is to split the signal through two digital compressors, one wet (ie with a ratio of more than 1:1) and the other 'dry'. In this way both the wet and dry signal have the same processing delay, thus avoiding the phase cancellation issues when they are recombined in the main mix bus.
That aside, there's a much easier way to preserve transients - just slow down the compressor's attack time....
On Tue, May 18, 2010 at 11:01 AM, mark hadman markhadman@googlemail.comwrote:
That aside, there's a much easier way to preserve transients - just slow down the compressor's attack time....
This is still quite different than parallel compression. One can have fast attack times with high ratios yet still have the transient response of the dry sound. Parallel compression is a fundamental audio engineering 'trick' responsible for massive drums sounds (Bonham 'When the Levee Breaks', the snare sound on Bowie's 'Let's Dance', etc).
Unfortunately, DSP compression is absolutely horrid compared to analog boxes like an API 2500 or ADR Compex - let alone the old tube gear like a 176.
On Tue, 18 May 2010, Martin Peach wrote:
chris clepper wrote:
Unfortunately, DSP compression is absolutely horrid compared to analog boxes like an API 2500 or ADR Compex - let alone the old tube gear like a 176.
Why do you think that is? What is missing in the digital version?
the digital version doesn't sufficiently deviate from the theoretical model...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, May 18, 2010 at 11:04 PM, Mathieu Bouchard matju@artengine.cawrote:
On Tue, 18 May 2010, Martin Peach wrote:
chris clepper wrote:
Unfortunately, DSP compression is absolutely horrid compared to analog boxes like an API 2500 or ADR Compex - let alone the old tube gear like a 176.
Why do you think that is? What is missing in the digital version?
the digital version doesn't sufficiently deviate from the theoretical model...
More like the digital version lacks sufficient complexity in response.
Roman
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?
yes i do agree. for me it was important to have wet/dry for all fx, but of course it doesn't make sense for all fx.
there's mtl also available: http://puredata.info/Members/mtl/index_html
à +
On Tue, 2010-05-18 at 11:12 -0400, patrick wrote:
Roman
P.S.: @pdmtl guys It's plain wrong to have a wet/dry parameter for dynamic processing fx. It just doesn't make sense at all to have the compressor output mixed with the input signal (It not only doesn't make sense, it even adds strange phasing effects, if the the dynamic processor uses a look-ahead delay). Can we agree on that? And if not, can we discuss this, so that we finally can agree on that?
yes i do agree. for me it was important to have wet/dry for all fx, but of course it doesn't make sense for all fx.
there's mtl also available: http://puredata.info/Members/mtl/index_html
Hi Patrick
As Chris Clepper, Harris Pilton and others pointed out, there is a valid use for this implementation, which even has a name: parallel compression.
I was probably thinking too much inside the box: Effects, that 'add' something to a signal deserve a 'wet/dry' controller, whereas effects that only modify the signal shouldn't have one. In the case of the compressor, you cannot add more or less compression with a 'wet/dry' controller (which is why I defeated the usefulness of it), but when implemented properly (no phase shift between dry and wet signal) it modifies the type of compression, which can be useful.
So, I rephrase my initial question: Can we agree on keeping it in? ;-)
Roman
There's also +compand~ from the port of Tom Erbe's soundhack VST plug-ins:
http://www.soundhack.com/externs.php
On Mon, May 17, 2010 at 11:57 PM, Alexandre Porres porres@gmail.com wrote:
Hi, anyone know of any good patches or objects for compression in Pd? thanks _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Porres -
chris clepper -
Frank Barknecht -
mark hadman -
Martin Peach -
Mathieu Bouchard -
patrick -
Paulo Casaes -
Roman Haefeli -
William Brent