Stack Overflow w/ non-infinite loops

Dec 10, 2010 at 9:49pm

Stack Overflow w/ non-infinite loops

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?

#53860
Dec 10, 2010 at 10:06pm

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

– Pasted Max Patch, click to expand. –
#193881
Dec 10, 2010 at 11:20pm

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

#193882
Dec 10, 2010 at 11:32pm

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!

did I miss something?

#193883
Dec 10, 2010 at 11:45pm

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.

Re: tdaeik

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?

Thanks for the replies.

#193884
Dec 11, 2010 at 12:46am

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]

: 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

– Pasted Max Patch, click to expand. –

T

#193885
Dec 11, 2010 at 12:51am

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.

_
johan

#193886
Dec 11, 2010 at 1:07am

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.)

the sheduler can be set by a message to max:

“;
max interval 5″

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 .

-110

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

#193887
Dec 11, 2010 at 2:14am

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

– Pasted Max Patch, click to expand. –
#193888
Dec 11, 2010 at 5:11am

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

#193889
Dec 13, 2010 at 3:01pm

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.

2. I don’t really understand deferlow.

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.

– Pasted Max Patch, click to expand. –
#193890
Dec 13, 2010 at 3:19pm

Hello Fen,

high/low priority thread tutorial :

http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

HTH.

#193891
Dec 13, 2010 at 4:12pm

That helps quite a bit. Thank you very much.

#193892
Dec 14, 2010 at 7:49am

(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.

everything else is low.

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.

-110

#193893

You must be logged in to reply to this topic.