Automate the Data Dan

Replies to This Discussion

Permalink Reply by Hannes Löschke on February 6, 2013 at 3:05am

You can set a timer interval.

Everyting else would need some external program to interact with data dam.

A trigger from inside a GH definition makes no sense, since the single threaded graph logic of GH makes sure, every input to a component is calculated before the component is evaluated.

Permalink Reply by Doctor No on February 6, 2013 at 5:07am

Data Dan is a nice component for making recursion and cyclical data streams, and I agree it could be useful to have a certain limit of times for refreshing the data, or let some external conditions stop the process when they are reached... This can be done inserting a filter node (or a dispatch, gate , etc) after the first Geometry parameter, but it could be nice to have it inside the data dan compo

Attachments:

• cyclic data recursion.gh, 13 KB
• recursion.wmv, 385 KB

Permalink Reply by Hannes Löschke on February 6, 2013 at 12:01pm

For recursion, there's Hoopsnake. No need for DataDam here.

DataDam was conceived to separate Parts of comutationally heavy definitions so you could modify parameters without waiting for all the rest to update.

Permalink Reply by Doctor No on February 6, 2013 at 1:53pm

hoopsnake is cool, but is not native component. Data Dan can also be used for step by step definition explanations, controlling the time to be updated. So no need for hoopsnake there.

Permalink Reply by Hannes Löschke on February 6, 2013 at 2:14pm

That's what I said:

Recursion (what you show in your screenshot) -> Hoopsnake, not DataDam

Delayed Execution -> DataDam, not Hoopsnake

Permalink Reply by Doctor No on February 6, 2013 at 2:35pm

The more you can choose, the better the result. Pick whatever you like. I bet almost anything hoopsnake can do, data dan is able to achieve, you only need some creativity looking for different workarounds

Permalink Reply by Hannes Löschke on February 7, 2013 at 3:30am

While you certainly can trick DataDam into recursion, I wouldn't recommend it.

GH doesn't allow for cyclic data streams and has a logic to detect them. While a single DataDam may be connected in "Never" mode the cyclic stream will be detected once the data is sent through. You can defy this by using two DataDams with only one passing through at a time. Both passing through and GH will detect the cycle again.

There's some problems I see here:

a) The detection logic is limited. Since a single DataDam doesn't work in any case, it's obviously not meant to recurse data. The two dams trick looks like a bug or flaw so don't excepect it to work in any future version.

b) You can timer-trigger both dams so they will alternately pass through. The timer interval needs to be longer than your execution time, which is inefficient at least. Due to the execution time of the solution and timing inaccuracies in the message loop, there are cases when both dams pass at the same time... your iteration breaks.

c) Because you need two Dams to make this work, the data will be copied twice. This is double the ressources you would actually need and that Hoopsnake would use.

So, back to your argument about diversity of possible solutions: While you can certainly put a hammer to a screw, a screwdriver would be by far the better idea.

Permalink Reply by Doctor No on February 7, 2013 at 7:39pm

the obvious thing is that it is a trick! Notice we (you, and me, and the whole community) are only playing with some components to find out other solutions that can be hits for further software development 

a) of course the detection logic is limited in Data Dam, that´s why an event-change based logic detection could be more useful. So that we could avoid de-synchronization between that two datadams. Not only two, but also I imagine a number of datadams when required along the whole definition at the start and at the end of every component that it is in need of a loop...

b)a certain of event-change based logic could pass and retain data when needed, could avoid the problem of the time execution of the definition between data dams

c) I'd rather have two, four, eigth datadams than doublecliking(or rightclicking) all over the def two, three or four times

(Nevertheless I like Hoopsnake a lot!, but it isnt native...and thats always a problem when somebody dont have it installed)

So, back to your argument about playing with hammers and screws, we could remain neanderthal for ages without a little of experimental nonsenses

Permalink Reply by Brian Harms on February 6, 2013 at 4:03pm

I have similar issues with the other components that have on-component click requirements (data recorder, data dam, geometry pipeline).

While their interfaces are very nice, it makes it very difficult to use them parametrically. There are alternatives to these components in 3rd party plugins (data recorder => data logger in Firefly, geometry pipeline => horster reference) but if you are moving around computers a lot or distributing definitions to a lot of people, it can be a hassle to install 3 plugins to be able to use your definition.

I'd definitely be in favor of the classic GH "grip" inputs to drive these components rather than the on-component buttons.

Any thoughts?

-Brian

Permalink Reply by Michael Makris on February 7, 2013 at 2:02am

I agree. I was hopping for some sort of triggered logging and/or delay, rather than having to use a timer stuck at the same interval. IE it would be useful to delay update until a certain event happens rather than a certain time occurs.

Permalink Reply by Michael Makris on February 7, 2013 at 2:06am

Well it turns out I accomplished what I was looking for a totally different way. HOWEVER, thanks everyone for you input and advice.

To Hannes and NaN, I think some more clarification would have been useful on my part, sorry. I was looking for delay, not recursion. I've used Hoopsnake, but wouldn't have satisfied. But again, I've solved the issue, so no more worrying. I agree with NaN that it would be nice to have a native component like Hoopsnake to avoid plugin requirements. NaN, while I agree the delay can be useful, the fact that it only operates on a timer and not event-based is the drawback i was trying to figure out. If you could have it pass information based on an event, I would use it more.

Thanks guys!