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 <fffr...@googlemail.com> 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 <nzuel...@gmail.com> 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 <dominos...@gmail.com> 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
