or use wider samples at the soundcard
or create an output transfer function
    that has tollerable distortion.


kelly

On Wed, 10 Aug 2011, Dennis Raddle wrote:

> I didn't realize a similar question has already been asked.
>
> Let me make clear that my question is about live playback, so there is
> no choice either to set a very low level, or use a compressor of some
> sort.
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Along with the discussion of mastering, I have a question about
possible use of compression to limit peak amplitude during live
playback.

The general problem I encounter is this. Suppose I am playing a Csound
instrument via midi, and at any one time there may be only one quiet
note playing, or 10 loud notes. And I don't want to clip the output.
So I have to set the output level of the instrument pretty low. Would
it be possible to use a compressor as a way of gracefully limiting
peak output (without clicks/distortion) and allowing for a higher
average output level? I would imagine that during loud music, it's
only a small proportion of the samples that clip.

Dennis


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I didn't realize a similar question has already been asked.

Let me make clear that my question is about live playback, so there is
no choice either to set a very low level, or use a compressor of some
sort.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Compressor/limiter, yes. But I'm no expert on the optional settings.

I've just done a little testing, and the compress opcode seems to work well.
I'm able to bang on the keyboard and not get any clipping. I'm routing the
output of the instrument(s) through an output "instrument" that applies
compression to the entire signal.

The tricky bit with compress is that it assumes 0dbfs=32768. Since I
normally use 0dbfx=1.0, my output mixer instrument has to perform an
additional adjustment to the input and output levels of compress. Here's the
code that's working for me:

instr 201		; output compressor

ainL = gaRevOutL + gaSynthOutL
ainR = gaRevOutR + gaSynthOutR
gaSynthOutL = 0
gaSynthOutR = 0

; get rid of DC:
ainL	atone	ainL, 10
ainR	atone	ainR, 10

ainL = ainL * 32768
ainR = ainR * 32768
aoutL	compress	ainL, ainL, 0, 60, 76, 2, 0.001, 0.05, 0.005
aoutR	compress	ainR, ainR, 0, 60, 76, 2, 0.001, 0.05, 0.005
aoutL = aoutL / 32768
aoutR = aoutR / 32768
		outs	aoutL, aoutR

endin

Note that the reverb bus doesn't have to be zeroed, because the reverb is
running monophonically. Also note that compress may perform better with a
higher value for ilook (0.005 here), but that will introduce more latency
when you're playing a MIDI keyboard. 5ms seems a decent compromise.

Hope this helps.

--Jim Aikin

--
View this message in context: http://csound.1045644.n5.nabble.com/compression-tp4687419p4691319.html
Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hello,

the bug with compress and 0dbfs=1 is now fixed in the GIT version by Victor Lazzarini and it works well. http://sourceforge.net/tracker/?func=detail&aid=3349333&group_id=81968&atid=564599john 

If you are able to compile the source again, you can use your code it without the 32768 multiplication. (For any case I attach the corrected compress.c code from source folder Opcodes)

In fact,  how is it possible to compile just one bit of the source like 'make compress'?
I have not found a solution with scons this way.

At this case it would be enough to compile new libcompress.so (or .dll) and copy it to the opcodes directory ($OPCODEDIR64) and building the whole package would not be necessary at all.

As for compression, I have used  compress as limiter as well and it works pritty nicely:

gasig1 compress gasig1,gasig1, 0,89,89, 100, 0.01, 0.1, 0.05

just sometimes some high sample slip through.

greetings,
tarmo



On Friday 12 August 2011 01:27:00 Jim Aikin wrote:
> I've just done a little testing, and the compress opcode seems to work well.
> I'm able to bang on the keyboard and not get any clipping. I'm routing the
> output of the instrument(s) through an output "instrument" that applies
> compression to the entire signal.
> 
> The tricky bit with compress is that it assumes 0dbfs=32768. Since I
> normally use 0dbfx=1.0, my output mixer instrument has to perform an
> additional adjustment to the input and output levels of compress. Here's the
> code that's working for me:
> 
> instr 201		; output compressor
> 
> ainL = gaRevOutL + gaSynthOutL
> ainR = gaRevOutR + gaSynthOutR
> gaSynthOutL = 0
> gaSynthOutR = 0
> 
> ; get rid of DC:
> ainL	atone	ainL, 10
> ainR	atone	ainR, 10
> 
> ainL = ainL * 32768
> ainR = ainR * 32768
> aoutL	compress	ainL, ainL, 0, 60, 76, 2, 0.001, 0.05, 0.005
> aoutR	compress	ainR, ainR, 0, 60, 76, 2, 0.001, 0.05, 0.005
> aoutL = aoutL / 32768
> aoutR = aoutR / 32768
> 		outs	aoutL, aoutR
> 
> endin
> 
> Note that the reverb bus doesn't have to be zeroed, because the reverb is
> running monophonically. Also note that compress may perform better with a
> higher value for ilook (0.005 here), but that will introduce more latency
> when you're playing a MIDI keyboard. 5ms seems a decent compromise.
> 
> Hope this helps.
> 
> --Jim Aikin
> 
> --
> View this message in context: http://csound.1045644.n5.nabble.com/compression-tp4687419p4691319.html
> Sent from the Csound - General mailing list archive at Nabble.com.
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"