if parameter change then disable slow components temporarily

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.

http://www.jonahhawk.com/2012/04/grasshopper-parameter-change-test-...

Replies to This Discussion

Permalink Reply by Hannes Löschke on April 10, 2012 at 5:33am

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.

Permalink Reply by Hannes Löschke on April 10, 2012 at 9:05am

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.

Permalink Reply by David Rutten on April 10, 2012 at 10:43am

Here's some ideas that might be interesting:

Put locks on objects or wires. One click locks them (and everything downstream of them), another click unlocks them. Benefit is that it's quick to assign a state, drawback is that you have to remember to do it every time you start messing with the lightweight stuff. Locks could perhaps be limited to group objects only. It might also be interesting to control Preview On/Off via groups.
Provide a data-dam object which collects data on the left but doesn't allow data to flow through it. Only when clicked will it seed its outputs. It could of course also have a mode where it always seeds data, in which case it would be like inserting a Generic parameter into an existing wire.
Since most GH files are ordered left to right (sometimes they also have a strong top to bottom layout), I could add a draggable border. An infinite vertical line that can be dragged around at will, and everything to the right of this line is disabled. Benefit here is that it's easy to modify which objects are solved, drawback is that it's difficult to quickly solve all objects and then go back into locked state. You can think of this as a Clipping Plane sort of thing if you want.
Have a mode that doesn't solve components which took more than X seconds to solve previously, until you specifically exit the mode via a mouseclick or keypress.

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.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by taz on April 10, 2012 at 11:20am

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!

$0.02

Permalink Reply by David Rutten on April 12, 2012 at 6:06am

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Hannes Löschke on April 12, 2012 at 8:40am

I guess I'm speaking for all of us, when I say:

Your're awesome!

...and I love "DataDam" for the component... ;)

Permalink Reply by Michael Pryor on April 12, 2012 at 8:54am

agreed, great name, maybe a beaver has an icon :D

Permalink Reply by David Rutten on April 12, 2012 at 10:41am

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: