sending data back to gh is still quite a hassle. it's possible, but it won't be read in realtime - just as soon as you modify some referenced geometry in rhino or pull on a slider that directly affects the definition file.
as soon as david sees this post and will hopefully take mercy and implement some sort of autoupdating in a scripting component it's going to be just about writing interpreters for whatever our processing sketch generates. On Apr 30, 9:57 pm, enrique <[email protected]> wrote: > I tried as well a VVVV patch wich reads GH streaming pretty well > but i wonder which is the best to send back data to GH... > > On 30 abr, 19:27, gll <[email protected]> wrote: > > > Maybe something like VBScript > JAVA > VBScript? > > Similar to JNI (Java Native Interface)? > > > Does it exist? > > > On Apr 30, 5:05 pm, frankS <[email protected]> wrote: > > > > concering real-time data streaming i was asking david about OSC. > > > see thread:http://tinyurl.com/d4em99 > > > > Dimitrie: i have no clue were to start off with using the OSC > > > implementation, because i don't know any vb.script. > > > did i get you right that you managed reading OSC data from within GH? > > > would you mind sharing how it is done. > > > > frank > > > > On Apr 30, 4:58 pm, frankS <[email protected]> wrote: > > > > > 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
