Damned Data Dam

If I send a brief new value to a data dam with a tempo, (like with a button from a Human-UI interface), the data is ignored when the button press is faster than the tempo :

This makes the Data Dam useless for my purpose which is “let stuff happen before refreshing the data in my definition”.

Assigned to Grasshopper category so it will be seen.

1 Like

Sorry, I forgot…

In other words : the data dam doesn’t fully act as a buffer, but more as a damper.
If changing values are input, it will just output whatever is at the door when the timer has expired.

This is kind of lame, or at least, there should be a toogle to make it act as a true buffer.

Not lame at all since buffering would cause all sorts of new problems. Perhaps the name “dam” suggests buffering? So Data Shield would convey its purpose better? You can implement a buffer using Data Recorder eh?

for this problem I can recommend metahoppers expire:

If that still is not working try strg+f to compute selected components first

one_shot_expire.gh (6.3 KB)

edit: maybe this would also force a strict sequence:

1 Like

Here is an python component which will fire once if the input is changed:
one_shot_expire_v2.gh (8.1 KB)

1 Like

EDIT : I tried out your idea of chaining the Data recorder and the Data dam, first with a record limit of 1 :


This does not work because in effect, the recorder does nothing.

Then I tried without a record limit :


This doesn’t work because, at each cycle of the Data dam, ALL the history of “True” and “False” is passed through.

Finally, I added a “List Item” component to pass only the very last boolean :


This does nothing else than what the Data dam alone would do…
“True” is only passed if the boolean button is pressed longer than 1 second (the delay I set on my dam).

And you are right , the name “Dam” is misleading.
In a real dam, floating debris accumulates behind the dam ; it doesn’t just disappear for no reason.

Hey, thanks Konrad, I need to try this out !

This custom script should update/work/dothething every time an input is changed/updated (expired).

It is a sort of “like data dam but with parametric update button”.
Also, as it send data to an un-connected Data parameter this let recursive programming (like, indeed, data dam).

Data is volatile *, so “not internalized” in the parameter. If you disable/enable the parameter or reload the file it lose the data.
But should be fine during grasshopper execution.

“ID” (Guid parameter) is needed to store the guid of the target Data parameter through Save/Open file.

Connect and use it as seen in the gif:
DDD V1
DDD V1.gh (6.8 KB)

It can work with button instead of boolean toggle…

Hope it helps :slight_smile:

* because of performance reasons, but also because I wasn’t able to set persistent data for that situation… XD

1 Like

Well… this is what the Metahopper “Expire” component would do on a Data dam, right ?
It doesn’t really solve the problem of delaying the transfer of a changing boolean without skipping any.

I have no idea. I’ve never used metahopper.

But i think that working with a button should have some different effect.

Hi Konrad, I fooled around with your C# and Python scripts :


I got a whole flurry of behaviors, but none was able to get rid of “Boolean stuttering” (True-True , False-False,…).
When I press a boolean Toggle, I’d like to filter the output to get ONE “True” and ONE “False”, nothing else, nothing more.

Also, this doesn’t solve the issue with the Data dam tempo.