UDP problem!

Replies to This Discussion

Permalink Reply by Luis Fraguada on April 10, 2012 at 5:04pm

What have you changed from the example?  Since you are just connecting to yourself, you should not need to worry about internet connectivity...

Permalink Reply by Evert Amador on April 11, 2012 at 3:15am

Hi Luis, Thanks for your promp reply.

I see what you mean about the ip, I've just had a look at the documentation for the send() method and I understand that a null ip will send the package to the local host.

I haven't changed anything on the GH definition and I've got the string ready and formatted (is 2d so I don't need to change anything in GH) as required in processing, the udp bits I've incorporated from the Flocking-howl example are these:

 

import hypermedia.net.*;

UDP udps;

void setup() {

 udps = new UDP( this, 6400 );

 

and in my interact() method :

 

 locList = loclist + all the other bits

String message  = locList;// the message to send    

String ip       = "127.0.0.1"; // the remote IP address    

 int port        = 6400;  // the destination port    

 udps.send( message, ip, port );    // send the message  

print(locList);// just to check the formatting is right!

 locList = "";//clear the locList String

 

pls let me know if you need to look at the processing sketch and I can email that to you, if you don't mind having a look at it.

Many thanks

Evert

 

 

Permalink Reply by Luis Fraguada on April 11, 2012 at 3:42am

Hello Evert,

It would help to get the processing sketch to see if I can detect anything.

Best,

Luis

Permalink Reply by Evert Amador on April 11, 2012 at 4:04am

Hello,

Here it is!

Cheers

Evert

Permalink Reply by Evert Amador on April 11, 2012 at 4:07am

Whoops!

Attachments:

• sketch_apr10a.zip, 1 KB

Permalink Reply by Luis Fraguada on April 11, 2012 at 12:18pm

Evert,

Yes, the issue is definitely in the processing code.  I tried a few ways, including changing to a different library (oscP5 which uses netP5), but I get the same issue.  One question, why are you not implementing the boid behavior in a draw loop?  I ma really not sure what the issue is.  All of the other examples with both libraries runs just fine over here!

Permalink Reply by Evert Amador on April 11, 2012 at 2:06pm

Hi Luis,

Thanks for looking at this, It is definitely the udps = new UDP( this, 6400 ); which is causing the error, I've tried breaking the sketch into separate tabs and even create another class to handle the interact method and still doesn't work.

I can make all the examples work just like you, so there is probably something to do with Igeo taking over PIApplet and PIGraphicsGL. Probably Igeo takes over the ip when it first starts and does not releases control while the sketch is running.

The reason that I don't have a draw loop is because Igeo handles the draw loop via a dinamic server that starts with defining IG.GL in the set up.

I'll dig in the Igeo source code to see if I can find the problem when I'm back in a couple of days.

Thanks again and I'll post any findings for future refenrence.

Cheers

Evert

Permalink Reply by Luis Fraguada on April 11, 2012 at 11:43pm

Yes, I also was thinking that the Igeo was doing something suspicious.  Maybe you want to submit an issue report to their Github Source?

Permalink Reply by Evert Amador on April 14, 2012 at 6:43pm

Hi Luis,

I found the problem! For some reason still unkown, the UDP needs to be initialised with the owner only. So it sort of works as sometimes processing hangs out, mmm, I don't know why, it even happens closing and disposing of the UDP.

A sort of working example attached. I'll keep looking and let you know!

Cheers

Evert

Attachments:

• IgeoParticleAttractorExample.zip, 2 KB

Permalink Reply by Evert Amador on April 14, 2012 at 6:54pm

!

Attachments:

• Igeo_GH_Test.jpg, 439 KB