Comment

Comment by Martin Siegrist on October 11, 2016 at 7:28am

AJ, you need to group the button with another grasshopper component/s

Comment by AJ on October 10, 2016 at 2:16am

hi Andrew, how do you use the enable / disable button (like in the gif) ? thnx

Comment by Xavier AM on September 15, 2016 at 4:22am

Damn, MetaHopper is absolutely AWESOME! I wish I had known it from the time I started writing complex definitions, it would have saved days of work.

I am just figuring out component by component what are their purposes,  I feel like a child on Christmas day :-) A special big up for the "Label Groups" and the "Bottleneck analyzer".

Thanks Andrew for this really good job!

Comment by Vongsawat Wongkijjalerd on August 9, 2016 at 10:59pm

Huh, weird things when you try to circumvent core grasshopper design I guess..

Throttling by Data Dam with boolean trigger is exactly what I'm trying for. (huh, setObjVal as opposed to expireObj threw me for a loop there) Thanks for the suggestion though!

Would you know why, when I connect a Data Recorder to this, the first time triggering will always double-trigger?.. subsequent triggers act as expected, if I clear the Recorder, the first value triggers twice again. Whether the behaviour's coming from the Dam or the Recorder ..

Comment by Andrew Heumann on August 9, 2016 at 7:00am

I should also mention that the Data Dam has an in-built "timer" of its own, that allows you to "throttle" your data as I think you're attempting to do.

Comment by Andrew Heumann on August 9, 2016 at 6:57am

Well Vongsawat, this one had me really puzzled. Every time I opened YOUR definition, it didn't work, and every time I reconstructed your definition, it worked without fail. Here is what I think is happening:

Grasshopper can only be computing one "Solution" at a time. In every solution, it only calculates "Expired" components - so that it avoids recalculating stuff which hasn't changed. The timer handles "expiring" the counter and scheduling a new solution - and so does the "Expire objects" component. Within a given solution, normal GH logic dictates that "upstream" components calculate first, and then passes that data long to other components further downstream. Now, since your metahopper rig does not involve conventional "wired" connections, there is nothing to tell grasshopper that the chunk of components with the counter needs to solve prior to the "param data" component retrieving the contents of the param downstream. Here is the really strange bit: In the absence of wired chains of dependency, Grasshopper decides which components should solve first BASED ON THEIR DRAW ORDER on the canvas. This means that, if you take your group of components with the counter and "Send to back" - everything works as expected. If you "Bring to front" you will consistently get an empty list from the param.

I think the reason your lower set occasionally returns proper values is that you click the "expire" at just the right time to insert a complete solution IN BETWEEN the solutions triggered by the counter/timer combo. With the upper configuration + faster timer, this is next to impossible.

So - all this is to say - by messing with the draw order, you may be able to cause this rig to work predictably - make sure you "bring to front" on all the metahopper components and "send to back" on the stuff you are listening to, in order to force it to compute first during any given solution. If this does not work, some sort of custom script may be necessary... but this strikes me as highly difficult.

I'd also like to suggest an alternative approach: you may find that using the data dam set to "Never" in a situation like this is preferable. It will circumvent solution logic such that even as the upstream components expire, the data is only passed through (and the downstream components expired) when you hit the "play" button. If you need to control this with a boolean value instead of the ui element itself, you can use metahopper "Set object value" on a data dam to cause it to recompute programmatically.

Thanks for a truly interesting puzzle - hope one of these solutions will get you where you need to be!

Best,
Andrew

Comment by Vongsawat Wongkijjalerd on August 8, 2016 at 9:47pm

two versions: The top one runs at 20ms, apparently too fast at least for my pc. The bottom one runs haphazardly as every 4th or so result is a null-result, sometimes more.

dataTrigger.gh

Comment by Andrew Heumann on August 8, 2016 at 7:36am

Vongsawat - I tried to rebuild your pictured definition but I am not able to reproduce the problem. Can you upload a file? 

Comment by Vongsawat Wongkijjalerd on August 8, 2016 at 5:50am

I have a bunch of data inputs that update at different rates, but I only want the main portion of my code to trigger when I say so (at random intervals)
I had thought using these components would solve this handily as SelObj would only grab the data whenever Expire turned true, but I can't have it output (and so trigger the entire code) with weird null-results, if that makes sense?
D'you think that's possible with MetaHopper? I've tried dipping my toes in to VB scripting but I've no background in VB at all so quickly got scared off.

Comment by Andrew Heumann on August 8, 2016 at 5:25am

Hi Vongsawat - can you explain what you're trying to do here? How and when are you refreshing the get param data component? If it executes while the other components are still solving it makes complete sense that it would not retrieve any value.

• ‹ Previous
• 1
• 2
• 3
• 4
• 5
• 6
• …
• 10
• Next ›
• Page