Re: Threading Question
Re: Threading Question
- Subject: Re: Threading Question
- From: Gregory Wieber <email@hidden>
- Date: Mon, 30 Jan 2012 14:37:25 -0800
Perhaps instead of having attack and decay as functions, maybe you could do your ADSR using a switch/case statement that uses an integer to indicate which portion of the envelope you're in, and a sampleCount that is incremented and causes the envelope to go into the next boundary when the right number of samples have elapsed.
Eg, (I wrote this hastily, meant to be taken as pseudo code)
int ADSRIndex = 0; // attacking
...
nextBoundary = SAMPLE_RATE * attackInSeconds;
...
switch (ADSRIndex)
{
case:
{
if (++sampleCount > nextBoundary)
{
ADSRIndex+= 1; // now its decaying
}
else amplitude+= amplitudeIncrement;
}
... etc
}
On Mon, Jan 30, 2012 at 1:30 PM, ben kamen
<email@hidden> wrote:
Hello,
I have an iOS synth app and I am running into a problem that I think needs to be resolved through thread management or through some sort of locking system.
I have an envelope generator, a c++ object, to which I call "attack()" "decay()" from an audio controller object. The envelope objects calls "decay()" and "sustain()" to itself within the render loop at appropriate times.
I've noticed that the "attack()" and "release()" functions get called on different threads than the "sustain()" and "decay()" functions, which sometimes (though not terribly often) results in the messages occuring out of order, and causes notes to get stuck on.
After some research my thinking is that I need a way to ensure that the audio controller only can call "attack()" or "release()" between render callbacks, or even better, in between processing each frame. Is there a design pattern or preferred method that can help me ensure that that will happen? A code example would be incredibly helpful.
I realize this could also be a DSP question, but I'm pretty sure that is not my issue here. I'm interested in knowing what the proper way to avoid this kind of situation is.
Thanks in advance!
Ben
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden