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 Gavin on April 12, 2012 at 12:44pm

HI David, sorry to trouble you but I cant seem to identify the third component in your video (AB, AB),

Cheers,

Gavin

Permalink Reply by David Rutten on April 12, 2012 at 12:55pm

Hi Gavin,

it's the one I just wrote in response to this discussion. It won't be publicly available until the next build is released. It also doesn't (didn't) have an icon yet, which is why the default icon is shown.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Gavin on April 12, 2012 at 1:11pm

early bird gets the dam. Are you really going to call it the beaver buffer?

Permalink Reply by Mateusz Zwierzycki on April 12, 2012 at 3:34pm

Could it be a document option ? (compute real time or not)

Permalink Reply by Brian Harms on April 12, 2012 at 12:29pm

Would it be possible to create the equivalent of layer states? It would remember which components are previewed, unpreviewed, enabled, and disabled. If new objects are added to the canvas they would be excluded from the state manager, and if ones are deleted they just stay deleted.

Not sure if this is possible, but would be cool.

Permalink Reply by Andrew Heumann on April 10, 2012 at 4:43pm

Jonah - this is really clever. Would be awesome to find a way to adapt it to work with any input object, rather than just the graph mapper. I tried myself but didn't get anywhere.

David - I especially like #2 and #4. #1 doesn't seem to do a whole lot that simply disabling an upstream component wouldn't, and #3 would be a pain for sloppy users like me who aren't so careful about the left-to-right thing.

I like Hannes's suggestion of a timed lock, which only passes the data fed into it when it's not changing (within some specified time interval). This would allow precisely the kind of functionality Jonah's solution enables, but without the complexity or dependence on the graph mapper.

Permalink Reply by David Rutten on April 11, 2012 at 12:54am

In fact a time lock mechanism could also be added to a DataDam. It could operate in 3 modes:

Always pump data from left to right.
Never pump data from left to right unless the user clicks on a special button on the object.
Pump data from left to right after no new data has come in for X seconds, or when the user clicks on a special button on the object.

Where [2] is simply [3] with an infinite timeout. It's probably not too hard to write this, I should be able to add such an object in an hour or so.

I thought that my original solution #3 would be interesting for teaching purposes, where the instructor might want to show step by step how a file works. But I'm too busy to start working on this for the next release.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jonah Hawk on April 12, 2012 at 1:42am

Thanks for the compliments.

I like all of the ideas here but especially the last #3. It functions somewhat like a callback;

on parameter change do( )

or more appropriately,

on parameter change don't( )

Using a timer to compare values was my next thought. But I would think it would have to update fast in order for it to catch a change before the solution down stream begins to solve?