interactive data visualizations for debugging + understanding patches?
i just read these essays:
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?
I don ‘t use the debugging tools. (maybe I should though?)
For monitoring and debugging data flow I use: print to max window, number and message boxes, jit.pwindow’s. You don’t wanna let them linger around though. Disconnect when not needed or performance will suffer.
i like "Probing" a lot
jit.fpsgui and its different modes is useful to me too
- This reply was modified 1 month by dtr.
so i just messed with the playgrounds in apple’s swift. lol
see from about 1:20 here https://www.youtube.com/watch?v=vogFSIxprUo
think i’ll just play at cross translating certain ideas between the two if i’m really stuck for the time being. won’t hurt to think about things a 2nd or 3rd! way.
- This reply was modified 1 month by jonah.