I've got a strong procedural-programming background and am having a bit of trouble with the new paradigm (from what I understand, this is pretty common). The program I'm building takes 100 samples of an audio file, does some processing, rinses and repeats until it's gon through an entire audio file.

I'm having difficulty with the outer loop for this... specifically I'm getting stack overflows. I suspect this is because MAX resolves things in a depth-first manor, and my loop just goes too deep. I use sfinfo~ to get the length of the file, then increment a value object by 12.5 (100 samples in 8khz is 12.5 ms). Then I'm using an if to test whether or not I've read to the end of the file.... and it'll overflow every time. I've debugged and the counter is definitely incrementing properly.

Am I trying to use square pegs in a round hole?

I've got a strong procedural-programming background and am having a bit of trouble with the new paradigm (from what I understand, this is pretty common).  The program I'm building takes 100 samples of an audio file, does some processing, rinses and repeats until it's gon through an entire audio file.

I'm having difficulty with the outer loop for this... specifically I'm getting stack overflows.  I suspect this is because MAX resolves things in a depth-first manor, and my loop just goes too deep.  I use sfinfo~ to get the length of the file, then increment a value object by 12.5 (100 samples in 8khz is 12.5 ms).  Then I'm using an if to test whether or not I've read to the end of the file.... and it'll overflow every time.  I've debugged and the counter is definitely incrementing properly.

Am I trying to use square pegs in a round hole?


stack-overflow-w-non-infinite-loops

Apologies if this patcher's not posted properly... this is the first one I've posted.

hi,
theres a help files in the distro titled
"avoid_stack_overflow_with_set"
maybe this could help?


do you get stack overflows with the posted example?

with a short .wav loaded I get the expected:

print: 0.000000
print: 12.500000
print: 25.000000
print: 37.500000
print: 50.000000
print: 62.500000
print: 75.000000
print: 87.500000
print: 100.000000
print: 112.500000
print: Done!

do you get stack overflows with the posted example?  

Sorry, I forgot to mention the size of the file. It's about two minutes in length, so approximately 10,000 loops. I get the overflow after about 1000 loops.

Is there another way of programing long loops? Should I maybe be using an entirely different approach? I can't help but feel that my background has me approaching this problem from the wrong angle.

I can't seem to find that one. When I search for stack overflow set, I don't see anything. How did you get to that help file?

Sorry, I forgot to mention the size of the file.  It's about two minutes in length, so approximately 10,000 loops.  I get the overflow after about 1000 loops.

Is there another way of programing long loops?  Should I maybe be using an entirely different approach?  I can't help but feel that my background has me approaching this problem from the wrong angle.

I can't seem to find that one.  When I search for stack overflow set, I don't see anything.  How did you get to that help file?

: remove the print object and see if you get a stack overflow without it there.

: put a deferlow object somewhere in the loop-- that usually fixes things of this nature

: neaten up the patch for clarity-- for instance your subpatch mainLoop could use multiple value objects, and use trigger objects to ensure event ordering

I haven't checked this mod-- let me know if it alters anything

Try these things
: remove the print object and see if you get a stack overflow without it there.
: put a deferlow object somewhere in the loop-- that usually fixes things of this nature
: replace buttons with [t b]

Max is not particularly good at doing this kind of loops or recursive processes. Of course it is possible to do such things in java. In this case, a deferlow somewhere in the feedback loop might ease the pain. The total processing time goes up quite dramatically however.

a stack overflow can happen with non infinite loops when there is simply too

usually a [defer] right behind the [uzi] already solves it, but you might also try

to turn audio off, or lower the sheduler interval during such a process (if your

app does not need to sequence or play videoframes at the same time.)

the sheduler can be set by a message to max:

arguments are 1-20 milliseconds, 1 is default, and take care, this writes into the

preferences (at least it does in max v4), so you need to reset it to 1 when you

p.s. oh and like terry said, [print] is of course using the most CPU here.

a stack overflow can happen with non infinite loops when there is simply too
much data to process.

usually a [defer] right behind the [uzi] already solves it, but you might also try
to turn audio off, or lower the sheduler interval during such a process (if your
app does not need to sequence or play videoframes at the same time.)

arguments are 1-20 milliseconds, 1 is default, and take care, this writes into the
preferences (at least it does in max v4), so you need to reset it to 1 when you
close your app .

p.s. oh and like terry said, [print] is of course using the most CPU here.


I tested the patch with a 7 minute sound file-- doesn't overflow, but the print object slows it down by a factor of about 50-100; I made a slight mistake in the previous post (wouldn't print)-- this one will work

very interesting stuff, figuring out where the overflows happen and why...

First of all, thank you for the informative posts. This community is very impressive.

1. I was able to further improve on Terry's patch.

Terry, thanks for the patch. It does indeed seem to work without an overflow for audio files of any size. The deferlow seems to slow things down quite a bit though. I've added a conditional statement that only routes things through the deferlow every 1000 loops. This speeds things up greatly.

I've read the documentation on deferlow, and can make a few guesses as to what's going on, but I'm not sure I really get it. How exactly is this stopping the overflow? I *think* that the print messages were getting backed up in a queue, and the stack overflow would happen when that queue got too large. The deferlow set to trigger every 1000 steps seems to support that as I get a slight pause followed by 1000 print messages each time I route through there.

But what confuses me is the mention in deferlow's help is the mention of "high priority" and "low priority" messages. It gives a few examples, but is there any way to know exactly what will be considered "high priority" and what will be "low"? I thought everything was supposed to be resolved in a depth first manor, right to left. If this were the case, I would expect these print messages to be dealt with one at a time, rather than put into a queue.

First of all, thank you for the informative posts.  This community is very impressive.

1.  I was able to further improve on Terry's patch.

Terry, thanks for the patch.  It does indeed seem to work without an overflow for audio files of any size.  The deferlow seems to slow things down quite a bit though.  I've added a conditional statement that only routes things through the deferlow every 1000 loops.  This speeds things up greatly.

I've read the documentation on deferlow, and can make a few guesses as to what's going on, but I'm not sure I really get it.  How exactly is this stopping the overflow?  I *think* that the print messages were getting backed up in a queue, and the stack overflow would happen when that queue got too large.  The deferlow set to trigger every 1000 steps seems to support that as I get a slight pause followed by 1000 print messages each time I route through there.  

But what confuses me is the mention in deferlow's help is the mention of "high priority" and "low priority" messages.  It gives a few examples, but is there any way to know exactly what will be considered "high priority" and what will be "low"?  I thought everything was supposed to be resolved in a depth first manor, right to left.  If this were the case, I would expect these print messages to be dealt with one at a time, rather than put into a queue.


That helps quite a bit. Thank you very much.

That helps quite a bit.  Thank you very much.


(someone please correc me when i am wrong), low and high priority in

max is very limited and therefore very easy to track and/or create.

high priority is everything what comes from [metro] and [uzi], and it will

remain high priority until a [defer] is inserted somewhere.

with [deferlow] it is more complicated and i am not the right person to

i am also not sure about the priority level of midi input and its 2

modes, which one of them obviously raises priority by lowering the one

(someone please correc me when i am wrong), low and high priority in
max is very limited and therefore very easy to track and/or create.

high priority is everything what comes from [metro] and [uzi], and it will
remain high priority until a [defer] is inserted somewhere.

with [deferlow] it is more complicated and i am not the right person to
explain this.^^

i am also not sure about the priority level of midi input and its 2
modes, which one of them obviously raises priority by lowering the one
of other data.

Stack Overflow w/ non-infinite loops