generative modeling for Rhino
This is a simple example of a mechanism something like a callback to monitor user input... Sometimes, I would like to disable slow/time-consuming portions of my definition while tweaking parameters. I know this can be done manually. This small def shows one way of doing it somewhat automatically... at least for a graphmapper. I would love to see how others handle something like this.
Just my 2ct:
I personally hate "intelligent" programs. Most likely the intelligent behavior is disabling the exact component you want to observe.
I prefer building the definition with light geometry to the very last moment. You'll have more fun adjusting parameters and probably will end up with an overall lighter definition.
Ok, after taking the time to watch your video, I see you actually did what I'd have done. Except I'd complete the definition with the booleand stuff only after I was satisfied with the distribution.
Your trick works on what I'd call a bug, because the graph mapper causes the canvas to recompute while there actually was no change in its value. This is why you get the last value twice.
I could imagine some kind of timed lock. A component that delays execution for a given amount of time after it was invalidated.
Here's some ideas that might be interesting:
I have to say I love your solution, very clever. But I can see how it's annoying if you have to add something like this to every definition you make.
I like this discussion! I've put in physical breaks (wires intended to be connected later) to allow input parameters to be tweaked quickly and set before allowing all the downstream stuff to happen.
I think 2) might be the simplest idea to start with, each data-dam having a boolean toggle.
I like the 1) idea of locking wires but in combination with enable/disable and/or lock/unlock with components things might start to get confusing with too many state options.
For 3) I think a group type bounding box (mentioned in 1) would be more flexible. With wireless wires it's also fairly common for users to spread little clusters all around the canvas and not necessarily in a linear flow.
The profiler is pretty handy to visually identify computationally intensive components. I like having a bit more control to deal with memory hogs rather than turning them all off. But that may be just me!
I guess I'm speaking for all of us, when I say:
...and I love "DataDam" for the component... ;)
agreed, great name, maybe a beaver has an icon :D
Aww, I actually called it Data Buffer in the code, which -to my mind- is more self-documenting. No alliterations though, so it is no longer possible to explain what this object does by saying:
David designed the Data-Dam doodad delaying the data deluge to disallow downstream doohickeys diddle-daddling the direct designer/diagram discourse.