This is/was (among other things) what the PEAK chunk is/was for. Write 
floats to a file, without clipping, and with PEAK info. When a file with 
the PEAK chunk was read into Csound, if the peaks were over-range they 
were automatically rescaled. This was all working back in v4.23. 
Doubtless with the move to libsndfile that code has all gone (though the 
original structure field "do_floatscaling" seems still to be around), 
but in principle it should be able to be reintroduced (libsndfile does 
know about the PEAK chunk so Csound can still obtain that info). But 
then users have to get used to having the PEAK chunk in their files 
(some really old naff software might not understand, and fail to read 
the file properly), and I saw quite a lot of resistance to that.

Of course for real-time rendering, there is no solution other than to be 
careful, or apply some sort of limiter. And limiters are not exactly 
transparent.  Csound has historically been an "open" system in that it 
does not hold your hand - "with great freedom..." etc.


Richard Dobson

On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
..
>
> Back in the day, Matt Ingalls used to have an option in MacCsound where
> you could render to floats, and then it would do a float to int
> conversion prior to playback - and this gave a lot more headroom - and a
> lot less pain, but...... is there a way to solve this problem at a
> deeper and yet more transparent level. In Csound or PortAudio or QuteCsound.
>




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

I agree it would be great to have some sort of protection... I'm sure
we've all blown our ears at least once using csound....

But I'm not sure how it would be implemented, since it depends greatly
on the monitoring level. No matter how quick and effective a limiter
is, it can't know the level the user is monitoring at, so it can't
really offer any real protection, because when people are working,
they might be working with very soft sources, and therefore turn the
monitoring level high up, and then when a much larger source comes
through, even if it's not a really loud one under other conditions, it
will blow the person's ears.

So what I mean to say is that in practice, to have such a protection,
you must know beforehand the monitoring level, or the maximum
permitted amplitude (in the case of speaker protection), but for
Csound where monitoring levels are so variable, such a system is not
possible. The best thing, would be as part of the introductory csds
have a way of scaring people a bit about the huge dynamic range Csound
can produce, without actually doing any damage, but enough of a scare
that they will be careful when monitoring (look at the meters first,
make sure you are not working at too low amplitudes and high
monitoring levels, etc.)

Anyone want to write such a csd?

Cheers,
Andrés

On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
 wrote:
> OK this is kind of not related but I found a weird bug either with csladspa
> or aurdour, or both. When I copy a csladspa plug-in form one channel strip
> of Ardour to another, there is this massive explosion and then Ardour
> crashes. So there you go, you don't always have the option of pre-scoping.
>
> Well what the hell, I like to live dangerously and that's certainly possible
> with Csound ;-)
> Best,
> Peiman
>
> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>
> But if "blow-up insurance" is built back into Csound, it would ruin the
> hilarity of the "basic proficiency test" that takes place during the point
> in class that Dr. B describes! I was in last semester's class... he left the
> room and it was like a game of whack-a-mole of people yelling curse words
> and horrendous square waveforms coming out of headphones...
> This is why I scope every .csd I make. Step 1, mute speakers and run csd.
> Step 2, look at scope. If the scope is straight up and down lines, DO NOT
> UNMUTE. Step 3, if the coast is clear, unmute!
> It's charming... kinda.
> -Nick
>
> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>  wrote:
>>
>> This is/was (among other things) what the PEAK chunk is/was for. Write
>> floats to a file, without clipping, and with PEAK info. When a file with the
>> PEAK chunk was read into Csound, if the peaks were over-range they were
>> automatically rescaled. This was all working back in v4.23. Doubtless with
>> the move to libsndfile that code has all gone (though the original structure
>> field "do_floatscaling" seems still to be around), but in principle it
>> should be able to be reintroduced (libsndfile does know about the PEAK chunk
>> so Csound can still obtain that info). But then users have to get used to
>> having the PEAK chunk in their files (some really old naff software might
>> not understand, and fail to read the file properly), and I saw quite a lot
>> of resistance to that.
>>
>> Of course for real-time rendering, there is no solution other than to be
>> careful, or apply some sort of limiter. And limiters are not exactly
>> transparent.  Csound has historically been an "open" system in that it does
>> not hold your hand - "with great freedom..." etc.
>>
>>
>> Richard Dobson
>>
>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>> ..
>>>
>>> Back in the day, Matt Ingalls used to have an option in MacCsound where
>>> you could render to floats, and then it would do a float to int
>>> conversion prior to playback - and this gave a lot more headroom - and a
>>> lot less pain, but...... is there a way to solve this problem at a
>>> deeper and yet more transparent level. In Csound or PortAudio or
>>> QuteCsound.
>>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> --
> Nick Suda
> Renton, WA/Boston, MA
> nick.suda@gmail.com
> (425) 941-0093
>
>



-- 


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

The best way of scaring poeple:

I saw a couple a few years ago at the Bourges festival, they were  
performing a joint electroacoustic composition.

After some enquiry it turned out that one of them had lost her hearing  
after a studio session when a maxmsp patch, which didn't have  
protection built into it, had blown the speakers away. Not a pleasant  
story.

I agree that the caution must come from the user as there is no way of  
protecting the csd. Also of course I would advice against headphones  
in any case. In our studio at City we have one of those systems with a  
db-meter in the room, which turns everything off if the volume goes  
above a certain level.

alas I haven't got such a system at home so have to be very careful.

Best,

Peiman



On 19 Feb 2010, at 11:39, Andres Cabrera wrote:

> Hi,
>
> I agree it would be great to have some sort of protection... I'm sure
> we've all blown our ears at least once using csound....
>
> But I'm not sure how it would be implemented, since it depends greatly
> on the monitoring level. No matter how quick and effective a limiter
> is, it can't know the level the user is monitoring at, so it can't
> really offer any real protection, because when people are working,
> they might be working with very soft sources, and therefore turn the
> monitoring level high up, and then when a much larger source comes
> through, even if it's not a really loud one under other conditions, it
> will blow the person's ears.
>
> So what I mean to say is that in practice, to have such a protection,
> you must know beforehand the monitoring level, or the maximum
> permitted amplitude (in the case of speaker protection), but for
> Csound where monitoring levels are so variable, such a system is not
> possible. The best thing, would be as part of the introductory csds
> have a way of scaring people a bit about the huge dynamic range Csound
> can produce, without actually doing any damage, but enough of a scare
> that they will be careful when monitoring (look at the meters first,
> make sure you are not working at too low amplitudes and high
> monitoring levels, etc.)
>
> Anyone want to write such a csd?
>
> Cheers,
> Andrés
>
> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>  wrote:
>> OK this is kind of not related but I found a weird bug either with  
>> csladspa
>> or aurdour, or both. When I copy a csladspa plug-in form one  
>> channel strip
>> of Ardour to another, there is this massive explosion and then Ardour
>> crashes. So there you go, you don't always have the option of pre- 
>> scoping.
>>
>> Well what the hell, I like to live dangerously and that's certainly  
>> possible
>> with Csound ;-)
>> Best,
>> Peiman
>>
>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>
>> But if "blow-up insurance" is built back into Csound, it would ruin  
>> the
>> hilarity of the "basic proficiency test" that takes place during  
>> the point
>> in class that Dr. B describes! I was in last semester's class... he  
>> left the
>> room and it was like a game of whack-a-mole of people yelling curse  
>> words
>> and horrendous square waveforms coming out of headphones...
>> This is why I scope every .csd I make. Step 1, mute speakers and  
>> run csd.
>> Step 2, look at scope. If the scope is straight up and down lines,  
>> DO NOT
>> UNMUTE. Step 3, if the coast is clear, unmute!
>> It's charming... kinda.
>> -Nick
>>
>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>  wrote:
>>>
>>> This is/was (among other things) what the PEAK chunk is/was for.  
>>> Write
>>> floats to a file, without clipping, and with PEAK info. When a  
>>> file with the
>>> PEAK chunk was read into Csound, if the peaks were over-range they  
>>> were
>>> automatically rescaled. This was all working back in v4.23.  
>>> Doubtless with
>>> the move to libsndfile that code has all gone (though the original  
>>> structure
>>> field "do_floatscaling" seems still to be around), but in  
>>> principle it
>>> should be able to be reintroduced (libsndfile does know about the  
>>> PEAK chunk
>>> so Csound can still obtain that info). But then users have to get  
>>> used to
>>> having the PEAK chunk in their files (some really old naff  
>>> software might
>>> not understand, and fail to read the file properly), and I saw  
>>> quite a lot
>>> of resistance to that.
>>>
>>> Of course for real-time rendering, there is no solution other than  
>>> to be
>>> careful, or apply some sort of limiter. And limiters are not exactly
>>> transparent.  Csound has historically been an "open" system in  
>>> that it does
>>> not hold your hand - "with great freedom..." etc.
>>>
>>>
>>> Richard Dobson
>>>
>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>> ..
>>>>
>>>> Back in the day, Matt Ingalls used to have an option in MacCsound  
>>>> where
>>>> you could render to floats, and then it would do a float to int
>>>> conversion prior to playback - and this gave a lot more headroom  
>>>> - and a
>>>> lot less pain, but...... is there a way to solve this problem at a
>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>> QuteCsound.
>>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>>
>> --
>> Nick Suda
>> Renton, WA/Boston, MA
>> nick.suda@gmail.com
>> (425) 941-0093
>>
>>
>
>
>
> -- 
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Maybe we could do an "auto-normalizer" sort of thing.

If the output level (in spout probably) is above the max value
(0dbfs), output is automatically scaled down.
The scale factor can be calculated as: 0dbfs/currentMaxLevel

This will indeed create glitches when the scale factor is recalculated
(when the maxlevel is exceeded),
but such a noticeable glitch can also give the user an indication that
something has gone over the top,
without causing actual ear or speaker damage.
This feature could be enabled via a command line flag, and it should
report the max level and/or scale factor arrived at when Csound is
done. Also print a kind note to the user suggesting the levels in
instruments be checked...

The normalize threshold could of course be set to something less than
0dbfs, but I can't really see why that would be useful.

best
Oeyvind

2010/2/19 Andres Cabrera :
> Hi,
>
> I agree it would be great to have some sort of protection... I'm sure
> we've all blown our ears at least once using csound....
>
> But I'm not sure how it would be implemented, since it depends greatly
> on the monitoring level. No matter how quick and effective a limiter
> is, it can't know the level the user is monitoring at, so it can't
> really offer any real protection, because when people are working,
> they might be working with very soft sources, and therefore turn the
> monitoring level high up, and then when a much larger source comes
> through, even if it's not a really loud one under other conditions, it
> will blow the person's ears.
>
> So what I mean to say is that in practice, to have such a protection,
> you must know beforehand the monitoring level, or the maximum
> permitted amplitude (in the case of speaker protection), but for
> Csound where monitoring levels are so variable, such a system is not
> possible. The best thing, would be as part of the introductory csds
> have a way of scaring people a bit about the huge dynamic range Csound
> can produce, without actually doing any damage, but enough of a scare
> that they will be careful when monitoring (look at the meters first,
> make sure you are not working at too low amplitudes and high
> monitoring levels, etc.)
>
> Anyone want to write such a csd?
>
> Cheers,
> Andrés
>
> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>  wrote:
>> OK this is kind of not related but I found a weird bug either with csladspa
>> or aurdour, or both. When I copy a csladspa plug-in form one channel strip
>> of Ardour to another, there is this massive explosion and then Ardour
>> crashes. So there you go, you don't always have the option of pre-scoping.
>>
>> Well what the hell, I like to live dangerously and that's certainly possible
>> with Csound ;-)
>> Best,
>> Peiman
>>
>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>
>> But if "blow-up insurance" is built back into Csound, it would ruin the
>> hilarity of the "basic proficiency test" that takes place during the point
>> in class that Dr. B describes! I was in last semester's class... he left the
>> room and it was like a game of whack-a-mole of people yelling curse words
>> and horrendous square waveforms coming out of headphones...
>> This is why I scope every .csd I make. Step 1, mute speakers and run csd.
>> Step 2, look at scope. If the scope is straight up and down lines, DO NOT
>> UNMUTE. Step 3, if the coast is clear, unmute!
>> It's charming... kinda.
>> -Nick
>>
>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>  wrote:
>>>
>>> This is/was (among other things) what the PEAK chunk is/was for. Write
>>> floats to a file, without clipping, and with PEAK info. When a file with the
>>> PEAK chunk was read into Csound, if the peaks were over-range they were
>>> automatically rescaled. This was all working back in v4.23. Doubtless with
>>> the move to libsndfile that code has all gone (though the original structure
>>> field "do_floatscaling" seems still to be around), but in principle it
>>> should be able to be reintroduced (libsndfile does know about the PEAK chunk
>>> so Csound can still obtain that info). But then users have to get used to
>>> having the PEAK chunk in their files (some really old naff software might
>>> not understand, and fail to read the file properly), and I saw quite a lot
>>> of resistance to that.
>>>
>>> Of course for real-time rendering, there is no solution other than to be
>>> careful, or apply some sort of limiter. And limiters are not exactly
>>> transparent.  Csound has historically been an "open" system in that it does
>>> not hold your hand - "with great freedom..." etc.
>>>
>>>
>>> Richard Dobson
>>>
>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>> ..
>>>>
>>>> Back in the day, Matt Ingalls used to have an option in MacCsound where
>>>> you could render to floats, and then it would do a float to int
>>>> conversion prior to playback - and this gave a lot more headroom - and a
>>>> lot less pain, but...... is there a way to solve this problem at a
>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>> QuteCsound.
>>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>>
>> --
>> Nick Suda
>> Renton, WA/Boston, MA
>> nick.suda@gmail.com
>> (425) 941-0093
>>
>>
>
>
>
> --
>
>
> Andrés
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Gosh, to loose hearing through loudspeakers appears to me to be  
extreme carelessness. I don't think I ever worked in an environment  
where the amplifier gain was so high that anything like that could  
ever happen.

Headphones, yes they are definitely dangerous. I had my share of close  
shaves with sine waves.

Victor

On 19 Feb 2010, at 12:28, Peiman Khosravi wrote:

> The best way of scaring poeple:
>
> I saw a couple a few years ago at the Bourges festival, they were  
> performing a joint electroacoustic composition.
>
> After some enquiry it turned out that one of them had lost her  
> hearing after a studio session when a maxmsp patch, which didn't  
> have protection built into it, had blown the speakers away. Not a  
> pleasant story.
>
> I agree that the caution must come from the user as there is no way  
> of protecting the csd. Also of course I would advice against  
> headphones in any case. In our studio at City we have one of those  
> systems with a db-meter in the room, which turns everything off if  
> the volume goes above a certain level.
>
> alas I haven't got such a system at home so have to be very careful.
>
> Best,
>
> Peiman
>
>
>
> On 19 Feb 2010, at 11:39, Andres Cabrera wrote:
>
>> Hi,
>>
>> I agree it would be great to have some sort of protection... I'm sure
>> we've all blown our ears at least once using csound....
>>
>> But I'm not sure how it would be implemented, since it depends  
>> greatly
>> on the monitoring level. No matter how quick and effective a limiter
>> is, it can't know the level the user is monitoring at, so it can't
>> really offer any real protection, because when people are working,
>> they might be working with very soft sources, and therefore turn the
>> monitoring level high up, and then when a much larger source comes
>> through, even if it's not a really loud one under other conditions,  
>> it
>> will blow the person's ears.
>>
>> So what I mean to say is that in practice, to have such a protection,
>> you must know beforehand the monitoring level, or the maximum
>> permitted amplitude (in the case of speaker protection), but for
>> Csound where monitoring levels are so variable, such a system is not
>> possible. The best thing, would be as part of the introductory csds
>> have a way of scaring people a bit about the huge dynamic range  
>> Csound
>> can produce, without actually doing any damage, but enough of a scare
>> that they will be careful when monitoring (look at the meters first,
>> make sure you are not working at too low amplitudes and high
>> monitoring levels, etc.)
>>
>> Anyone want to write such a csd?
>>
>> Cheers,
>> Andrés
>>
>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>  wrote:
>>> OK this is kind of not related but I found a weird bug either with  
>>> csladspa
>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>> channel strip
>>> of Ardour to another, there is this massive explosion and then  
>>> Ardour
>>> crashes. So there you go, you don't always have the option of pre- 
>>> scoping.
>>>
>>> Well what the hell, I like to live dangerously and that's  
>>> certainly possible
>>> with Csound ;-)
>>> Best,
>>> Peiman
>>>
>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>
>>> But if "blow-up insurance" is built back into Csound, it would  
>>> ruin the
>>> hilarity of the "basic proficiency test" that takes place during  
>>> the point
>>> in class that Dr. B describes! I was in last semester's class...  
>>> he left the
>>> room and it was like a game of whack-a-mole of people yelling  
>>> curse words
>>> and horrendous square waveforms coming out of headphones...
>>> This is why I scope every .csd I make. Step 1, mute speakers and  
>>> run csd.
>>> Step 2, look at scope. If the scope is straight up and down lines,  
>>> DO NOT
>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>> It's charming... kinda.
>>> -Nick
>>>
>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>  wrote:
>>>>
>>>> This is/was (among other things) what the PEAK chunk is/was for.  
>>>> Write
>>>> floats to a file, without clipping, and with PEAK info. When a  
>>>> file with the
>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>> they were
>>>> automatically rescaled. This was all working back in v4.23.  
>>>> Doubtless with
>>>> the move to libsndfile that code has all gone (though the  
>>>> original structure
>>>> field "do_floatscaling" seems still to be around), but in  
>>>> principle it
>>>> should be able to be reintroduced (libsndfile does know about the  
>>>> PEAK chunk
>>>> so Csound can still obtain that info). But then users have to get  
>>>> used to
>>>> having the PEAK chunk in their files (some really old naff  
>>>> software might
>>>> not understand, and fail to read the file properly), and I saw  
>>>> quite a lot
>>>> of resistance to that.
>>>>
>>>> Of course for real-time rendering, there is no solution other  
>>>> than to be
>>>> careful, or apply some sort of limiter. And limiters are not  
>>>> exactly
>>>> transparent.  Csound has historically been an "open" system in  
>>>> that it does
>>>> not hold your hand - "with great freedom..." etc.
>>>>
>>>>
>>>> Richard Dobson
>>>>
>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>> ..
>>>>>
>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>> MacCsound where
>>>>> you could render to floats, and then it would do a float to int
>>>>> conversion prior to playback - and this gave a lot more headroom  
>>>>> - and a
>>>>> lot less pain, but...... is there a way to solve this problem at a
>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>> QuteCsound.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> --
>>> Nick Suda
>>> Renton, WA/Boston, MA
>>> nick.suda@gmail.com
>>> (425) 941-0093
>>>
>>>
>>
>>
>>
>> -- 
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

But I think the problem seems to be that if it reaches clipping levels  
(0dbfs), then it's too late. Of course, you can't go above  0dbfs. I  
still think you can put a clip before out and that would help. But it  
won't if you keep turning the amplifier gain higher  and higher to  
compensate.


On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:

> Maybe we could do an "auto-normalizer" sort of thing.
>
> If the output level (in spout probably) is above the max value
> (0dbfs), output is automatically scaled down.
> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>
> This will indeed create glitches when the scale factor is recalculated
> (when the maxlevel is exceeded),
> but such a noticeable glitch can also give the user an indication that
> something has gone over the top,
> without causing actual ear or speaker damage.
> This feature could be enabled via a command line flag, and it should
> report the max level and/or scale factor arrived at when Csound is
> done. Also print a kind note to the user suggesting the levels in
> instruments be checked...
>
> The normalize threshold could of course be set to something less than
> 0dbfs, but I can't really see why that would be useful.
>
> best
> Oeyvind
>
> 2010/2/19 Andres Cabrera :
>> Hi,
>>
>> I agree it would be great to have some sort of protection... I'm sure
>> we've all blown our ears at least once using csound....
>>
>> But I'm not sure how it would be implemented, since it depends  
>> greatly
>> on the monitoring level. No matter how quick and effective a limiter
>> is, it can't know the level the user is monitoring at, so it can't
>> really offer any real protection, because when people are working,
>> they might be working with very soft sources, and therefore turn the
>> monitoring level high up, and then when a much larger source comes
>> through, even if it's not a really loud one under other conditions,  
>> it
>> will blow the person's ears.
>>
>> So what I mean to say is that in practice, to have such a protection,
>> you must know beforehand the monitoring level, or the maximum
>> permitted amplitude (in the case of speaker protection), but for
>> Csound where monitoring levels are so variable, such a system is not
>> possible. The best thing, would be as part of the introductory csds
>> have a way of scaring people a bit about the huge dynamic range  
>> Csound
>> can produce, without actually doing any damage, but enough of a scare
>> that they will be careful when monitoring (look at the meters first,
>> make sure you are not working at too low amplitudes and high
>> monitoring levels, etc.)
>>
>> Anyone want to write such a csd?
>>
>> Cheers,
>> Andrés
>>
>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>  wrote:
>>> OK this is kind of not related but I found a weird bug either with  
>>> csladspa
>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>> channel strip
>>> of Ardour to another, there is this massive explosion and then  
>>> Ardour
>>> crashes. So there you go, you don't always have the option of pre- 
>>> scoping.
>>>
>>> Well what the hell, I like to live dangerously and that's  
>>> certainly possible
>>> with Csound ;-)
>>> Best,
>>> Peiman
>>>
>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>
>>> But if "blow-up insurance" is built back into Csound, it would  
>>> ruin the
>>> hilarity of the "basic proficiency test" that takes place during  
>>> the point
>>> in class that Dr. B describes! I was in last semester's class...  
>>> he left the
>>> room and it was like a game of whack-a-mole of people yelling  
>>> curse words
>>> and horrendous square waveforms coming out of headphones...
>>> This is why I scope every .csd I make. Step 1, mute speakers and  
>>> run csd.
>>> Step 2, look at scope. If the scope is straight up and down lines,  
>>> DO NOT
>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>> It's charming... kinda.
>>> -Nick
>>>
>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>  wrote:
>>>>
>>>> This is/was (among other things) what the PEAK chunk is/was for.  
>>>> Write
>>>> floats to a file, without clipping, and with PEAK info. When a  
>>>> file with the
>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>> they were
>>>> automatically rescaled. This was all working back in v4.23.  
>>>> Doubtless with
>>>> the move to libsndfile that code has all gone (though the  
>>>> original structure
>>>> field "do_floatscaling" seems still to be around), but in  
>>>> principle it
>>>> should be able to be reintroduced (libsndfile does know about the  
>>>> PEAK chunk
>>>> so Csound can still obtain that info). But then users have to get  
>>>> used to
>>>> having the PEAK chunk in their files (some really old naff  
>>>> software might
>>>> not understand, and fail to read the file properly), and I saw  
>>>> quite a lot
>>>> of resistance to that.
>>>>
>>>> Of course for real-time rendering, there is no solution other  
>>>> than to be
>>>> careful, or apply some sort of limiter. And limiters are not  
>>>> exactly
>>>> transparent.  Csound has historically been an "open" system in  
>>>> that it does
>>>> not hold your hand - "with great freedom..." etc.
>>>>
>>>>
>>>> Richard Dobson
>>>>
>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>> ..
>>>>>
>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>> MacCsound where
>>>>> you could render to floats, and then it would do a float to int
>>>>> conversion prior to playback - and this gave a lot more headroom  
>>>>> - and a
>>>>> lot less pain, but...... is there a way to solve this problem at a
>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>> QuteCsound.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> --
>>> Nick Suda
>>> Renton, WA/Boston, MA
>>> nick.suda@gmail.com
>>> (425) 941-0093
>>>
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I think scaling would be better in this case than limiting/clipping,
as clipping is what we get anyway (as you also say).
And scaling the output so that it won't clip will take away the
excessive energy burst associated this kind of user error.
The amplifier gain, of course is the responsibility of the user. As
long as Csound automatically downscales out-of-range audio, we should
be fine. Of course, some users might turn up their amplifier gain to
compensate, but that is out of our hands anyway. A solidly visible
message about the output rescaling should be printed when Csound
exits, so as to help the user understand that it's the orchestra that
needs fixing, not the amp.

Oeyvind

2010/2/19 Victor Lazzarini :
> But I think the problem seems to be that if it reaches clipping levels
> (0dbfs), then it's too late. Of course, you can't go above  0dbfs. I still
> think you can put a clip before out and that would help. But it won't if you
> keep turning the amplifier gain higher  and higher to compensate.
>
>
> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>
>> Maybe we could do an "auto-normalizer" sort of thing.
>>
>> If the output level (in spout probably) is above the max value
>> (0dbfs), output is automatically scaled down.
>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>
>> This will indeed create glitches when the scale factor is recalculated
>> (when the maxlevel is exceeded),
>> but such a noticeable glitch can also give the user an indication that
>> something has gone over the top,
>> without causing actual ear or speaker damage.
>> This feature could be enabled via a command line flag, and it should
>> report the max level and/or scale factor arrived at when Csound is
>> done. Also print a kind note to the user suggesting the levels in
>> instruments be checked...
>>
>> The normalize threshold could of course be set to something less than
>> 0dbfs, but I can't really see why that would be useful.
>>
>> best
>> Oeyvind
>>
>> 2010/2/19 Andres Cabrera :
>>>
>>> Hi,
>>>
>>> I agree it would be great to have some sort of protection... I'm sure
>>> we've all blown our ears at least once using csound....
>>>
>>> But I'm not sure how it would be implemented, since it depends greatly
>>> on the monitoring level. No matter how quick and effective a limiter
>>> is, it can't know the level the user is monitoring at, so it can't
>>> really offer any real protection, because when people are working,
>>> they might be working with very soft sources, and therefore turn the
>>> monitoring level high up, and then when a much larger source comes
>>> through, even if it's not a really loud one under other conditions, it
>>> will blow the person's ears.
>>>
>>> So what I mean to say is that in practice, to have such a protection,
>>> you must know beforehand the monitoring level, or the maximum
>>> permitted amplitude (in the case of speaker protection), but for
>>> Csound where monitoring levels are so variable, such a system is not
>>> possible. The best thing, would be as part of the introductory csds
>>> have a way of scaring people a bit about the huge dynamic range Csound
>>> can produce, without actually doing any damage, but enough of a scare
>>> that they will be careful when monitoring (look at the meters first,
>>> make sure you are not working at too low amplitudes and high
>>> monitoring levels, etc.)
>>>
>>> Anyone want to write such a csd?
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>  wrote:
>>>>
>>>> OK this is kind of not related but I found a weird bug either with
>>>> csladspa
>>>> or aurdour, or both. When I copy a csladspa plug-in form one channel
>>>> strip
>>>> of Ardour to another, there is this massive explosion and then Ardour
>>>> crashes. So there you go, you don't always have the option of
>>>> pre-scoping.
>>>>
>>>> Well what the hell, I like to live dangerously and that's certainly
>>>> possible
>>>> with Csound ;-)
>>>> Best,
>>>> Peiman
>>>>
>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>
>>>> But if "blow-up insurance" is built back into Csound, it would ruin the
>>>> hilarity of the "basic proficiency test" that takes place during the
>>>> point
>>>> in class that Dr. B describes! I was in last semester's class... he left
>>>> the
>>>> room and it was like a game of whack-a-mole of people yelling curse
>>>> words
>>>> and horrendous square waveforms coming out of headphones...
>>>> This is why I scope every .csd I make. Step 1, mute speakers and run
>>>> csd.
>>>> Step 2, look at scope. If the scope is straight up and down lines, DO
>>>> NOT
>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>> It's charming... kinda.
>>>> -Nick
>>>>
>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>  wrote:
>>>>>
>>>>> This is/was (among other things) what the PEAK chunk is/was for. Write
>>>>> floats to a file, without clipping, and with PEAK info. When a file
>>>>> with the
>>>>> PEAK chunk was read into Csound, if the peaks were over-range they were
>>>>> automatically rescaled. This was all working back in v4.23. Doubtless
>>>>> with
>>>>> the move to libsndfile that code has all gone (though the original
>>>>> structure
>>>>> field "do_floatscaling" seems still to be around), but in principle it
>>>>> should be able to be reintroduced (libsndfile does know about the PEAK
>>>>> chunk
>>>>> so Csound can still obtain that info). But then users have to get used
>>>>> to
>>>>> having the PEAK chunk in their files (some really old naff software
>>>>> might
>>>>> not understand, and fail to read the file properly), and I saw quite a
>>>>> lot
>>>>> of resistance to that.
>>>>>
>>>>> Of course for real-time rendering, there is no solution other than to
>>>>> be
>>>>> careful, or apply some sort of limiter. And limiters are not exactly
>>>>> transparent.  Csound has historically been an "open" system in that it
>>>>> does
>>>>> not hold your hand - "with great freedom..." etc.
>>>>>
>>>>>
>>>>> Richard Dobson
>>>>>
>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>> ..
>>>>>>
>>>>>> Back in the day, Matt Ingalls used to have an option in MacCsound
>>>>>> where
>>>>>> you could render to floats, and then it would do a float to int
>>>>>> conversion prior to playback - and this gave a lot more headroom - and
>>>>>> a
>>>>>> lot less pain, but...... is there a way to solve this problem at a
>>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>>> QuteCsound.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>>
>>>> --
>>>> Nick Suda
>>>> Renton, WA/Boston, MA
>>>> nick.suda@gmail.com
>>>> (425) 941-0093
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

So many users/student work with headphones.

In our Classrooms and Learning Labs at Berklee, they are required to  
work with headphones.

In their apartments and their dorm rooms, they are often required to  
work with headphones.

I work through the  night here in my home studio - always - and I need  
to use headphones.

I warn them.  I warn myself.  But... I have to grade their homework -  
and these blow up on me too.

Hopefully you will be able to come up with some way that this can be  
addressed and
this "feature" can be optionally turned on/off.

Dr. B.

On Feb 19, 2010, at 7:51 AM, Oeyvind Brandtsegg wrote:

> I think scaling would be better in this case than limiting/clipping,
> as clipping is what we get anyway (as you also say).
> And scaling the output so that it won't clip will take away the
> excessive energy burst associated this kind of user error.
> The amplifier gain, of course is the responsibility of the user. As
> long as Csound automatically downscales out-of-range audio, we should
> be fine. Of course, some users might turn up their amplifier gain to
> compensate, but that is out of our hands anyway. A solidly visible
> message about the output rescaling should be printed when Csound
> exits, so as to help the user understand that it's the orchestra that
> needs fixing, not the amp.
>
> Oeyvind
>
> 2010/2/19 Victor Lazzarini :
>> But I think the problem seems to be that if it reaches clipping  
>> levels
>> (0dbfs), then it's too late. Of course, you can't go above  0dbfs.  
>> I still
>> think you can put a clip before out and that would help. But it  
>> won't if you
>> keep turning the amplifier gain higher  and higher to compensate.
>>
>>
>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>
>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>
>>> If the output level (in spout probably) is above the max value
>>> (0dbfs), output is automatically scaled down.
>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>
>>> This will indeed create glitches when the scale factor is  
>>> recalculated
>>> (when the maxlevel is exceeded),
>>> but such a noticeable glitch can also give the user an indication  
>>> that
>>> something has gone over the top,
>>> without causing actual ear or speaker damage.
>>> This feature could be enabled via a command line flag, and it should
>>> report the max level and/or scale factor arrived at when Csound is
>>> done. Also print a kind note to the user suggesting the levels in
>>> instruments be checked...
>>>
>>> The normalize threshold could of course be set to something less  
>>> than
>>> 0dbfs, but I can't really see why that would be useful.
>>>
>>> best
>>> Oeyvind
>>>
>>> 2010/2/19 Andres Cabrera :
>>>>
>>>> Hi,
>>>>
>>>> I agree it would be great to have some sort of protection... I'm  
>>>> sure
>>>> we've all blown our ears at least once using csound....
>>>>
>>>> But I'm not sure how it would be implemented, since it depends  
>>>> greatly
>>>> on the monitoring level. No matter how quick and effective a  
>>>> limiter
>>>> is, it can't know the level the user is monitoring at, so it can't
>>>> really offer any real protection, because when people are working,
>>>> they might be working with very soft sources, and therefore turn  
>>>> the
>>>> monitoring level high up, and then when a much larger source comes
>>>> through, even if it's not a really loud one under other  
>>>> conditions, it
>>>> will blow the person's ears.
>>>>
>>>> So what I mean to say is that in practice, to have such a  
>>>> protection,
>>>> you must know beforehand the monitoring level, or the maximum
>>>> permitted amplitude (in the case of speaker protection), but for
>>>> Csound where monitoring levels are so variable, such a system is  
>>>> not
>>>> possible. The best thing, would be as part of the introductory csds
>>>> have a way of scaring people a bit about the huge dynamic range  
>>>> Csound
>>>> can produce, without actually doing any damage, but enough of a  
>>>> scare
>>>> that they will be careful when monitoring (look at the meters  
>>>> first,
>>>> make sure you are not working at too low amplitudes and high
>>>> monitoring levels, etc.)
>>>>
>>>> Anyone want to write such a csd?
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>  wrote:
>>>>>
>>>>> OK this is kind of not related but I found a weird bug either with
>>>>> csladspa
>>>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>>>> channel
>>>>> strip
>>>>> of Ardour to another, there is this massive explosion and then  
>>>>> Ardour
>>>>> crashes. So there you go, you don't always have the option of
>>>>> pre-scoping.
>>>>>
>>>>> Well what the hell, I like to live dangerously and that's  
>>>>> certainly
>>>>> possible
>>>>> with Csound ;-)
>>>>> Best,
>>>>> Peiman
>>>>>
>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>
>>>>> But if "blow-up insurance" is built back into Csound, it would  
>>>>> ruin the
>>>>> hilarity of the "basic proficiency test" that takes place during  
>>>>> the
>>>>> point
>>>>> in class that Dr. B describes! I was in last semester's class...  
>>>>> he left
>>>>> the
>>>>> room and it was like a game of whack-a-mole of people yelling  
>>>>> curse
>>>>> words
>>>>> and horrendous square waveforms coming out of headphones...
>>>>> This is why I scope every .csd I make. Step 1, mute speakers and  
>>>>> run
>>>>> csd.
>>>>> Step 2, look at scope. If the scope is straight up and down  
>>>>> lines, DO
>>>>> NOT
>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>> It's charming... kinda.
>>>>> -Nick
>>>>>
>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>  wrote:
>>>>>>
>>>>>> This is/was (among other things) what the PEAK chunk is/was  
>>>>>> for. Write
>>>>>> floats to a file, without clipping, and with PEAK info. When a  
>>>>>> file
>>>>>> with the
>>>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>>>> they were
>>>>>> automatically rescaled. This was all working back in v4.23.  
>>>>>> Doubtless
>>>>>> with
>>>>>> the move to libsndfile that code has all gone (though the  
>>>>>> original
>>>>>> structure
>>>>>> field "do_floatscaling" seems still to be around), but in  
>>>>>> principle it
>>>>>> should be able to be reintroduced (libsndfile does know about  
>>>>>> the PEAK
>>>>>> chunk
>>>>>> so Csound can still obtain that info). But then users have to  
>>>>>> get used
>>>>>> to
>>>>>> having the PEAK chunk in their files (some really old naff  
>>>>>> software
>>>>>> might
>>>>>> not understand, and fail to read the file properly), and I saw  
>>>>>> quite a
>>>>>> lot
>>>>>> of resistance to that.
>>>>>>
>>>>>> Of course for real-time rendering, there is no solution other  
>>>>>> than to
>>>>>> be
>>>>>> careful, or apply some sort of limiter. And limiters are not  
>>>>>> exactly
>>>>>> transparent.  Csound has historically been an "open" system in  
>>>>>> that it
>>>>>> does
>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>
>>>>>>
>>>>>> Richard Dobson
>>>>>>
>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>> ..
>>>>>>>
>>>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>>>> MacCsound
>>>>>>> where
>>>>>>> you could render to floats, and then it would do a float to int
>>>>>>> conversion prior to playback - and this gave a lot more  
>>>>>>> headroom - and
>>>>>>> a
>>>>>>> lot less pain, but...... is there a way to solve this problem  
>>>>>>> at a
>>>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>>>> QuteCsound.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nick Suda
>>>>> Renton, WA/Boston, MA
>>>>> nick.suda@gmail.com
>>>>> (425) 941-0093
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

But what you call out-of-range surely means well below 0dbfs?  
Otherwise, there is no advantage, because anything above that will  
have a RMS = 0dbfs anyway, which sounds just below 0dbfs might very  
well be quite close to.
So before the scaling kicks in, we're in trouble.

Victor


On 19 Feb 2010, at 12:51, Oeyvind Brandtsegg wrote:

> I think scaling would be better in this case than limiting/clipping,
> as clipping is what we get anyway (as you also say).
> And scaling the output so that it won't clip will take away the
> excessive energy burst associated this kind of user error.
> The amplifier gain, of course is the responsibility of the user. As
> long as Csound automatically downscales out-of-range audio, we should
> be fine. Of course, some users might turn up their amplifier gain to
> compensate, but that is out of our hands anyway. A solidly visible
> message about the output rescaling should be printed when Csound
> exits, so as to help the user understand that it's the orchestra that
> needs fixing, not the amp.
>
> Oeyvind
>
> 2010/2/19 Victor Lazzarini :
>> But I think the problem seems to be that if it reaches clipping  
>> levels
>> (0dbfs), then it's too late. Of course, you can't go above  0dbfs.  
>> I still
>> think you can put a clip before out and that would help. But it  
>> won't if you
>> keep turning the amplifier gain higher  and higher to compensate.
>>
>>
>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>
>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>
>>> If the output level (in spout probably) is above the max value
>>> (0dbfs), output is automatically scaled down.
>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>
>>> This will indeed create glitches when the scale factor is  
>>> recalculated
>>> (when the maxlevel is exceeded),
>>> but such a noticeable glitch can also give the user an indication  
>>> that
>>> something has gone over the top,
>>> without causing actual ear or speaker damage.
>>> This feature could be enabled via a command line flag, and it should
>>> report the max level and/or scale factor arrived at when Csound is
>>> done. Also print a kind note to the user suggesting the levels in
>>> instruments be checked...
>>>
>>> The normalize threshold could of course be set to something less  
>>> than
>>> 0dbfs, but I can't really see why that would be useful.
>>>
>>> best
>>> Oeyvind
>>>
>>> 2010/2/19 Andres Cabrera :
>>>>
>>>> Hi,
>>>>
>>>> I agree it would be great to have some sort of protection... I'm  
>>>> sure
>>>> we've all blown our ears at least once using csound....
>>>>
>>>> But I'm not sure how it would be implemented, since it depends  
>>>> greatly
>>>> on the monitoring level. No matter how quick and effective a  
>>>> limiter
>>>> is, it can't know the level the user is monitoring at, so it can't
>>>> really offer any real protection, because when people are working,
>>>> they might be working with very soft sources, and therefore turn  
>>>> the
>>>> monitoring level high up, and then when a much larger source comes
>>>> through, even if it's not a really loud one under other  
>>>> conditions, it
>>>> will blow the person's ears.
>>>>
>>>> So what I mean to say is that in practice, to have such a  
>>>> protection,
>>>> you must know beforehand the monitoring level, or the maximum
>>>> permitted amplitude (in the case of speaker protection), but for
>>>> Csound where monitoring levels are so variable, such a system is  
>>>> not
>>>> possible. The best thing, would be as part of the introductory csds
>>>> have a way of scaring people a bit about the huge dynamic range  
>>>> Csound
>>>> can produce, without actually doing any damage, but enough of a  
>>>> scare
>>>> that they will be careful when monitoring (look at the meters  
>>>> first,
>>>> make sure you are not working at too low amplitudes and high
>>>> monitoring levels, etc.)
>>>>
>>>> Anyone want to write such a csd?
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>  wrote:
>>>>>
>>>>> OK this is kind of not related but I found a weird bug either with
>>>>> csladspa
>>>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>>>> channel
>>>>> strip
>>>>> of Ardour to another, there is this massive explosion and then  
>>>>> Ardour
>>>>> crashes. So there you go, you don't always have the option of
>>>>> pre-scoping.
>>>>>
>>>>> Well what the hell, I like to live dangerously and that's  
>>>>> certainly
>>>>> possible
>>>>> with Csound ;-)
>>>>> Best,
>>>>> Peiman
>>>>>
>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>
>>>>> But if "blow-up insurance" is built back into Csound, it would  
>>>>> ruin the
>>>>> hilarity of the "basic proficiency test" that takes place during  
>>>>> the
>>>>> point
>>>>> in class that Dr. B describes! I was in last semester's class...  
>>>>> he left
>>>>> the
>>>>> room and it was like a game of whack-a-mole of people yelling  
>>>>> curse
>>>>> words
>>>>> and horrendous square waveforms coming out of headphones...
>>>>> This is why I scope every .csd I make. Step 1, mute speakers and  
>>>>> run
>>>>> csd.
>>>>> Step 2, look at scope. If the scope is straight up and down  
>>>>> lines, DO
>>>>> NOT
>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>> It's charming... kinda.
>>>>> -Nick
>>>>>
>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>  wrote:
>>>>>>
>>>>>> This is/was (among other things) what the PEAK chunk is/was  
>>>>>> for. Write
>>>>>> floats to a file, without clipping, and with PEAK info. When a  
>>>>>> file
>>>>>> with the
>>>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>>>> they were
>>>>>> automatically rescaled. This was all working back in v4.23.  
>>>>>> Doubtless
>>>>>> with
>>>>>> the move to libsndfile that code has all gone (though the  
>>>>>> original
>>>>>> structure
>>>>>> field "do_floatscaling" seems still to be around), but in  
>>>>>> principle it
>>>>>> should be able to be reintroduced (libsndfile does know about  
>>>>>> the PEAK
>>>>>> chunk
>>>>>> so Csound can still obtain that info). But then users have to  
>>>>>> get used
>>>>>> to
>>>>>> having the PEAK chunk in their files (some really old naff  
>>>>>> software
>>>>>> might
>>>>>> not understand, and fail to read the file properly), and I saw  
>>>>>> quite a
>>>>>> lot
>>>>>> of resistance to that.
>>>>>>
>>>>>> Of course for real-time rendering, there is no solution other  
>>>>>> than to
>>>>>> be
>>>>>> careful, or apply some sort of limiter. And limiters are not  
>>>>>> exactly
>>>>>> transparent.  Csound has historically been an "open" system in  
>>>>>> that it
>>>>>> does
>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>
>>>>>>
>>>>>> Richard Dobson
>>>>>>
>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>> ..
>>>>>>>
>>>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>>>> MacCsound
>>>>>>> where
>>>>>>> you could render to floats, and then it would do a float to int
>>>>>>> conversion prior to playback - and this gave a lot more  
>>>>>>> headroom - and
>>>>>>> a
>>>>>>> lot less pain, but...... is there a way to solve this problem  
>>>>>>> at a
>>>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>>>> QuteCsound.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nick Suda
>>>>> Renton, WA/Boston, MA
>>>>> nick.suda@gmail.com
>>>>> (425) 941-0093
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Andrés
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I think the only way around it would be to add a little look-ahead  
function to the front-end application (not csound itself), which  
delays the output of csound by N samples, looks at the sample values  
and if they are above a user-defined level (say -1 db) then stops  
csound performance while opening an error messages or something. Of  
course this would mean that the user has to calibrate their system  
before in terms of the actual levels.

I don't like the idea of scaling anything for the user. Now stopping  
the performance is another thing.

Best,

Peiman




On 19 Feb 2010, at 13:05, Victor Lazzarini wrote:

> But what you call out-of-range surely means well below 0dbfs?  
> Otherwise, there is no advantage, because anything above that will  
> have a RMS = 0dbfs anyway, which sounds just below 0dbfs might very  
> well be quite close to.
> So before the scaling kicks in, we're in trouble.
>
> Victor
>
>
> On 19 Feb 2010, at 12:51, Oeyvind Brandtsegg wrote:
>
>> I think scaling would be better in this case than limiting/clipping,
>> as clipping is what we get anyway (as you also say).
>> And scaling the output so that it won't clip will take away the
>> excessive energy burst associated this kind of user error.
>> The amplifier gain, of course is the responsibility of the user. As
>> long as Csound automatically downscales out-of-range audio, we should
>> be fine. Of course, some users might turn up their amplifier gain to
>> compensate, but that is out of our hands anyway. A solidly visible
>> message about the output rescaling should be printed when Csound
>> exits, so as to help the user understand that it's the orchestra that
>> needs fixing, not the amp.
>>
>> Oeyvind
>>
>> 2010/2/19 Victor Lazzarini :
>>> But I think the problem seems to be that if it reaches clipping  
>>> levels
>>> (0dbfs), then it's too late. Of course, you can't go above  0dbfs.  
>>> I still
>>> think you can put a clip before out and that would help. But it  
>>> won't if you
>>> keep turning the amplifier gain higher  and higher to compensate.
>>>
>>>
>>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>>
>>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>>
>>>> If the output level (in spout probably) is above the max value
>>>> (0dbfs), output is automatically scaled down.
>>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>>
>>>> This will indeed create glitches when the scale factor is  
>>>> recalculated
>>>> (when the maxlevel is exceeded),
>>>> but such a noticeable glitch can also give the user an indication  
>>>> that
>>>> something has gone over the top,
>>>> without causing actual ear or speaker damage.
>>>> This feature could be enabled via a command line flag, and it  
>>>> should
>>>> report the max level and/or scale factor arrived at when Csound is
>>>> done. Also print a kind note to the user suggesting the levels in
>>>> instruments be checked...
>>>>
>>>> The normalize threshold could of course be set to something less  
>>>> than
>>>> 0dbfs, but I can't really see why that would be useful.
>>>>
>>>> best
>>>> Oeyvind
>>>>
>>>> 2010/2/19 Andres Cabrera :
>>>>>
>>>>> Hi,
>>>>>
>>>>> I agree it would be great to have some sort of protection... I'm  
>>>>> sure
>>>>> we've all blown our ears at least once using csound....
>>>>>
>>>>> But I'm not sure how it would be implemented, since it depends  
>>>>> greatly
>>>>> on the monitoring level. No matter how quick and effective a  
>>>>> limiter
>>>>> is, it can't know the level the user is monitoring at, so it can't
>>>>> really offer any real protection, because when people are working,
>>>>> they might be working with very soft sources, and therefore turn  
>>>>> the
>>>>> monitoring level high up, and then when a much larger source comes
>>>>> through, even if it's not a really loud one under other  
>>>>> conditions, it
>>>>> will blow the person's ears.
>>>>>
>>>>> So what I mean to say is that in practice, to have such a  
>>>>> protection,
>>>>> you must know beforehand the monitoring level, or the maximum
>>>>> permitted amplitude (in the case of speaker protection), but for
>>>>> Csound where monitoring levels are so variable, such a system is  
>>>>> not
>>>>> possible. The best thing, would be as part of the introductory  
>>>>> csds
>>>>> have a way of scaring people a bit about the huge dynamic range  
>>>>> Csound
>>>>> can produce, without actually doing any damage, but enough of a  
>>>>> scare
>>>>> that they will be careful when monitoring (look at the meters  
>>>>> first,
>>>>> make sure you are not working at too low amplitudes and high
>>>>> monitoring levels, etc.)
>>>>>
>>>>> Anyone want to write such a csd?
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>>  wrote:
>>>>>>
>>>>>> OK this is kind of not related but I found a weird bug either  
>>>>>> with
>>>>>> csladspa
>>>>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>>>>> channel
>>>>>> strip
>>>>>> of Ardour to another, there is this massive explosion and then  
>>>>>> Ardour
>>>>>> crashes. So there you go, you don't always have the option of
>>>>>> pre-scoping.
>>>>>>
>>>>>> Well what the hell, I like to live dangerously and that's  
>>>>>> certainly
>>>>>> possible
>>>>>> with Csound ;-)
>>>>>> Best,
>>>>>> Peiman
>>>>>>
>>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>>
>>>>>> But if "blow-up insurance" is built back into Csound, it would  
>>>>>> ruin the
>>>>>> hilarity of the "basic proficiency test" that takes place  
>>>>>> during the
>>>>>> point
>>>>>> in class that Dr. B describes! I was in last semester's  
>>>>>> class... he left
>>>>>> the
>>>>>> room and it was like a game of whack-a-mole of people yelling  
>>>>>> curse
>>>>>> words
>>>>>> and horrendous square waveforms coming out of headphones...
>>>>>> This is why I scope every .csd I make. Step 1, mute speakers  
>>>>>> and run
>>>>>> csd.
>>>>>> Step 2, look at scope. If the scope is straight up and down  
>>>>>> lines, DO
>>>>>> NOT
>>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>>> It's charming... kinda.
>>>>>> -Nick
>>>>>>
>>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>>  wrote:
>>>>>>>
>>>>>>> This is/was (among other things) what the PEAK chunk is/was  
>>>>>>> for. Write
>>>>>>> floats to a file, without clipping, and with PEAK info. When a  
>>>>>>> file
>>>>>>> with the
>>>>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>>>>> they were
>>>>>>> automatically rescaled. This was all working back in v4.23.  
>>>>>>> Doubtless
>>>>>>> with
>>>>>>> the move to libsndfile that code has all gone (though the  
>>>>>>> original
>>>>>>> structure
>>>>>>> field "do_floatscaling" seems still to be around), but in  
>>>>>>> principle it
>>>>>>> should be able to be reintroduced (libsndfile does know about  
>>>>>>> the PEAK
>>>>>>> chunk
>>>>>>> so Csound can still obtain that info). But then users have to  
>>>>>>> get used
>>>>>>> to
>>>>>>> having the PEAK chunk in their files (some really old naff  
>>>>>>> software
>>>>>>> might
>>>>>>> not understand, and fail to read the file properly), and I saw  
>>>>>>> quite a
>>>>>>> lot
>>>>>>> of resistance to that.
>>>>>>>
>>>>>>> Of course for real-time rendering, there is no solution other  
>>>>>>> than to
>>>>>>> be
>>>>>>> careful, or apply some sort of limiter. And limiters are not  
>>>>>>> exactly
>>>>>>> transparent.  Csound has historically been an "open" system in  
>>>>>>> that it
>>>>>>> does
>>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>>
>>>>>>>
>>>>>>> Richard Dobson
>>>>>>>
>>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>>> ..
>>>>>>>>
>>>>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>>>>> MacCsound
>>>>>>>> where
>>>>>>>> you could render to floats, and then it would do a float to int
>>>>>>>> conversion prior to playback - and this gave a lot more  
>>>>>>>> headroom - and
>>>>>>>> a
>>>>>>>> lot less pain, but...... is there a way to solve this problem  
>>>>>>>> at a
>>>>>>>> deeper and yet more transparent level. In Csound or PortAudio  
>>>>>>>> or
>>>>>>>> QuteCsound.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nick Suda
>>>>>> Renton, WA/Boston, MA
>>>>>> nick.suda@gmail.com
>>>>>> (425) 941-0093
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

-odac



	sr	=	44100
	kr	=	441
	ksmps	=	100
	nchnls	=	2
	0dbfs	= 	1
	giMax	= 	0dbfs
	gkScale	init	1
	giSine	ftgen	0, 0, 65537, 10, 1

;********************************************
	instr 1
	iamp	= p4
	icps	= p5
	a1	oscil	iamp, icps, giSine
	aRef	init 0
	aMax	maxabs	a1, aRef
	aRef	= aMax
	kMax	downsamp aMax, ksmps
	gkScale = (giMax*0.62/kMax < 1 ? giMax*0.62/kMax : gkScale)
	a1	= a1*gkScale
		outs a1, a1
	endin
;********************************************


i1 0 1 0.5 440	; normal amp range
i1 2 1 1.0 440	; normal max amp range
i1 4 1 3.0 440	; overload
i1 6 1 300 440	; massive overload
e






2010/2/19 Dr. Richard Boulanger :
> So many users/student work with headphones.
>
> In our Classrooms and Learning Labs at Berklee, they are required to work
> with headphones.
>
> In their apartments and their dorm rooms, they are often required to work
> with headphones.
>
> I work through the  night here in my home studio - always - and I need to
> use headphones.
>
> I warn them.  I warn myself.  But... I have to grade their homework - and
> these blow up on me too.
>
> Hopefully you will be able to come up with some way that this can be
> addressed and
> this "feature" can be optionally turned on/off.
>
> Dr. B.
>
> On Feb 19, 2010, at 7:51 AM, Oeyvind Brandtsegg wrote:
>
>> I think scaling would be better in this case than limiting/clipping,
>> as clipping is what we get anyway (as you also say).
>> And scaling the output so that it won't clip will take away the
>> excessive energy burst associated this kind of user error.
>> The amplifier gain, of course is the responsibility of the user. As
>> long as Csound automatically downscales out-of-range audio, we should
>> be fine. Of course, some users might turn up their amplifier gain to
>> compensate, but that is out of our hands anyway. A solidly visible
>> message about the output rescaling should be printed when Csound
>> exits, so as to help the user understand that it's the orchestra that
>> needs fixing, not the amp.
>>
>> Oeyvind
>>
>> 2010/2/19 Victor Lazzarini :
>>>
>>> But I think the problem seems to be that if it reaches clipping levels
>>> (0dbfs), then it's too late. Of course, you can't go above  0dbfs. I
>>> still
>>> think you can put a clip before out and that would help. But it won't if
>>> you
>>> keep turning the amplifier gain higher  and higher to compensate.
>>>
>>>
>>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>>
>>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>>
>>>> If the output level (in spout probably) is above the max value
>>>> (0dbfs), output is automatically scaled down.
>>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>>
>>>> This will indeed create glitches when the scale factor is recalculated
>>>> (when the maxlevel is exceeded),
>>>> but such a noticeable glitch can also give the user an indication that
>>>> something has gone over the top,
>>>> without causing actual ear or speaker damage.
>>>> This feature could be enabled via a command line flag, and it should
>>>> report the max level and/or scale factor arrived at when Csound is
>>>> done. Also print a kind note to the user suggesting the levels in
>>>> instruments be checked...
>>>>
>>>> The normalize threshold could of course be set to something less than
>>>> 0dbfs, but I can't really see why that would be useful.
>>>>
>>>> best
>>>> Oeyvind
>>>>
>>>> 2010/2/19 Andres Cabrera :
>>>>>
>>>>> Hi,
>>>>>
>>>>> I agree it would be great to have some sort of protection... I'm sure
>>>>> we've all blown our ears at least once using csound....
>>>>>
>>>>> But I'm not sure how it would be implemented, since it depends greatly
>>>>> on the monitoring level. No matter how quick and effective a limiter
>>>>> is, it can't know the level the user is monitoring at, so it can't
>>>>> really offer any real protection, because when people are working,
>>>>> they might be working with very soft sources, and therefore turn the
>>>>> monitoring level high up, and then when a much larger source comes
>>>>> through, even if it's not a really loud one under other conditions, it
>>>>> will blow the person's ears.
>>>>>
>>>>> So what I mean to say is that in practice, to have such a protection,
>>>>> you must know beforehand the monitoring level, or the maximum
>>>>> permitted amplitude (in the case of speaker protection), but for
>>>>> Csound where monitoring levels are so variable, such a system is not
>>>>> possible. The best thing, would be as part of the introductory csds
>>>>> have a way of scaring people a bit about the huge dynamic range Csound
>>>>> can produce, without actually doing any damage, but enough of a scare
>>>>> that they will be careful when monitoring (look at the meters first,
>>>>> make sure you are not working at too low amplitudes and high
>>>>> monitoring levels, etc.)
>>>>>
>>>>> Anyone want to write such a csd?
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>>  wrote:
>>>>>>
>>>>>> OK this is kind of not related but I found a weird bug either with
>>>>>> csladspa
>>>>>> or aurdour, or both. When I copy a csladspa plug-in form one channel
>>>>>> strip
>>>>>> of Ardour to another, there is this massive explosion and then Ardour
>>>>>> crashes. So there you go, you don't always have the option of
>>>>>> pre-scoping.
>>>>>>
>>>>>> Well what the hell, I like to live dangerously and that's certainly
>>>>>> possible
>>>>>> with Csound ;-)
>>>>>> Best,
>>>>>> Peiman
>>>>>>
>>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>>
>>>>>> But if "blow-up insurance" is built back into Csound, it would ruin
>>>>>> the
>>>>>> hilarity of the "basic proficiency test" that takes place during the
>>>>>> point
>>>>>> in class that Dr. B describes! I was in last semester's class... he
>>>>>> left
>>>>>> the
>>>>>> room and it was like a game of whack-a-mole of people yelling curse
>>>>>> words
>>>>>> and horrendous square waveforms coming out of headphones...
>>>>>> This is why I scope every .csd I make. Step 1, mute speakers and run
>>>>>> csd.
>>>>>> Step 2, look at scope. If the scope is straight up and down lines, DO
>>>>>> NOT
>>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>>> It's charming... kinda.
>>>>>> -Nick
>>>>>>
>>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>>  wrote:
>>>>>>>
>>>>>>> This is/was (among other things) what the PEAK chunk is/was for.
>>>>>>> Write
>>>>>>> floats to a file, without clipping, and with PEAK info. When a file
>>>>>>> with the
>>>>>>> PEAK chunk was read into Csound, if the peaks were over-range they
>>>>>>> were
>>>>>>> automatically rescaled. This was all working back in v4.23. Doubtless
>>>>>>> with
>>>>>>> the move to libsndfile that code has all gone (though the original
>>>>>>> structure
>>>>>>> field "do_floatscaling" seems still to be around), but in principle
>>>>>>> it
>>>>>>> should be able to be reintroduced (libsndfile does know about the
>>>>>>> PEAK
>>>>>>> chunk
>>>>>>> so Csound can still obtain that info). But then users have to get
>>>>>>> used
>>>>>>> to
>>>>>>> having the PEAK chunk in their files (some really old naff software
>>>>>>> might
>>>>>>> not understand, and fail to read the file properly), and I saw quite
>>>>>>> a
>>>>>>> lot
>>>>>>> of resistance to that.
>>>>>>>
>>>>>>> Of course for real-time rendering, there is no solution other than to
>>>>>>> be
>>>>>>> careful, or apply some sort of limiter. And limiters are not exactly
>>>>>>> transparent.  Csound has historically been an "open" system in that
>>>>>>> it
>>>>>>> does
>>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>>
>>>>>>>
>>>>>>> Richard Dobson
>>>>>>>
>>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>>> ..
>>>>>>>>
>>>>>>>> Back in the day, Matt Ingalls used to have an option in MacCsound
>>>>>>>> where
>>>>>>>> you could render to floats, and then it would do a float to int
>>>>>>>> conversion prior to playback - and this gave a lot more headroom -
>>>>>>>> and
>>>>>>>> a
>>>>>>>> lot less pain, but...... is there a way to solve this problem at a
>>>>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>>>>> QuteCsound.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nick Suda
>>>>>> Renton, WA/Boston, MA
>>>>>> nick.suda@gmail.com
>>>>>> (425) 941-0093
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Actually, I have to disagree.
Playing sounds at 0dbfs should not damage anything,
but when the audio system tries to reproduce a signal that exceeds
0dbfs by several orders of magnitude, the output enegry is much higher
than just playing a nonclipped signal at 0dbfs.

Try to comment out the line
a1      = a1*gkScale
in the csd I just sent,
and play it *at low level* for safety

With this line in, we rescale nicely to just below 1.0 regardless of
the original signal overload.

Oeyvind

2010/2/19 Victor Lazzarini :
> But what you call out-of-range surely means well below 0dbfs? Otherwise,
> there is no advantage, because anything above that will have a RMS = 0dbfs
> anyway, which sounds just below 0dbfs might very well be quite close to.
> So before the scaling kicks in, we're in trouble.
>
> Victor
>
>
> On 19 Feb 2010, at 12:51, Oeyvind Brandtsegg wrote:
>
>> I think scaling would be better in this case than limiting/clipping,
>> as clipping is what we get anyway (as you also say).
>> And scaling the output so that it won't clip will take away the
>> excessive energy burst associated this kind of user error.
>> The amplifier gain, of course is the responsibility of the user. As
>> long as Csound automatically downscales out-of-range audio, we should
>> be fine. Of course, some users might turn up their amplifier gain to
>> compensate, but that is out of our hands anyway. A solidly visible
>> message about the output rescaling should be printed when Csound
>> exits, so as to help the user understand that it's the orchestra that
>> needs fixing, not the amp.
>>
>> Oeyvind
>>
>> 2010/2/19 Victor Lazzarini :
>>>
>>> But I think the problem seems to be that if it reaches clipping levels
>>> (0dbfs), then it's too late. Of course, you can't go above  0dbfs. I
>>> still
>>> think you can put a clip before out and that would help. But it won't if
>>> you
>>> keep turning the amplifier gain higher  and higher to compensate.
>>>
>>>
>>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>>
>>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>>
>>>> If the output level (in spout probably) is above the max value
>>>> (0dbfs), output is automatically scaled down.
>>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>>
>>>> This will indeed create glitches when the scale factor is recalculated
>>>> (when the maxlevel is exceeded),
>>>> but such a noticeable glitch can also give the user an indication that
>>>> something has gone over the top,
>>>> without causing actual ear or speaker damage.
>>>> This feature could be enabled via a command line flag, and it should
>>>> report the max level and/or scale factor arrived at when Csound is
>>>> done. Also print a kind note to the user suggesting the levels in
>>>> instruments be checked...
>>>>
>>>> The normalize threshold could of course be set to something less than
>>>> 0dbfs, but I can't really see why that would be useful.
>>>>
>>>> best
>>>> Oeyvind
>>>>
>>>> 2010/2/19 Andres Cabrera :
>>>>>
>>>>> Hi,
>>>>>
>>>>> I agree it would be great to have some sort of protection... I'm sure
>>>>> we've all blown our ears at least once using csound....
>>>>>
>>>>> But I'm not sure how it would be implemented, since it depends greatly
>>>>> on the monitoring level. No matter how quick and effective a limiter
>>>>> is, it can't know the level the user is monitoring at, so it can't
>>>>> really offer any real protection, because when people are working,
>>>>> they might be working with very soft sources, and therefore turn the
>>>>> monitoring level high up, and then when a much larger source comes
>>>>> through, even if it's not a really loud one under other conditions, it
>>>>> will blow the person's ears.
>>>>>
>>>>> So what I mean to say is that in practice, to have such a protection,
>>>>> you must know beforehand the monitoring level, or the maximum
>>>>> permitted amplitude (in the case of speaker protection), but for
>>>>> Csound where monitoring levels are so variable, such a system is not
>>>>> possible. The best thing, would be as part of the introductory csds
>>>>> have a way of scaring people a bit about the huge dynamic range Csound
>>>>> can produce, without actually doing any damage, but enough of a scare
>>>>> that they will be careful when monitoring (look at the meters first,
>>>>> make sure you are not working at too low amplitudes and high
>>>>> monitoring levels, etc.)
>>>>>
>>>>> Anyone want to write such a csd?
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>>  wrote:
>>>>>>
>>>>>> OK this is kind of not related but I found a weird bug either with
>>>>>> csladspa
>>>>>> or aurdour, or both. When I copy a csladspa plug-in form one channel
>>>>>> strip
>>>>>> of Ardour to another, there is this massive explosion and then Ardour
>>>>>> crashes. So there you go, you don't always have the option of
>>>>>> pre-scoping.
>>>>>>
>>>>>> Well what the hell, I like to live dangerously and that's certainly
>>>>>> possible
>>>>>> with Csound ;-)
>>>>>> Best,
>>>>>> Peiman
>>>>>>
>>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>>
>>>>>> But if "blow-up insurance" is built back into Csound, it would ruin
>>>>>> the
>>>>>> hilarity of the "basic proficiency test" that takes place during the
>>>>>> point
>>>>>> in class that Dr. B describes! I was in last semester's class... he
>>>>>> left
>>>>>> the
>>>>>> room and it was like a game of whack-a-mole of people yelling curse
>>>>>> words
>>>>>> and horrendous square waveforms coming out of headphones...
>>>>>> This is why I scope every .csd I make. Step 1, mute speakers and run
>>>>>> csd.
>>>>>> Step 2, look at scope. If the scope is straight up and down lines, DO
>>>>>> NOT
>>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>>> It's charming... kinda.
>>>>>> -Nick
>>>>>>
>>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>>  wrote:
>>>>>>>
>>>>>>> This is/was (among other things) what the PEAK chunk is/was for.
>>>>>>> Write
>>>>>>> floats to a file, without clipping, and with PEAK info. When a file
>>>>>>> with the
>>>>>>> PEAK chunk was read into Csound, if the peaks were over-range they
>>>>>>> were
>>>>>>> automatically rescaled. This was all working back in v4.23. Doubtless
>>>>>>> with
>>>>>>> the move to libsndfile that code has all gone (though the original
>>>>>>> structure
>>>>>>> field "do_floatscaling" seems still to be around), but in principle
>>>>>>> it
>>>>>>> should be able to be reintroduced (libsndfile does know about the
>>>>>>> PEAK
>>>>>>> chunk
>>>>>>> so Csound can still obtain that info). But then users have to get
>>>>>>> used
>>>>>>> to
>>>>>>> having the PEAK chunk in their files (some really old naff software
>>>>>>> might
>>>>>>> not understand, and fail to read the file properly), and I saw quite
>>>>>>> a
>>>>>>> lot
>>>>>>> of resistance to that.
>>>>>>>
>>>>>>> Of course for real-time rendering, there is no solution other than to
>>>>>>> be
>>>>>>> careful, or apply some sort of limiter. And limiters are not exactly
>>>>>>> transparent.  Csound has historically been an "open" system in that
>>>>>>> it
>>>>>>> does
>>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>>
>>>>>>>
>>>>>>> Richard Dobson
>>>>>>>
>>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>>> ..
>>>>>>>>
>>>>>>>> Back in the day, Matt Ingalls used to have an option in MacCsound
>>>>>>>> where
>>>>>>>> you could render to floats, and then it would do a float to int
>>>>>>>> conversion prior to playback - and this gave a lot more headroom -
>>>>>>>> and
>>>>>>>> a
>>>>>>>> lot less pain, but...... is there a way to solve this problem at a
>>>>>>>> deeper and yet more transparent level. In Csound or PortAudio or
>>>>>>>> QuteCsound.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nick Suda
>>>>>> Renton, WA/Boston, MA
>>>>>> nick.suda@gmail.com
>>>>>> (425) 941-0093
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Andrés
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

That seems to be HW-dependent: with my macbook soundcard, above 0dbfs  
there is a slight increase in amplitude up to the point when the HW is  
blown off (about 10 times 0dbfs) and then you have to reboot to get it  
working again. With an m-audio quattro (what I have at hand to test),  
you just get a clipped signal that is not of any higher amplitude than  
the signal at 0dbfs, sometimes less, depending on the amount of  
clipping. It does not explode beyond 0dbfs. Similar thing with other  
soundcards I have used, including the typical Dell PC onboard soundcard.

I think Apple have got it wrong with their HW, this behaviour is very  
suspicious of a bad design.

Victor

On 19 Feb 2010, at 13:25, Oeyvind Brandtsegg wrote:

> Actually, I have to disagree.
> Playing sounds at 0dbfs should not damage anything,
> but when the audio system tries to reproduce a signal that exceeds
> 0dbfs by several orders of magnitude, the output enegry is much higher
> than just playing a nonclipped signal at 0dbfs.
>
> Try to comment out the line
> a1      = a1*gkScale
> in the csd I just sent,
> and play it *at low level* for safety
>
> With this line in, we rescale nicely to just below 1.0 regardless of
> the original signal overload.
>
> Oeyvind
>
> 2010/2/19 Victor Lazzarini :
>> But what you call out-of-range surely means well below 0dbfs?  
>> Otherwise,
>> there is no advantage, because anything above that will have a RMS  
>> = 0dbfs
>> anyway, which sounds just below 0dbfs might very well be quite  
>> close to.
>> So before the scaling kicks in, we're in trouble.
>>
>> Victor
>>
>>
>> On 19 Feb 2010, at 12:51, Oeyvind Brandtsegg wrote:
>>
>>> I think scaling would be better in this case than limiting/clipping,
>>> as clipping is what we get anyway (as you also say).
>>> And scaling the output so that it won't clip will take away the
>>> excessive energy burst associated this kind of user error.
>>> The amplifier gain, of course is the responsibility of the user. As
>>> long as Csound automatically downscales out-of-range audio, we  
>>> should
>>> be fine. Of course, some users might turn up their amplifier gain to
>>> compensate, but that is out of our hands anyway. A solidly visible
>>> message about the output rescaling should be printed when Csound
>>> exits, so as to help the user understand that it's the orchestra  
>>> that
>>> needs fixing, not the amp.
>>>
>>> Oeyvind
>>>
>>> 2010/2/19 Victor Lazzarini :
>>>>
>>>> But I think the problem seems to be that if it reaches clipping  
>>>> levels
>>>> (0dbfs), then it's too late. Of course, you can't go above   
>>>> 0dbfs. I
>>>> still
>>>> think you can put a clip before out and that would help. But it  
>>>> won't if
>>>> you
>>>> keep turning the amplifier gain higher  and higher to compensate.
>>>>
>>>>
>>>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>>>
>>>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>>>
>>>>> If the output level (in spout probably) is above the max value
>>>>> (0dbfs), output is automatically scaled down.
>>>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>>>
>>>>> This will indeed create glitches when the scale factor is  
>>>>> recalculated
>>>>> (when the maxlevel is exceeded),
>>>>> but such a noticeable glitch can also give the user an  
>>>>> indication that
>>>>> something has gone over the top,
>>>>> without causing actual ear or speaker damage.
>>>>> This feature could be enabled via a command line flag, and it  
>>>>> should
>>>>> report the max level and/or scale factor arrived at when Csound is
>>>>> done. Also print a kind note to the user suggesting the levels in
>>>>> instruments be checked...
>>>>>
>>>>> The normalize threshold could of course be set to something less  
>>>>> than
>>>>> 0dbfs, but I can't really see why that would be useful.
>>>>>
>>>>> best
>>>>> Oeyvind
>>>>>
>>>>> 2010/2/19 Andres Cabrera :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I agree it would be great to have some sort of protection...  
>>>>>> I'm sure
>>>>>> we've all blown our ears at least once using csound....
>>>>>>
>>>>>> But I'm not sure how it would be implemented, since it depends  
>>>>>> greatly
>>>>>> on the monitoring level. No matter how quick and effective a  
>>>>>> limiter
>>>>>> is, it can't know the level the user is monitoring at, so it  
>>>>>> can't
>>>>>> really offer any real protection, because when people are  
>>>>>> working,
>>>>>> they might be working with very soft sources, and therefore  
>>>>>> turn the
>>>>>> monitoring level high up, and then when a much larger source  
>>>>>> comes
>>>>>> through, even if it's not a really loud one under other  
>>>>>> conditions, it
>>>>>> will blow the person's ears.
>>>>>>
>>>>>> So what I mean to say is that in practice, to have such a  
>>>>>> protection,
>>>>>> you must know beforehand the monitoring level, or the maximum
>>>>>> permitted amplitude (in the case of speaker protection), but for
>>>>>> Csound where monitoring levels are so variable, such a system  
>>>>>> is not
>>>>>> possible. The best thing, would be as part of the introductory  
>>>>>> csds
>>>>>> have a way of scaring people a bit about the huge dynamic range  
>>>>>> Csound
>>>>>> can produce, without actually doing any damage, but enough of a  
>>>>>> scare
>>>>>> that they will be careful when monitoring (look at the meters  
>>>>>> first,
>>>>>> make sure you are not working at too low amplitudes and high
>>>>>> monitoring levels, etc.)
>>>>>>
>>>>>> Anyone want to write such a csd?
>>>>>>
>>>>>> Cheers,
>>>>>> Andrés
>>>>>>
>>>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>>>  wrote:
>>>>>>>
>>>>>>> OK this is kind of not related but I found a weird bug either  
>>>>>>> with
>>>>>>> csladspa
>>>>>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>>>>>> channel
>>>>>>> strip
>>>>>>> of Ardour to another, there is this massive explosion and then  
>>>>>>> Ardour
>>>>>>> crashes. So there you go, you don't always have the option of
>>>>>>> pre-scoping.
>>>>>>>
>>>>>>> Well what the hell, I like to live dangerously and that's  
>>>>>>> certainly
>>>>>>> possible
>>>>>>> with Csound ;-)
>>>>>>> Best,
>>>>>>> Peiman
>>>>>>>
>>>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>>>
>>>>>>> But if "blow-up insurance" is built back into Csound, it would  
>>>>>>> ruin
>>>>>>> the
>>>>>>> hilarity of the "basic proficiency test" that takes place  
>>>>>>> during the
>>>>>>> point
>>>>>>> in class that Dr. B describes! I was in last semester's  
>>>>>>> class... he
>>>>>>> left
>>>>>>> the
>>>>>>> room and it was like a game of whack-a-mole of people yelling  
>>>>>>> curse
>>>>>>> words
>>>>>>> and horrendous square waveforms coming out of headphones...
>>>>>>> This is why I scope every .csd I make. Step 1, mute speakers  
>>>>>>> and run
>>>>>>> csd.
>>>>>>> Step 2, look at scope. If the scope is straight up and down  
>>>>>>> lines, DO
>>>>>>> NOT
>>>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>>>> It's charming... kinda.
>>>>>>> -Nick
>>>>>>>
>>>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> This is/was (among other things) what the PEAK chunk is/was  
>>>>>>>> for.
>>>>>>>> Write
>>>>>>>> floats to a file, without clipping, and with PEAK info. When  
>>>>>>>> a file
>>>>>>>> with the
>>>>>>>> PEAK chunk was read into Csound, if the peaks were over-range  
>>>>>>>> they
>>>>>>>> were
>>>>>>>> automatically rescaled. This was all working back in v4.23.  
>>>>>>>> Doubtless
>>>>>>>> with
>>>>>>>> the move to libsndfile that code has all gone (though the  
>>>>>>>> original
>>>>>>>> structure
>>>>>>>> field "do_floatscaling" seems still to be around), but in  
>>>>>>>> principle
>>>>>>>> it
>>>>>>>> should be able to be reintroduced (libsndfile does know about  
>>>>>>>> the
>>>>>>>> PEAK
>>>>>>>> chunk
>>>>>>>> so Csound can still obtain that info). But then users have to  
>>>>>>>> get
>>>>>>>> used
>>>>>>>> to
>>>>>>>> having the PEAK chunk in their files (some really old naff  
>>>>>>>> software
>>>>>>>> might
>>>>>>>> not understand, and fail to read the file properly), and I  
>>>>>>>> saw quite
>>>>>>>> a
>>>>>>>> lot
>>>>>>>> of resistance to that.
>>>>>>>>
>>>>>>>> Of course for real-time rendering, there is no solution other  
>>>>>>>> than to
>>>>>>>> be
>>>>>>>> careful, or apply some sort of limiter. And limiters are not  
>>>>>>>> exactly
>>>>>>>> transparent.  Csound has historically been an "open" system  
>>>>>>>> in that
>>>>>>>> it
>>>>>>>> does
>>>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Dobson
>>>>>>>>
>>>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>>>> ..
>>>>>>>>>
>>>>>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>>>>>> MacCsound
>>>>>>>>> where
>>>>>>>>> you could render to floats, and then it would do a float to  
>>>>>>>>> int
>>>>>>>>> conversion prior to playback - and this gave a lot more  
>>>>>>>>> headroom -
>>>>>>>>> and
>>>>>>>>> a
>>>>>>>>> lot less pain, but...... is there a way to solve this  
>>>>>>>>> problem at a
>>>>>>>>> deeper and yet more transparent level. In Csound or  
>>>>>>>>> PortAudio or
>>>>>>>>> QuteCsound.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Send bugs reports to this list.
>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>>> "unsubscribe
>>>>>>>> csound"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nick Suda
>>>>>>> Renton, WA/Boston, MA
>>>>>>> nick.suda@gmail.com
>>>>>>> (425) 941-0093
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Andrés
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

A simple solution that might work is to do this:

1) add a 0dbfs =  100000  to the header if there is none
2) change the 0dbfs by a factor of two or more if there is one

You will get extra headroom. You can can give yourself more of it if  
you need.

Victor


On 19 Feb 2010, at 14:37, Victor Lazzarini wrote:

> That seems to be HW-dependent: with my macbook soundcard, above  
> 0dbfs there is a slight increase in amplitude up to the point when  
> the HW is blown off (about 10 times 0dbfs) and then you have to  
> reboot to get it working again. With an m-audio quattro (what I have  
> at hand to test), you just get a clipped signal that is not of any  
> higher amplitude than the signal at 0dbfs, sometimes less, depending  
> on the amount of clipping. It does not explode beyond 0dbfs. Similar  
> thing with other soundcards I have used, including the typical Dell  
> PC onboard soundcard.
>
> I think Apple have got it wrong with their HW, this behaviour is  
> very suspicious of a bad design.
>
> Victor
>
> On 19 Feb 2010, at 13:25, Oeyvind Brandtsegg wrote:
>
>> Actually, I have to disagree.
>> Playing sounds at 0dbfs should not damage anything,
>> but when the audio system tries to reproduce a signal that exceeds
>> 0dbfs by several orders of magnitude, the output enegry is much  
>> higher
>> than just playing a nonclipped signal at 0dbfs.
>>
>> Try to comment out the line
>> a1      = a1*gkScale
>> in the csd I just sent,
>> and play it *at low level* for safety
>>
>> With this line in, we rescale nicely to just below 1.0 regardless of
>> the original signal overload.
>>
>> Oeyvind
>>
>> 2010/2/19 Victor Lazzarini :
>>> But what you call out-of-range surely means well below 0dbfs?  
>>> Otherwise,
>>> there is no advantage, because anything above that will have a RMS  
>>> = 0dbfs
>>> anyway, which sounds just below 0dbfs might very well be quite  
>>> close to.
>>> So before the scaling kicks in, we're in trouble.
>>>
>>> Victor
>>>
>>>
>>> On 19 Feb 2010, at 12:51, Oeyvind Brandtsegg wrote:
>>>
>>>> I think scaling would be better in this case than limiting/ 
>>>> clipping,
>>>> as clipping is what we get anyway (as you also say).
>>>> And scaling the output so that it won't clip will take away the
>>>> excessive energy burst associated this kind of user error.
>>>> The amplifier gain, of course is the responsibility of the user. As
>>>> long as Csound automatically downscales out-of-range audio, we  
>>>> should
>>>> be fine. Of course, some users might turn up their amplifier gain  
>>>> to
>>>> compensate, but that is out of our hands anyway. A solidly visible
>>>> message about the output rescaling should be printed when Csound
>>>> exits, so as to help the user understand that it's the orchestra  
>>>> that
>>>> needs fixing, not the amp.
>>>>
>>>> Oeyvind
>>>>
>>>> 2010/2/19 Victor Lazzarini :
>>>>>
>>>>> But I think the problem seems to be that if it reaches clipping  
>>>>> levels
>>>>> (0dbfs), then it's too late. Of course, you can't go above   
>>>>> 0dbfs. I
>>>>> still
>>>>> think you can put a clip before out and that would help. But it  
>>>>> won't if
>>>>> you
>>>>> keep turning the amplifier gain higher  and higher to compensate.
>>>>>
>>>>>
>>>>> On 19 Feb 2010, at 12:28, Oeyvind Brandtsegg wrote:
>>>>>
>>>>>> Maybe we could do an "auto-normalizer" sort of thing.
>>>>>>
>>>>>> If the output level (in spout probably) is above the max value
>>>>>> (0dbfs), output is automatically scaled down.
>>>>>> The scale factor can be calculated as: 0dbfs/currentMaxLevel
>>>>>>
>>>>>> This will indeed create glitches when the scale factor is  
>>>>>> recalculated
>>>>>> (when the maxlevel is exceeded),
>>>>>> but such a noticeable glitch can also give the user an  
>>>>>> indication that
>>>>>> something has gone over the top,
>>>>>> without causing actual ear or speaker damage.
>>>>>> This feature could be enabled via a command line flag, and it  
>>>>>> should
>>>>>> report the max level and/or scale factor arrived at when Csound  
>>>>>> is
>>>>>> done. Also print a kind note to the user suggesting the levels in
>>>>>> instruments be checked...
>>>>>>
>>>>>> The normalize threshold could of course be set to something  
>>>>>> less than
>>>>>> 0dbfs, but I can't really see why that would be useful.
>>>>>>
>>>>>> best
>>>>>> Oeyvind
>>>>>>
>>>>>> 2010/2/19 Andres Cabrera :
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I agree it would be great to have some sort of protection...  
>>>>>>> I'm sure
>>>>>>> we've all blown our ears at least once using csound....
>>>>>>>
>>>>>>> But I'm not sure how it would be implemented, since it depends  
>>>>>>> greatly
>>>>>>> on the monitoring level. No matter how quick and effective a  
>>>>>>> limiter
>>>>>>> is, it can't know the level the user is monitoring at, so it  
>>>>>>> can't
>>>>>>> really offer any real protection, because when people are  
>>>>>>> working,
>>>>>>> they might be working with very soft sources, and therefore  
>>>>>>> turn the
>>>>>>> monitoring level high up, and then when a much larger source  
>>>>>>> comes
>>>>>>> through, even if it's not a really loud one under other  
>>>>>>> conditions, it
>>>>>>> will blow the person's ears.
>>>>>>>
>>>>>>> So what I mean to say is that in practice, to have such a  
>>>>>>> protection,
>>>>>>> you must know beforehand the monitoring level, or the maximum
>>>>>>> permitted amplitude (in the case of speaker protection), but for
>>>>>>> Csound where monitoring levels are so variable, such a system  
>>>>>>> is not
>>>>>>> possible. The best thing, would be as part of the introductory  
>>>>>>> csds
>>>>>>> have a way of scaring people a bit about the huge dynamic  
>>>>>>> range Csound
>>>>>>> can produce, without actually doing any damage, but enough of  
>>>>>>> a scare
>>>>>>> that they will be careful when monitoring (look at the meters  
>>>>>>> first,
>>>>>>> make sure you are not working at too low amplitudes and high
>>>>>>> monitoring levels, etc.)
>>>>>>>
>>>>>>> Anyone want to write such a csd?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andrés
>>>>>>>
>>>>>>> On Thu, Feb 18, 2010 at 11:44 PM, Peiman Khosravi
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> OK this is kind of not related but I found a weird bug either  
>>>>>>>> with
>>>>>>>> csladspa
>>>>>>>> or aurdour, or both. When I copy a csladspa plug-in form one  
>>>>>>>> channel
>>>>>>>> strip
>>>>>>>> of Ardour to another, there is this massive explosion and  
>>>>>>>> then Ardour
>>>>>>>> crashes. So there you go, you don't always have the option of
>>>>>>>> pre-scoping.
>>>>>>>>
>>>>>>>> Well what the hell, I like to live dangerously and that's  
>>>>>>>> certainly
>>>>>>>> possible
>>>>>>>> with Csound ;-)
>>>>>>>> Best,
>>>>>>>> Peiman
>>>>>>>>
>>>>>>>> On 18 Feb 2010, at 23:38, Nick Suda wrote:
>>>>>>>>
>>>>>>>> But if "blow-up insurance" is built back into Csound, it  
>>>>>>>> would ruin
>>>>>>>> the
>>>>>>>> hilarity of the "basic proficiency test" that takes place  
>>>>>>>> during the
>>>>>>>> point
>>>>>>>> in class that Dr. B describes! I was in last semester's  
>>>>>>>> class... he
>>>>>>>> left
>>>>>>>> the
>>>>>>>> room and it was like a game of whack-a-mole of people yelling  
>>>>>>>> curse
>>>>>>>> words
>>>>>>>> and horrendous square waveforms coming out of headphones...
>>>>>>>> This is why I scope every .csd I make. Step 1, mute speakers  
>>>>>>>> and run
>>>>>>>> csd.
>>>>>>>> Step 2, look at scope. If the scope is straight up and down  
>>>>>>>> lines, DO
>>>>>>>> NOT
>>>>>>>> UNMUTE. Step 3, if the coast is clear, unmute!
>>>>>>>> It's charming... kinda.
>>>>>>>> -Nick
>>>>>>>>
>>>>>>>> On Thu, Feb 18, 2010 at 6:32 PM, Richard Dobson
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> This is/was (among other things) what the PEAK chunk is/was  
>>>>>>>>> for.
>>>>>>>>> Write
>>>>>>>>> floats to a file, without clipping, and with PEAK info. When  
>>>>>>>>> a file
>>>>>>>>> with the
>>>>>>>>> PEAK chunk was read into Csound, if the peaks were over- 
>>>>>>>>> range they
>>>>>>>>> were
>>>>>>>>> automatically rescaled. This was all working back in v4.23.  
>>>>>>>>> Doubtless
>>>>>>>>> with
>>>>>>>>> the move to libsndfile that code has all gone (though the  
>>>>>>>>> original
>>>>>>>>> structure
>>>>>>>>> field "do_floatscaling" seems still to be around), but in  
>>>>>>>>> principle
>>>>>>>>> it
>>>>>>>>> should be able to be reintroduced (libsndfile does know  
>>>>>>>>> about the
>>>>>>>>> PEAK
>>>>>>>>> chunk
>>>>>>>>> so Csound can still obtain that info). But then users have  
>>>>>>>>> to get
>>>>>>>>> used
>>>>>>>>> to
>>>>>>>>> having the PEAK chunk in their files (some really old naff  
>>>>>>>>> software
>>>>>>>>> might
>>>>>>>>> not understand, and fail to read the file properly), and I  
>>>>>>>>> saw quite
>>>>>>>>> a
>>>>>>>>> lot
>>>>>>>>> of resistance to that.
>>>>>>>>>
>>>>>>>>> Of course for real-time rendering, there is no solution  
>>>>>>>>> other than to
>>>>>>>>> be
>>>>>>>>> careful, or apply some sort of limiter. And limiters are not  
>>>>>>>>> exactly
>>>>>>>>> transparent.  Csound has historically been an "open" system  
>>>>>>>>> in that
>>>>>>>>> it
>>>>>>>>> does
>>>>>>>>> not hold your hand - "with great freedom..." etc.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard Dobson
>>>>>>>>>
>>>>>>>>> On 18/02/2010 22:24, Dr. Richard Boulanger wrote:
>>>>>>>>> ..
>>>>>>>>>>
>>>>>>>>>> Back in the day, Matt Ingalls used to have an option in  
>>>>>>>>>> MacCsound
>>>>>>>>>> where
>>>>>>>>>> you could render to floats, and then it would do a float to  
>>>>>>>>>> int
>>>>>>>>>> conversion prior to playback - and this gave a lot more  
>>>>>>>>>> headroom -
>>>>>>>>>> and
>>>>>>>>>> a
>>>>>>>>>> lot less pain, but...... is there a way to solve this  
>>>>>>>>>> problem at a
>>>>>>>>>> deeper and yet more transparent level. In Csound or  
>>>>>>>>>> PortAudio or
>>>>>>>>>> QuteCsound.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Send bugs reports to this list.
>>>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>>>> "unsubscribe
>>>>>>>>> csound"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nick Suda
>>>>>>>> Renton, WA/Boston, MA
>>>>>>>> nick.suda@gmail.com
>>>>>>>> (425) 941-0093
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Andrés
>>>>>>>
>>>>>>>
>>>>>>> Send bugs reports to this list.
>>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>>>> "unsubscribe
>>>>>>> csound"
>>>>>>
>>>>>>
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>>> "unsubscribe
>>>>>> csound"
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"