I think historically console games basically had to keep everything important inside a “safe area”, much like macOS/iOS software has to do now on devices with a notch en.wikipedia.org/wiki/Safe_ar...

100% helpful 0% obnoxious. actually would you mind if I keep bugging you with occasional max questions going forward?

really glad I made this thread now haha, all of your responses have been very helpful

oh right! ok awesome

also the interpolation functionality of the preset object looks extremely cool and useful, I feel like I will use this a lot

ah okay cool! so just hooking up a preset object to my flonums will more or less do what I want (with one extra step to save/load the preset)

but both of those require manually copying the value from one node to another at some point, which I find frustrating because I want to be able to open a patch, tweak a value with click-and-drag, then save and close it without extra steps

there are some workarounds, like putting a message node after the flonum node so that its value does get saved when you close the patch, or putting a loadmess node before the flonum node so that its value gets initialized to something when you open the patch

ah yeah, tbh that's probably a better way to think of it. like fundamentally it's just messages with sample-and-hold on top for convenience, rather than being a network with continuously updated values that sometimes fails to update properly

frustration #2: number/flonum nodes are good for interactive tweaking, since you can edit them (with the keyboard or with click-and-drag) while the patch is locked, but their values don't get saved when you close the patch. message nodes do get saved but aren't as nice for interactive tweaking

if I were designing a system like this I would probably have a firm divide from the start between values on the one hand, which are always kept up to date, and events/triggers on the other hand, which happen at a specific time. like CV vs gates/triggers in eurorack

yeah definitely, I'm already starting to get used to some of this stuff and it's not getting in my way as much while I'm trying to do things. but I figured I would try to capture my frustrations while they're fresh

and if I wanted that specific behavior with e.g. a * node, I can use a setup like this to have complete control over when triggers happen, right

oh yeah I mean, I definitely see the value of having separate control over preparing vs. triggering values! I guess it's just that "first input vs. other inputs" seems like a strange place to draw that line, and I feel like it's going to be a repeated source of bugs for me

frustration #1: nodes like * only recalculate their output values when their first input changes. if you want them to recalculate when their other inputs change, the workaround is to add a trigger node between the other inputs and the first input. not sure why I would ever not want this

honestly I think it's at exactly the right level of abstraction for how I want to work, but so far I've been running up against a lot of bizarre and frustrating design decisions

they happened over time, in a particular order, so I would have to say that that is accurate

this evening I’m starting At the Mouth of the River of Bees