Re: [PD] Compressor in Pd

2010-05-19 Thread chris clepper
On Tue, May 18, 2010 at 11:04 PM, Mathieu Bouchard ma...@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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-19 Thread William Brent
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 por...@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





-- 
William Brent
www.williambrent.com

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Compressor in Pd

2010-05-18 Thread Alexandre Porres
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


Re: [PD] Compressor in Pd

2010-05-18 Thread Roman Haefeli
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? 


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread chris clepper
On Tue, May 18, 2010 at 5:54 AM, Roman Haefeli reduzie...@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.

http://en.wikipedia.org/wiki/Parallel_compression
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread Roman Haefeli
On Tue, 2010-05-18 at 07:28 -0400, chris clepper wrote:
 On Tue, May 18, 2010 at 5:54 AM, Roman Haefeli reduzie...@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) ?

 http://en.wikipedia.org/wiki/Parallel_compression


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


Re: [PD] Compressor in Pd

2010-05-18 Thread Paulo Casaes

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 Haefelireduzie...@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) ?

   

http://en.wikipedia.org/wiki/Parallel_compression
 


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
   



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread mark hadman
On 18 May 2010 14:28, Roman Haefeli reduzie...@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 reduzie...@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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread Frank Barknecht
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

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread patrick



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

à+
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread Roman Haefeli
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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread chris clepper
On Tue, May 18, 2010 at 11:01 AM, mark hadman markhad...@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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread Martin Peach

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?

Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Compressor in Pd

2010-05-18 Thread Mathieu Bouchard

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___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list