I am trying to build a 'geometry synthesizer' using reactivision, processing and GH. Reactivision sends a TUIO data stream, processing parses it and writes it to a txt file, and GH reads it. It is already working, but obviously not in real time. I would like to get rid of the txt part and be able to stream it live, but I'm an architecture student so my programming knowledge is very limited. Even though, i've had technical help and i've been told that using HID protocol to stream live data could be an option. is this possible?
On Apr 29, 8:18 am, Dimitrie <didimit...@gmail.com> wrote: > oh damien, tell me about it. it was a fun day though - killing rhinos > and everything. > > i didn't find a way to trigger things inside rhino from java. any > idea? probably would be quite complicated since java isn't .net... > > On Apr 28, 8: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
