i did this gh-max/jitter experiment a while ago. http://tinyurl.com/dk9cc5 gh streams into text file which max/jitter reads (using coll).
best, frank On Apr 30, 4:02 pm, nzuelzke <[email protected]> wrote: > I'll settle for non-live data to and from processing to start with... > For example, a definition creates a group of points that I want to > pass into processing to manipulate. Then I want to bring the modified > points back into grasshopper for further work. If I change the > original ghx points I'm happy to repeat the process, for the time > being. > Any ideas? > Cheers, > Nathaniel. > > On Apr 28, 7:25 pm, damien_alomar <[email protected]> wrote: > > > > > > I did once this very clumsy thing - script with Rhinoscript a macro > > > that moves a point over and over and over again, while that point is > > > referenced in grasshopper. this is a very electro-shock kind of way to > > > convince grasshopper to update (i couldn't make the script stop > > > afterwards without killing the whole rhino process). It was cool > > > though to see some boids running around :) > > > You have to be very careful when you do this as there's the potential > > to get in to a cyclical reference and things will spiral until they > > crash. If you have some code that connects somewhere else and changes > > something, and some code within that other environment that on a > > change moves that point in grasshopper (thus firing the original code > > again), than one update will cause the scripts to update themselves > > continuously. You can set this up so it doesn't cause this reference, > > but you need to take extra steps to prevent this. Mainly, one code > > cannot be fired by event and trigger the event. If you have code that > > is set up to respond to events and fire code that could potentially > > cause events, then its best to find a way to suspend an event while > > making any changes. If after those changes, a condition is met and > > you still want to fire off the original code again, then that's > > another thing and you should do so in as controlled a manner as > > possible. > > > I agree that moving a point to fire off an event is rough, but when > > set up correctly, it will get the job done. Until David offers up > > something else.... > > > Best, > > Damien
