Hi list,

I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.

Best,
Martin

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Hi,

thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program. That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere. 

I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.

My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.

Any suggestions concerning this topic?

Best,
Martin


Am 14.03.2013 um 14:25 schrieb peiman khosravi:

> 
> 
> On 14 March 2013 13:23, Justin Smith  wrote:
> Will csound actually crash from excessive amplitudes?
> 
> Of course not. 
> 
> In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
> 
> The "active" opcode will tell you how many instances of an instrument are running.
> 
> 
> On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
> Hi list,
> 
> I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
> 
> Best,
> Martin

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Maybe its easier to understand, if the problem is posed the following way (pseudocode):

global value semaphore := 0

instr 1
	if started then
		semaphore := semaphore + 1
	if stopped then
		semaphore := semaphore - 1

	do stuff, maybe using the value of semaphore
endin
:
:
:
instr n
	if started then
		semaphore := semaphore + 1
	if stopped then
		semaphore := semaphore - 1

	do some other stuff here, maybe using the value of semaphore
endin

The idea is, to store in semaphore the number of instances of any instrument with numbers 1,...,n running. Of course, there may be other instruments n+1,...,n+k that don't increment/decrement the semaphore for some kind of reason. 

How do I implement this in Csound?

Best,
Martin

PS: As one can easily see, this method may be used to compute a global amplitude factor, as peiman khosravi suggests. It stems from the idea, that a fixed global amplitude factor would not be the best solution, since it may leave the signal to low, when only one or two instruments are running and it may cause overflow if too many instances of instruments are running.

Am 14.03.2013 um 14:57 schrieb Martin Huenniger:

> Hi,
> 
> thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program. That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere. 
> 
> I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.
> 
> My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.
> 
> Any suggestions concerning this topic?
> 
> Best,
> Martin
> 
> 
> Am 14.03.2013 um 14:25 schrieb peiman khosravi:
> 
>> 
>> 
>> On 14 March 2013 13:23, Justin Smith  wrote:
>> Will csound actually crash from excessive amplitudes?
>> 
>> Of course not. 
>> 
>> In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
>> 
>> The "active" opcode will tell you how many instances of an instrument are running.
>> 
>> 
>> On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
>> Hi list,
>> 
>> I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
>> 
>> Best,
>> Martin
> 
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Asprviously suggested, active opcode will tell you the same and is
automatically incremented/decremented by the csound engine.  In general it
is hard to discover that an instrument is about to stop.

active 0 will report total number of active instruments, or you need a
loop from 1 to n

==John ff


> Maybe its easier to understand, if the problem is posed the following way
> (pseudocode):
>
> global value semaphore := 0
>
> instr 1
> 	if started then
> 		semaphore := semaphore + 1
> 	if stopped then
> 		semaphore := semaphore - 1
>
> 	do stuff, maybe using the value of semaphore
> endin
> :
> :
> :
> instr n
> 	if started then
> 		semaphore := semaphore + 1
> 	if stopped then
> 		semaphore := semaphore - 1
>
> 	do some other stuff here, maybe using the value of semaphore
> endin
>
> The idea is, to store in semaphore the number of instances of any
> instrument with numbers 1,...,n running. Of course, there may be other
> instruments n+1,...,n+k that don't increment/decrement the semaphore for
> some kind of reason.
>
> How do I implement this in Csound?
>
> Best,
> Martin
>
> PS: As one can easily see, this method may be used to compute a global
> amplitude factor, as peiman khosravi suggests. It stems from the idea,
> that a fixed global amplitude factor would not be the best solution, since
> it may leave the signal to low, when only one or two instruments are
> running and it may cause overflow if too many instances of instruments are
> running.
>
> Am 14.03.2013 um 14:57 schrieb Martin Huenniger:
>
>> Hi,
>>
>> thanks for your replies, but that is not the problem. The background is
>> that I have this csound patch which plays a number of samples and at
>> some point, when enough samples are started and some audio-overflow (or
>> clipping) occurs, the audio-output will stop and i have to restart the
>> whole program. That's what I would consider a crash. Yes, I do not know
>> the maximum amplitude since the samples interact, but I want to keep
>> sure to have enough headroom, so that it won't matter. But the existence
>> of the overflow behavior is not the question. I know this from other
>> software as well and it seems completely reasonable to me and is
>> discussed extensively elsewhere.
>>
>> I don't think a limiter would help here, since if you have sounds which
>> do not clip or overflow but do overflow if played together then a
>> limiter might provide no help here, since the overflow would occur
>> before the limiter is able to detect the signal. But again, this is not
>> the fact I want to discuss.
>>
>> My question is just how to implement this semaphore concept, which might
>> be interesting not only in the context of avoiding this overflow issue,
>> but also in other circumstances, although the first use is right now
>> more important to me.
>>
>> Any suggestions concerning this topic?
>>
>> Best,
>> Martin
>>
>>
>> Am 14.03.2013 um 14:25 schrieb peiman khosravi:
>>
>>>
>>>
>>> On 14 March 2013 13:23, Justin Smith  wrote:
>>> Will csound actually crash from excessive amplitudes?
>>>
>>> Of course not.
>>>
>>> In my experience I can just use a global amplitude factor and adjust
>>> that as needed, I have never seen an amplitude based crash.
>>>
>>> The "active" opcode will tell you how many instances of an instrument
>>> are running.
>>>
>>>
>>> On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger
>>>  wrote:
>>> Hi list,
>>>
>>> I had the following idea to address the crashing of csound from audio
>>> overflow: Anytime an instrument is started, a global variable (a
>>> semaphore) should be incremented and if an instrument stops this
>>> variable will be decremented again. The value of this variable is then
>>> used to lower the output of all instruments playing, thereby
>>> (hopefully) preventing audio overflows. My problem is how to achieve
>>> this. Has this semaphore to be a control rate variable? or init-time?
>>> And how do I achieve the behavior that the semaphore gets incremented
>>> only once when the instrument is initialized and decremented once the
>>> instrument is stopped? Your advice is much appreciated.
>>>
>>> Best,
>>> Martin
>>
>> _________________________
>> Martin Hünniger
>> a_s_tarantoga@yahoo.de
>> a-s-tarantoga.tumblr.com
>> soundcloud.com/a_s_tarantoga
>>
>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>

I just thought I'd chip in that this "crash" behavior has happened to me as well when using csgrain on my iPad (gen 3). When abusing csgrain turning everything up to 11, especially reverb size and mix level, there is some really impressively harsh howling and the it goes silent. I can't get sound out of it again without restarting the app. I have not investigated systematically but it has happened a couple of times. 
I don't offer any solution (sorry) but thought it would be good to know it has happened to others as well. 

Regards,
Anders

14 mar 2013 kl. 14:57 skrev Martin Huenniger :

> Hi,
> 
> thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program. That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere. 
> 
> I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.
> 
> My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.
> 
> Any suggestions concerning this topic?
> 
> Best,
> Martin
> 
> 
> Am 14.03.2013 um 14:25 schrieb peiman khosravi:
> 
>> 
>> 
>> On 14 March 2013 13:23, Justin Smith  wrote:
>> Will csound actually crash from excessive amplitudes?
>> 
>> Of course not. 
>> 
>> In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
>> 
>> The "active" opcode will tell you how many instances of an instrument are running.
>> 
>> 
>> On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
>> Hi list,
>> 
>> I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
>> 
>> Best,
>> Martin
> 
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Hi John,

thank you. now I understand. that's quite convenient. I thought that it may be quite hard to determine, if an instrument stops. 

Best,
Martin

 
Am 14.03.2013 um 16:15 schrieb jpff@cs.bath.ac.uk:

> Asprviously suggested, active opcode will tell you the same and is
> automatically incremented/decremented by the csound engine.  In general it
> is hard to discover that an instrument is about to stop.
> 
> active 0 will report total number of active instruments, or you need a
> loop from 1 to n
> 
> ==John ff
> 
> 
>> Maybe its easier to understand, if the problem is posed the following way
>> (pseudocode):
>> 
>> global value semaphore := 0
>> 
>> instr 1
>> 	if started then
>> 		semaphore := semaphore + 1
>> 	if stopped then
>> 		semaphore := semaphore - 1
>> 
>> 	do stuff, maybe using the value of semaphore
>> endin
>> :
>> :
>> :
>> instr n
>> 	if started then
>> 		semaphore := semaphore + 1
>> 	if stopped then
>> 		semaphore := semaphore - 1
>> 
>> 	do some other stuff here, maybe using the value of semaphore
>> endin
>> 
>> The idea is, to store in semaphore the number of instances of any
>> instrument with numbers 1,...,n running. Of course, there may be other
>> instruments n+1,...,n+k that don't increment/decrement the semaphore for
>> some kind of reason.
>> 
>> How do I implement this in Csound?
>> 
>> Best,
>> Martin
>> 
>> PS: As one can easily see, this method may be used to compute a global
>> amplitude factor, as peiman khosravi suggests. It stems from the idea,
>> that a fixed global amplitude factor would not be the best solution, since
>> it may leave the signal to low, when only one or two instruments are
>> running and it may cause overflow if too many instances of instruments are
>> running.
>> 
>> Am 14.03.2013 um 14:57 schrieb Martin Huenniger:
>> 
>>> Hi,
>>> 
>>> thanks for your replies, but that is not the problem. The background is
>>> that I have this csound patch which plays a number of samples and at
>>> some point, when enough samples are started and some audio-overflow (or
>>> clipping) occurs, the audio-output will stop and i have to restart the
>>> whole program. That's what I would consider a crash. Yes, I do not know
>>> the maximum amplitude since the samples interact, but I want to keep
>>> sure to have enough headroom, so that it won't matter. But the existence
>>> of the overflow behavior is not the question. I know this from other
>>> software as well and it seems completely reasonable to me and is
>>> discussed extensively elsewhere.
>>> 
>>> I don't think a limiter would help here, since if you have sounds which
>>> do not clip or overflow but do overflow if played together then a
>>> limiter might provide no help here, since the overflow would occur
>>> before the limiter is able to detect the signal. But again, this is not
>>> the fact I want to discuss.
>>> 
>>> My question is just how to implement this semaphore concept, which might
>>> be interesting not only in the context of avoiding this overflow issue,
>>> but also in other circumstances, although the first use is right now
>>> more important to me.
>>> 
>>> Any suggestions concerning this topic?
>>> 
>>> Best,
>>> Martin
>>> 
>>> 
>>> Am 14.03.2013 um 14:25 schrieb peiman khosravi:
>>> 
>>>> 
>>>> 
>>>> On 14 March 2013 13:23, Justin Smith  wrote:
>>>> Will csound actually crash from excessive amplitudes?
>>>> 
>>>> Of course not.
>>>> 
>>>> In my experience I can just use a global amplitude factor and adjust
>>>> that as needed, I have never seen an amplitude based crash.
>>>> 
>>>> The "active" opcode will tell you how many instances of an instrument
>>>> are running.
>>>> 
>>>> 
>>>> On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger
>>>>  wrote:
>>>> Hi list,
>>>> 
>>>> I had the following idea to address the crashing of csound from audio
>>>> overflow: Anytime an instrument is started, a global variable (a
>>>> semaphore) should be incremented and if an instrument stops this
>>>> variable will be decremented again. The value of this variable is then
>>>> used to lower the output of all instruments playing, thereby
>>>> (hopefully) preventing audio overflows. My problem is how to achieve
>>>> this. Has this semaphore to be a control rate variable? or init-time?
>>>> And how do I achieve the behavior that the semaphore gets incremented
>>>> only once when the instrument is initialized and decremented once the
>>>> instrument is stopped? Your advice is much appreciated.
>>>> 
>>>> Best,
>>>> Martin
>>> 
>>> _________________________
>>> Martin Hünniger
>>> a_s_tarantoga@yahoo.de
>>> a-s-tarantoga.tumblr.com
>>> soundcloud.com/a_s_tarantoga
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>> 
>> 
>> _________________________
>> Martin Hünniger
>> a_s_tarantoga@yahoo.de
>> a-s-tarantoga.tumblr.com
>> soundcloud.com/a_s_tarantoga
>> 
>> 
>> 
>> 
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Hi

I don't think it's the number of samples/buffers etc. it's clearly related to amplitudes. It happens also if you do additive synthesis with a number of sines and at some point the addition of amplitudes causes an overflow which kills the audio-engine. It happens on different devices (mac, iphone) and is also present in different software (SuperCollider for example). I think this is a common problem, immanent to the digital nature of the sound synthesis. The usual way to avoid this is to lower the amplitude of each instrument/sine/sample/buffer playing. But to use a fixed value to decrease the amplitude won't solve the problem if it is unknown how many sound generators you mix together.

I just had an idea how to do stuff if an instrument start/stops: Maybe one could use the scoreline opcode in the following way

instr 1
	kstartstop = p4
	kinstance = p5
	ktrig = 1
	if kstartstop == 1 then
		String sprintfk {{ i 2.%d -1 }}, kinstance
		scoreline String, ktrig

		; do start-related stuff
	else
		String sprintfk {{ i -2.%d -1 }}, kinstance
		scoreline String, ktrig

		; do stop-related stuff
	endif
	ktrig = 0
endin

inst 2
	do instrument-magic
endin

In the score do

i 1 0 0 1 1 ; start instance 1 of instr 2
i 1 2 0 1 2 ; start instance 2 of instr 2
i 1 4 0 0 2 ; stop instance 2 of instr 2
i 1 8 0 0 1 ; stop instance 1 of instr 2

Best,
Martin


Am 14.03.2013 um 17:22 schrieb peiman khosravi:

> Oh so I guess it's a filter explosion. Still, it's not a clipping issue. It's the same with filter plug-ins in my experience, right?
> 
> P    
> 
> On 14 March 2013 15:56, Justin Smith  wrote:
> peiman: I can recreate the problem with little more than a single foscil going into a mode filter, it is not caused by excess sampling (which would only cause a temporary breakup of audio until the instrument count drops, not a permanent loss of audio as described).
> 
> 
> On Thu, Mar 14, 2013 at 8:53 AM, peiman khosravi  wrote:
> 
> 
> On 14 March 2013 13:57, Martin Huenniger  wrote:
> Hi,
> 
> thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program.
> 
> This is not caused by clipping, it's probably caused by having too many samples open, which is the same as having too many tracks playing in protools, which leads to a buffer overload. It has nothing to do with amplitude levels. The only way to avoid it is by  having some sort of 'polyphonic' management that doesn't allow more than a certain number of instruments to play. It will probably also help if you're reading the sample from a buffer (table).
> 
> P  
>  
> That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere.
> 
> I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.
> 
> My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.
> 
> Any suggestions concerning this topic?
> 
> Best,
> Martin
> 
> 
> Am 14.03.2013 um 14:25 schrieb peiman khosravi:
> 
> >
> >
> > On 14 March 2013 13:23, Justin Smith  wrote:
> > Will csound actually crash from excessive amplitudes?
> >
> > Of course not.
> >
> > In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
> >
> > The "active" opcode will tell you how many instances of an instrument are running.
> >
> >
> > On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
> > Hi list,
> >
> > I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
> >
> > Best,
> > Martin
> 
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 
> 
> 

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

ok. i cannot reproduce it. I really thought it would be related to an overflow problem. hmm. sorry for the buzz. now I'm smarter... I thought I had produced the same behavior some time ago with additive synthesis and made up my own explanation for this, i have to check my sources for what causes the crash, as an crash obviously happens.

Best,
Martin


Am 14.03.2013 um 17:53 schrieb peiman khosravi:

> This is the first tim eI hear this. Can you send an example of a csd with only sine oscillators to demonstrate this?
> 
> P  
> 
> On 14 March 2013 16:49, Martin Huenniger  wrote:
> Hi
> 
> I don't think it's the number of samples/buffers etc. it's clearly related to amplitudes. It happens also if you do additive synthesis with a number of sines and at some point the addition of amplitudes causes an overflow which kills the audio-engine. It happens on different devices (mac, iphone) and is also present in different software (SuperCollider for example). I think this is a common problem, immanent to the digital nature of the sound synthesis. The usual way to avoid this is to lower the amplitude of each instrument/sine/sample/buffer playing. But to use a fixed value to decrease the amplitude won't solve the problem if it is unknown how many sound generators you mix together.
> 
> I just had an idea how to do stuff if an instrument start/stops: Maybe one could use the scoreline opcode in the following way
> 
> instr 1
>         kstartstop = p4
>         kinstance = p5
>         ktrig = 1
>         if kstartstop == 1 then
>                 String sprintfk {{ i 2.%d -1 }}, kinstance
>                 scoreline String, ktrig
> 
>                 ; do start-related stuff
>         else
>                 String sprintfk {{ i -2.%d -1 }}, kinstance
>                 scoreline String, ktrig
> 
>                 ; do stop-related stuff
>         endif
>         ktrig = 0
> endin
> 
> inst 2
>         do instrument-magic
> endin
> 
> In the score do
> 
> i 1 0 0 1 1 ; start instance 1 of instr 2
> i 1 2 0 1 2 ; start instance 2 of instr 2
> i 1 4 0 0 2 ; stop instance 2 of instr 2
> i 1 8 0 0 1 ; stop instance 1 of instr 2
> 
> Best,
> Martin
> 
> 
> Am 14.03.2013 um 17:22 schrieb peiman khosravi:
> 
> > Oh so I guess it's a filter explosion. Still, it's not a clipping issue. It's the same with filter plug-ins in my experience, right?
> >
> > P
> >
> > On 14 March 2013 15:56, Justin Smith  wrote:
> > peiman: I can recreate the problem with little more than a single foscil going into a mode filter, it is not caused by excess sampling (which would only cause a temporary breakup of audio until the instrument count drops, not a permanent loss of audio as described).
> >
> >
> > On Thu, Mar 14, 2013 at 8:53 AM, peiman khosravi  wrote:
> >
> >
> > On 14 March 2013 13:57, Martin Huenniger  wrote:
> > Hi,
> >
> > thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program.
> >
> > This is not caused by clipping, it's probably caused by having too many samples open, which is the same as having too many tracks playing in protools, which leads to a buffer overload. It has nothing to do with amplitude levels. The only way to avoid it is by  having some sort of 'polyphonic' management that doesn't allow more than a certain number of instruments to play. It will probably also help if you're reading the sample from a buffer (table).
> >
> > P
> >
> > That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere.
> >
> > I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.
> >
> > My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.
> >
> > Any suggestions concerning this topic?
> >
> > Best,
> > Martin
> >
> >
> > Am 14.03.2013 um 14:25 schrieb peiman khosravi:
> >
> > >
> > >
> > > On 14 March 2013 13:23, Justin Smith  wrote:
> > > Will csound actually crash from excessive amplitudes?
> > >
> > > Of course not.
> > >
> > > In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
> > >
> > > The "active" opcode will tell you how many instances of an instrument are running.
> > >
> > >
> > > On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
> > > Hi list,
> > >
> > > I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
> > >
> > > Best,
> > > Martin
> >
> > _________________________
> > Martin Hünniger
> > a_s_tarantoga@yahoo.de
> > a-s-tarantoga.tumblr.com
> > soundcloud.com/a_s_tarantoga
> >
> >
> >
> >
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> >
> >
> >
> >
> 
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Hi,

I checked my sources again, and it really seems to be a filter related problem. The samples I mix, enter a flanger and also a lowpass filter and one of them causes the "explosion". Maybe my earlier experience was also related to a similar configuration.

Is there a way to let Csound recognize that a filter has just crashed? 

Best,
Martin 

Am 14.03.2013 um 18:08 schrieb Justin Smith:

> I am very skeptical of the notion that amplitudes alone could ever do this. There is simply no "state" preserved that would interfere with future operation of the sound engine. You can temporarily clip or distort or even get enough DC offset so no frequency actually hits the sound card, but normal operation will resume when amplitudes are lowered.
> 
> With some cards / drivers you could lose sync with the audio device requiring a restart of the driver if you have too many xruns, but amplitudes would not be the cause here, overtaxing the CPU / bad driver design are the culprits here.
> 
> This phenomenon of a bad state causing a drop of audio happens with feedback lines though (filters/reverbs/delays), and higher amplitudes put more stress on the opcodes using feedback lines, but that is a separate issue entirely, and can be alleviated by restarting those opcodes and thus clearing the problematic values from their feedback lines.
> 
> 
> 
> 
> On Thu, Mar 14, 2013 at 9:53 AM, peiman khosravi  wrote:
> This is the first tim eI hear this. Can you send an example of a csd with only sine oscillators to demonstrate this?
> 
> P  
> 
> 
> On 14 March 2013 16:49, Martin Huenniger  wrote:
> Hi
> 
> I don't think it's the number of samples/buffers etc. it's clearly related to amplitudes. It happens also if you do additive synthesis with a number of sines and at some point the addition of amplitudes causes an overflow which kills the audio-engine. It happens on different devices (mac, iphone) and is also present in different software (SuperCollider for example). I think this is a common problem, immanent to the digital nature of the sound synthesis. The usual way to avoid this is to lower the amplitude of each instrument/sine/sample/buffer playing. But to use a fixed value to decrease the amplitude won't solve the problem if it is unknown how many sound generators you mix together.
> 
> I just had an idea how to do stuff if an instrument start/stops: Maybe one could use the scoreline opcode in the following way
> 
> instr 1
>         kstartstop = p4
>         kinstance = p5
>         ktrig = 1
>         if kstartstop == 1 then
>                 String sprintfk {{ i 2.%d -1 }}, kinstance
>                 scoreline String, ktrig
> 
>                 ; do start-related stuff
>         else
>                 String sprintfk {{ i -2.%d -1 }}, kinstance
>                 scoreline String, ktrig
> 
>                 ; do stop-related stuff
>         endif
>         ktrig = 0
> endin
> 
> inst 2
>         do instrument-magic
> endin
> 
> In the score do
> 
> i 1 0 0 1 1 ; start instance 1 of instr 2
> i 1 2 0 1 2 ; start instance 2 of instr 2
> i 1 4 0 0 2 ; stop instance 2 of instr 2
> i 1 8 0 0 1 ; stop instance 1 of instr 2
> 
> Best,
> Martin
> 
> 
> Am 14.03.2013 um 17:22 schrieb peiman khosravi:
> 
> > Oh so I guess it's a filter explosion. Still, it's not a clipping issue. It's the same with filter plug-ins in my experience, right?
> >
> > P
> >
> > On 14 March 2013 15:56, Justin Smith  wrote:
> > peiman: I can recreate the problem with little more than a single foscil going into a mode filter, it is not caused by excess sampling (which would only cause a temporary breakup of audio until the instrument count drops, not a permanent loss of audio as described).
> >
> >
> > On Thu, Mar 14, 2013 at 8:53 AM, peiman khosravi  wrote:
> >
> >
> > On 14 March 2013 13:57, Martin Huenniger  wrote:
> > Hi,
> >
> > thanks for your replies, but that is not the problem. The background is that I have this csound patch which plays a number of samples and at some point, when enough samples are started and some audio-overflow (or clipping) occurs, the audio-output will stop and i have to restart the whole program.
> >
> > This is not caused by clipping, it's probably caused by having too many samples open, which is the same as having too many tracks playing in protools, which leads to a buffer overload. It has nothing to do with amplitude levels. The only way to avoid it is by  having some sort of 'polyphonic' management that doesn't allow more than a certain number of instruments to play. It will probably also help if you're reading the sample from a buffer (table).
> >
> > P
> >
> > That's what I would consider a crash. Yes, I do not know the maximum amplitude since the samples interact, but I want to keep sure to have enough headroom, so that it won't matter. But the existence of the overflow behavior is not the question. I know this from other software as well and it seems completely reasonable to me and is discussed extensively elsewhere.
> >
> > I don't think a limiter would help here, since if you have sounds which do not clip or overflow but do overflow if played together then a limiter might provide no help here, since the overflow would occur before the limiter is able to detect the signal. But again, this is not the fact I want to discuss.
> >
> > My question is just how to implement this semaphore concept, which might be interesting not only in the context of avoiding this overflow issue, but also in other circumstances, although the first use is right now more important to me.
> >
> > Any suggestions concerning this topic?
> >
> > Best,
> > Martin
> >
> >
> > Am 14.03.2013 um 14:25 schrieb peiman khosravi:
> >
> > >
> > >
> > > On 14 March 2013 13:23, Justin Smith  wrote:
> > > Will csound actually crash from excessive amplitudes?
> > >
> > > Of course not.
> > >
> > > In my experience I can just use a global amplitude factor and adjust that as needed, I have never seen an amplitude based crash.
> > >
> > > The "active" opcode will tell you how many instances of an instrument are running.
> > >
> > >
> > > On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger  wrote:
> > > Hi list,
> > >
> > > I had the following idea to address the crashing of csound from audio overflow: Anytime an instrument is started, a global variable (a semaphore) should be incremented and if an instrument stops this variable will be decremented again. The value of this variable is then used to lower the output of all instruments playing, thereby (hopefully) preventing audio overflows. My problem is how to achieve this. Has this semaphore to be a control rate variable? or init-time? And how do I achieve the behavior that the semaphore gets incremented only once when the instrument is initialized and decremented once the instrument is stopped? Your advice is much appreciated.
> > >
> > > Best,
> > > Martin
> >
> > _________________________
> > Martin Hünniger
> > a_s_tarantoga@yahoo.de
> > a-s-tarantoga.tumblr.com
> > soundcloud.com/a_s_tarantoga
> >
> >
> >
> >
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> >
> >
> >
> >
> 
> _________________________
> Martin Hünniger
> a_s_tarantoga@yahoo.de
> a-s-tarantoga.tumblr.com
> soundcloud.com/a_s_tarantoga
> 
> 
> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 
> 

_________________________
Martin Hünniger
a_s_tarantoga@yahoo.de
a-s-tarantoga.tumblr.com
soundcloud.com/a_s_tarantoga

Just wanted to note I've seen this happen here, though I never
investigated. I suspected INF or NAN getting in somewhere.  I haven't
had it happen in a long time, so can't recall the situation in which
it occurred.

On Thu, Mar 14, 2013 at 5:08 PM, Justin Smith  wrote:
> I am very skeptical of the notion that amplitudes alone could ever do this.
> There is simply no "state" preserved that would interfere with future
> operation of the sound engine. You can temporarily clip or distort or even
> get enough DC offset so no frequency actually hits the sound card, but
> normal operation will resume when amplitudes are lowered.
>
> With some cards / drivers you could lose sync with the audio device
> requiring a restart of the driver if you have too many xruns, but amplitudes
> would not be the cause here, overtaxing the CPU / bad driver design are the
> culprits here.
>
> This phenomenon of a bad state causing a drop of audio happens with feedback
> lines though (filters/reverbs/delays), and higher amplitudes put more stress
> on the opcodes using feedback lines, but that is a separate issue entirely,
> and can be alleviated by restarting those opcodes and thus clearing the
> problematic values from their feedback lines.
>
>
>
>
> On Thu, Mar 14, 2013 at 9:53 AM, peiman khosravi 
> wrote:
>>
>> This is the first tim eI hear this. Can you send an example of a csd with
>> only sine oscillators to demonstrate this?
>>
>> P
>>
>>
>> On 14 March 2013 16:49, Martin Huenniger  wrote:
>>>
>>> Hi
>>>
>>> I don't think it's the number of samples/buffers etc. it's clearly
>>> related to amplitudes. It happens also if you do additive synthesis with a
>>> number of sines and at some point the addition of amplitudes causes an
>>> overflow which kills the audio-engine. It happens on different devices (mac,
>>> iphone) and is also present in different software (SuperCollider for
>>> example). I think this is a common problem, immanent to the digital nature
>>> of the sound synthesis. The usual way to avoid this is to lower the
>>> amplitude of each instrument/sine/sample/buffer playing. But to use a fixed
>>> value to decrease the amplitude won't solve the problem if it is unknown how
>>> many sound generators you mix together.
>>>
>>> I just had an idea how to do stuff if an instrument start/stops: Maybe
>>> one could use the scoreline opcode in the following way
>>>
>>> instr 1
>>>         kstartstop = p4
>>>         kinstance = p5
>>>         ktrig = 1
>>>         if kstartstop == 1 then
>>>                 String sprintfk {{ i 2.%d -1 }}, kinstance
>>>                 scoreline String, ktrig
>>>
>>>                 ; do start-related stuff
>>>         else
>>>                 String sprintfk {{ i -2.%d -1 }}, kinstance
>>>                 scoreline String, ktrig
>>>
>>>                 ; do stop-related stuff
>>>         endif
>>>         ktrig = 0
>>> endin
>>>
>>> inst 2
>>>         do instrument-magic
>>> endin
>>>
>>> In the score do
>>>
>>> i 1 0 0 1 1 ; start instance 1 of instr 2
>>> i 1 2 0 1 2 ; start instance 2 of instr 2
>>> i 1 4 0 0 2 ; stop instance 2 of instr 2
>>> i 1 8 0 0 1 ; stop instance 1 of instr 2
>>>
>>> Best,
>>> Martin
>>>
>>>
>>> Am 14.03.2013 um 17:22 schrieb peiman khosravi:
>>>
>>> > Oh so I guess it's a filter explosion. Still, it's not a clipping
>>> > issue. It's the same with filter plug-ins in my experience, right?
>>> >
>>> > P
>>> >
>>> > On 14 March 2013 15:56, Justin Smith  wrote:
>>> > peiman: I can recreate the problem with little more than a single
>>> > foscil going into a mode filter, it is not caused by excess sampling (which
>>> > would only cause a temporary breakup of audio until the instrument count
>>> > drops, not a permanent loss of audio as described).
>>> >
>>> >
>>> > On Thu, Mar 14, 2013 at 8:53 AM, peiman khosravi
>>> >  wrote:
>>> >
>>> >
>>> > On 14 March 2013 13:57, Martin Huenniger 
>>> > wrote:
>>> > Hi,
>>> >
>>> > thanks for your replies, but that is not the problem. The background is
>>> > that I have this csound patch which plays a number of samples and at some
>>> > point, when enough samples are started and some audio-overflow (or clipping)
>>> > occurs, the audio-output will stop and i have to restart the whole program.
>>> >
>>> > This is not caused by clipping, it's probably caused by having too many
>>> > samples open, which is the same as having too many tracks playing in
>>> > protools, which leads to a buffer overload. It has nothing to do with
>>> > amplitude levels. The only way to avoid it is by  having some sort of
>>> > 'polyphonic' management that doesn't allow more than a certain number of
>>> > instruments to play. It will probably also help if you're reading the sample
>>> > from a buffer (table).
>>> >
>>> > P
>>> >
>>> > That's what I would consider a crash. Yes, I do not know the maximum
>>> > amplitude since the samples interact, but I want to keep sure to have enough
>>> > headroom, so that it won't matter. But the existence of the overflow
>>> > behavior is not the question. I know this from other software as well and it
>>> > seems completely reasonable to me and is discussed extensively elsewhere.
>>> >
>>> > I don't think a limiter would help here, since if you have sounds which
>>> > do not clip or overflow but do overflow if played together then a limiter
>>> > might provide no help here, since the overflow would occur before the
>>> > limiter is able to detect the signal. But again, this is not the fact I want
>>> > to discuss.
>>> >
>>> > My question is just how to implement this semaphore concept, which
>>> > might be interesting not only in the context of avoiding this overflow
>>> > issue, but also in other circumstances, although the first use is right now
>>> > more important to me.
>>> >
>>> > Any suggestions concerning this topic?
>>> >
>>> > Best,
>>> > Martin
>>> >
>>> >
>>> > Am 14.03.2013 um 14:25 schrieb peiman khosravi:
>>> >
>>> > >
>>> > >
>>> > > On 14 March 2013 13:23, Justin Smith  wrote:
>>> > > Will csound actually crash from excessive amplitudes?
>>> > >
>>> > > Of course not.
>>> > >
>>> > > In my experience I can just use a global amplitude factor and adjust
>>> > > that as needed, I have never seen an amplitude based crash.
>>> > >
>>> > > The "active" opcode will tell you how many instances of an instrument
>>> > > are running.
>>> > >
>>> > >
>>> > > On Thu, Mar 14, 2013 at 6:12 AM, Martin Huenniger
>>> > >  wrote:
>>> > > Hi list,
>>> > >
>>> > > I had the following idea to address the crashing of csound from audio
>>> > > overflow: Anytime an instrument is started, a global variable (a semaphore)
>>> > > should be incremented and if an instrument stops this variable will be
>>> > > decremented again. The value of this variable is then used to lower the
>>> > > output of all instruments playing, thereby (hopefully) preventing audio
>>> > > overflows. My problem is how to achieve this. Has this semaphore to be a
>>> > > control rate variable? or init-time? And how do I achieve the behavior that
>>> > > the semaphore gets incremented only once when the instrument is initialized
>>> > > and decremented once the instrument is stopped? Your advice is much
>>> > > appreciated.
>>> > >
>>> > > Best,
>>> > > Martin
>>> >
>>> > _________________________
>>> > Martin Hünniger
>>> > a_s_tarantoga@yahoo.de
>>> > a-s-tarantoga.tumblr.com
>>> > soundcloud.com/a_s_tarantoga
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> > "unsubscribe csound"
>>> >
>>> >
>>> >
>>> >
>>>
>>> _________________________
>>> Martin Hünniger
>>> a_s_tarantoga@yahoo.de
>>> a-s-tarantoga.tumblr.com
>>> soundcloud.com/a_s_tarantoga
>>>
>>>
>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>