Stack Overflow w/ non-infinite loops

    Dec 10 2010 | 9:49 pm
    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?

    • Dec 10 2010 | 10:06 pm
      Apologies if this patcher's not posted properly... this is the first one I've posted.
    • Dec 10 2010 | 11:20 pm
      hi, theres a help files in the distro titled "avoid_stack_overflow_with_set" maybe this could help?
    • Dec 10 2010 | 11:32 pm
      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?
    • Dec 10 2010 | 11:45 pm
      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.
    • Dec 11 2010 | 12:46 am
      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
    • Dec 11 2010 | 12:51 am
      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
    • Dec 11 2010 | 1:07 am
      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 .
      p.s. oh and like terry said, [print] is of course using the most CPU here.
    • Dec 11 2010 | 2:14 am
      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
    • Dec 11 2010 | 5:11 am
      very interesting stuff, figuring out where the overflows happen and why...
    • Dec 13 2010 | 3:01 pm
      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.
    • Dec 13 2010 | 4:12 pm
      That helps quite a bit. Thank you very much.
    • Dec 14 2010 | 7:49 am
      (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.