problem with stack overflow for list generation
I'm trying to generate a list of numbers consisting of between 4 and 8 numbers with a value between 1 and 4 for each. The total value when the numbers within the list are added together should not exceed 16. If this occurs I want a new generation to occur. My patch works for a bit before causing a stack overflow. I would appreciate if someone could point out to me where I am going wrong with constructing my patch. I know how to find out where the overflow is occurring using the max window. but I have not been able to fix the problem.
Many thanks
A
That's rather a large patch to want people to debug for you, so you might be waiting for a while [and you'll owe them several pints for being willing to do that much work for free :-) ].
While you're waiting, perhaps you might want to consider looking into some of the debugging tools that come with Max 5. I haven't done much debugging of late, so....
Oh - Choose Help > Max Help and then type "debugging" into the search box. That brings up a vignette that links to everything else.
Good news - looks like the tutorials that were rewritten for Max 5 even include stuff on debugging. Take a look at Max tutorial 5 (Message Order and Debugging). That's a basic intro on how to step through a patch.
Hmmm. I'd kind of forgotten how cool the watchpoint stuff is. Watching the flow of data AND knowing what current values are makes things a lot easier in hairy patches.
Ok, cheers I appreciate that, its a valid point.
Alternatively if someone knows of, and could suggest an easier, alternative method of generating the list, as I feel my patch might be a long winded way to obtained the desired results.
In the meantime I'll throw my hat at the debugger
thanks
A
This works, though it sometimes will spit out several lists, and the additional ones don't always have between 4 and 8 members. I'm not sure why, something with the timing is screwy---not allowing enough time for initialization perhaps. But you can get lists that fit your description.
The whole recursion thing can be tricky in Max, many people use javascript for these kinds of procedures. I can see it being particularly helpful to ensure correct order of operations when timing is tight.
If anyone sees where my bug is I'd like to understand it... maybe a [defer] in just the right place will solve things.
Try this patch, be warned though that if the list sums to more than 16 it will try the entire process again and could theoretically (although it's not particularly likely) retrigger itself continuously until your computer goes crazy. It is also not particularly random, you're more likely to have shorter lists as these are less likely to sum to a lower value. Hope it helps.
lh