i just read these essays: http://worrydream.com/#!/LearnableProgramming http://worrydream.com/#!2/LadderOfAbstraction

they made clear to me some concepts i think i'd find useful in solving a lot of my problems. (in patching, haha) a lot of the good stuff talked about max already does which is probably why i like it. :)

i'm wondering about the sections on "following the flow" and "seeing the state". particularly making time tangible and visible and showing comparisons. i basically just plug away at it, but having a method could help. :)

i mean, a lot of time my "mistakes" in the context of max patches are awesome...i get stuck more in figuring out why my mistakes are good, so that i can re-use those ideas, not so much how to actually do something that i think i want to do.

it seems like the way that max handles debugging, while it gets part of the way there, i can't really step through the process in a way that makes things more clear to me and it doesn't scale to give a broader overview of the data that i'm aware of. is there a way to get the data from the debugger window into max to process?

i'm wondering about methods to make "debugging" more interactive too, something you do while you're patching and interacting, even if it means building it on a patch level myself - as long as i can reuse it. :) maybe some good general strategies of using max to envision information patch wide where i can arbitrarily determine the scope and scale of data presented to me?

i mean i've used jitter to visualize data/convert audio, etc for the end "results" of a patch but not for the purpose of helping me be more clear in my thinking of putting the patch together - a higher level, abstracted, way of going about it.

also, it's entirely possible i'm attempting to use break and watch points in the wrong way! :) or they're intended to be used differently than i'm imagining. it's not super clear to me why to choose 1 over the other. or again even where to place them if i don't know in what way i'm making the mistake to begin with. that's where the concept of scrubbing backwards and seeing a visual in time seems like it'd be useful because i don't know how something has gone wrong until it's happened - or it wouldn't have gone wrong. :)

if anything i find the break + watch points kinda overwhelming like they're giving me too much feedback because i don't know what i'm supposed to do with the information they're giving me.

so maybe if someone has some examples of ways they use the debugging tools to find and fix problems? like, how do you use the information they give you to determine in what way something is (not) working, if that makes sense? or to say it another way: with the feedback they give you how does that inform where you begin looking for the problem?

thanks. :)