Stopping GH_Timer from affecting components downstream?

I use the Timer component, which as I understand it, expires a component's solution, thus expiring all the components that it plugs into, and onwards.

I'm also using the data recorder component / this custom VB data recorder to store some data. What I want to do is to stop the effects that the timer has on the data recorder, so that everything 'downstream' from that data recorder only recalculates a solution when a value changes, like normal Grasshopper. Is this possible?

My specific use-case: I'm using a camera control plugin to grab the location and orientation of the camera. When I press a button, I store the location and orientation of the camera at that moment into a list with Data Recorder, and turn that into geometry, and boolean all the results on the list together. But since the list slowly grows, the boolean gets more and more heavy. This wouldn't be a problem, except that the camera control plugin that I wrote requires the GH Timer with a high refresh rate (~20ms), so then the Data Recorder continues to refresh every 20ms, and then the boolean union operation is retriggered every 20ms, even when I want it to only trigger when a new item is added to the Data Recorder List.

Thanks a lot!

Replies to This Discussion

Permalink Reply by Dan Taeyoung on September 26, 2014 at 12:00am

Here's a simplified version of my workflow. The final Solid Union takes 234ms to run but is running every 20ms, slowing everything down.

Permalink Reply by Vicente Soler on September 26, 2014 at 2:10pm

This seems to work. It subscribes a method to an event so that it will only update when a particular view is changed.

Edit: seems to also fire when the Grasshopper canvas is redrawn, weird.

Permalink Reply by Vicente Soler on September 26, 2014 at 3:00pm

I added the condition to only update when Grasshopper doesn't have focus, so it should work better now.

Attachments:

updateview.gh, 5 KB

Permalink Reply by Dan Taeyoung on September 27, 2014 at 1:50pm

Thank you for this! This is interesting, but unfortunately there's no rate-limiting on it, so it looks like it fires too often without a specific reupdate rate and 'clogs up' my script when the view is actively being updated: e.g, being rotated with the mouse.

I'm probably looking for a general c# component that triggers an update / expire solution only when the GUID / object properties of its input change from one state to another, and explicitly stops it from calculating everything downstream from it.

Permalink Reply by Vicente Soler on September 27, 2014 at 4:25pm

How about this? It will only update the component after you stop changing the view. To make sure you are really done changing the view it will trigger half a second after the last time you stopped moving the camera (the amount of time can be changed through an input).

Attachments:

updateview02.gh, 5 KB

Permalink Reply by Dan Taeyoung on September 28, 2014 at 2:58pm

Thanks Vicente - it works, but but it actually still doesn't solve the root problem, which is that a 'data recorder' component plugged in downstream of this component will continue to update when you change the view --- even if the data recorded in the component itself doesn't change. This means that orbiting / updating the view itself becomes a costly computational operation..

Permalink Reply by Vicente Soler on September 28, 2014 at 3:14pm

So the recorded data doesn't change when a view is changed?

In the screenshot you posted it looks like a pipe is created using the camera and target of a view. That pipe is connected to the data recorder, so if the view changes, the recorded data necessarily changes. What am I missing?

Just to make sure, you shouldn't need any Grasshopper timers in the definition if you use the script I posted.

Permalink Reply by Dan Taeyoung on September 28, 2014 at 3:30pm

Ah, what I'm concerned with is turning off the data recorder / selectively recording data and having the components downstream not continuously re-trigger.

Here are two examples, posted with two versions of a data recorder component. I've posted them while orbiting, while both data recorders were off, but notice the Solid Union that takes 500ms to fire, despite the fact that no new data is being passed through from the Data Recorder.

Permalink Reply by Vicente Soler on September 28, 2014 at 3:45pm

Ahhhh, so the problem is that the data recorder still expires all downstream components even when its switched off.

So how about disconnecting the wire to the data recorder rather than pushing the stop recording button? It's one mouse action more, but workable solution. Keep a parameter close to the input for fast rewiring.

Permalink Reply by Dan Taeyoung on September 28, 2014 at 4:12pm

Yes, but I think it's the refresh being triggered by the initial c# component that 'flows' all the way to the data recorder, whether or not it's off or on.

Unfortunately I'm trying to record data programmatically, so I can't manually connect/disconnect the wire in Grasshopper. Even using a Stream Data component to create a 'switch' and to send empty info over a wire seems to trigger the refresh. (see picture)

Even creating an empty c# component that doesn't do anything still triggers this expiration every time I orbit in the view:

So I suspect the expiration is happening with a rule along the lines of "expire all things that are connected downstream, no matter what their logic is". What I need is an anti-timer, or a component that can block the propagation of this expiration..