gHowl

Comment

Comment by Peter Liebsch on December 19, 2011 at 8:37pm

Hi Andy,

Did the setup as discribed but no data comes through. So I assume it's our firewall or network in general as I do that in our office. I will try it at home and see if that resolves this issue.

Thx

Peter

Comment by Andy Payne on December 19, 2011 at 8:03pm

Hi Peter,

Yes, the setup is basically the same as with the GHowl components.  You just need to specify the UDP port you're listening to. You'll also need to connect a GH_Timer component so that it expires the component quickly (trying to get the latest message sent from the TouchOSC app).  

On you're TouchOSC app, you'll need to specify the IP address of the computer you're trying to send it to.   GHowl has an excellent tool for pinging your IP address called Network Source.  Just enter the IP address of your computer into the app, and pick an outgoing Port number you want to send the message (note: you're Grasshopper component should also use this same port number).  

The only other thing I could think of that might possibly be causing you trouble is whether your network is blocking your UDP message.  Could you describe your network setup.  Are you trying this at home (on a personal router) or at school/work?  Sometimes, different networks block UDP messages (this often happens if I try to connect on an institutional network, like at school).  In this instance, it could be a good idea to try to create an ad hoc network on your computer.  Here are instructions on how to do this: http://windows.microsoft.com/en-US/windows7/Set-up-a-computer-to-co...  Once you've created an ad hoc network, make sure both your phone and computer are connected to this same network.  It may take a while to regenerate your IP address (on your computer), but once it does... enter this new number in your phone app.  The port number can stay the same.  Ideally, this should solve your problem.  Let me know if you still have problems.

-Andy

Comment by Peter Liebsch on December 19, 2011 at 5:14pm

@Luis

I'm using a OSC Dispatch. It collects the information but struggles as soon as the timer on the FireFly is on. Funny enough it only struggles with the toggle data, the slider data gets through fine.

@Andy

Thanks for your video link and explanation. I tried to hook up my OSC app via the FireFly OSC Listener but it reports no data... I assume the port is the same for gHowl UDP Reciver and FireFly OSC Listener, right? My setup looks the same as yours in the video... any idea?

Comment by Andy Payne on December 19, 2011 at 7:03am

It sounds like this problem might be because of a threading issue.  As Luis said, one of the great things about the OSC listener in GHowl is that it does not need timers.  It has (I think) it's own threading model which allows it to be very fast.  On the other hand, it's possible that there could be some inconsistencies in the data transfer if the threading isn't sync'd up with the Grasshopper UI threading model (especially if the data is being sent very quickly).  

One thought could be to try the OSC listener in Firefly.  It works similarly to the GHowl version with a couple exceptions... the first is that it requires the use of the GH_Timer to automatically update.  I've found that you can still get pretty good speed using the GH_Timer (I've been able to get up to around 60 fps) but the fact that you're using the GH_Timer means that the solution will always be recomputed in sync with the UI threading.  And since you're already using the GH_Timer for the Firefly component, you should be able to use this same timer to recompute both components.  I've been able to use TouchOSC and the Arduino components without having these issues, so I definitely think it's possible.  Here's one example: http://vimeo.com/26073521.  Anyway, I hope this helps.

Comment by Luis Fraguada on December 19, 2011 at 2:17am

gHowl is designed to not need / use timers.  Each time a timer fires, the solution is recomputed and this can significantly slow things down depending on what you are doing. 

How are you storing the toggle values?  Which OSC components are you using?  If you store the toggle in the OSC channel component, what happens, do you still loose the information?  Does the component return a null value or does it go to 0? 

Comment by Peter Liebsch on December 18, 2011 at 9:20pm

 

Hi Luis,

Great tool. Thanks for making it accessible!

I just have a question. I run a GH file where I get data from OSC iPad app in via gHowl as well as sensor data from an Arduino via FireFly.

The OSC are just simple horizontal sliders.

The problem I'm facing is that additional toggle items in OSC, which write only 0 or 1, don't get through properly. They do without problems as long as the timer on the FireFly is off. I also can write to the OSC app via gHowl to turn LEDs on or off.

As soon the FireFly timer is back on the toggle get lost in 8 of 10 attempts. The sliders still get through correct.

Any idea if this is because of a timing problem between gHowl and FireFly? I played around with different GH timer settings but that didn’t change much.

Cheers,

Peter

Comment by Luis Fraguada on November 22, 2011 at 12:02pm

Hello Jeremy,

I have not tried with such a large file.  I would need to have a file like that in order to debug and come up with a better way to parse the data.

Best,

Luis

Comment by Jeremy Bamberger on November 19, 2011 at 2:08pm

Hi Luis et al,

 

I am working with Ben Golder's Python script to read in shapefiles from GIS. I have the entire land use map (by parcel, ~150,000 polygons) of San Francisco and coordinated with the SF Assessor/Recorder's office to getting 10 years worth of property valuations (excel docs, again ~150,000 rows of data).

 

I've been trying to get gHowl to read in this large excel file. I've been dividing the data in half until GH stops freezing and landed at around 5,000 rows of data. Can gHowl do better?

 

I can probably script a method to parse the existing excel files then merge them back in GH, but that would be less than ideal (10 years x 40 separate files = 400 excel docs!).

 

Any ideas? Is there a more efficient manner to perhaps grab a csv file?

 

Thanks!

 

Jeremy Bamberger

jbamberger@cca.edu

Comment by Luis Fraguada on November 10, 2011 at 5:27pm

Hello Igor,

Not clear on what the issue is.  What is it you are expecting to get?

best,

Luis

Comment by Igor Mitric on November 7, 2011 at 6:59pm

Hi Luis,

Thanks for everything! I really do not want to be annoying.

I followed your instructions:

 I divide PictureFrame as Surface into number of points. I pluged this points into XZY – GEO Node, also one reference point to in order to get elevations data. Then I decomposed points and made them again with new Z lengths. Build a IntCrv and loft it. Works fine.

Now, I culled the lowest point in a list (with sort list) . Put a XY Plane trough, duplicate it with Series and specific number 2.0 and intersect this planes with lofted surface, in order to get isohypsen. Works also fine.  

I am just not sure, that with this way , intersection,  I get really thing!?

City is Graz (AU)

Thanks a lot one more time !

IgorGhowl%20to%20Google%20Earth.gh

GrazInnenstadt.3dm

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• …
• 13
• Next ›
• Page