UDP Send/recieve to non MAX objects

Aug 8, 2010 at 5:54pm

UDP Send/recieve to non MAX objects

Hello,

I am working on a project where I would like to be ablle to send UDP messages to and from a non MAX object. What I have tried so far indicates that this is not exactly possible.

What I have is a simple C# app using the udpClinet to send to a port where the udprecieve is listening. What I get in return on the send from the C# app to the udprecieve is “Session activly closed by host.”

When trying tests the other direction I was not able to get a udpsend to show up on the C# side either.

I am wondering if I’m missing something obvious here.

Thanks,
Brett

#50752
Aug 9, 2010 at 1:58am

Hi Brett,

I had a similar problem to yours a while ago (although not exactly the same problem):

http://cycling74.com/forums/topic.php?id=26385

After reading about the suggested FullPacket message and actually after making some tests with udpsend and an (external) udp receiver command-line tool I just had the impression that udpsend is sending (and respectively, udpreceive is expecting) data in an OSC-formatted way. Therefore (at least as far as I noticed) you should send your data in OSC format. This might cause the trouble when you send from C# to Max.

The other direction (Max->C#), I can’t really understand. Are you sure there’s no other object or software listening on the same UDP port that the one you try to use for the Max->C# communication? Just because if there would be another udp listener thread bound to the same port (like an udpreceive in Max), it might happen that it would receive your udp messages instead of the C# listener.

Actually I developed a couple of objects (still unpublished as I still didn’t find my time to write a proper help file and documentation) that make possible raw binary communication via TCP and UDP between Max and the ‘rest of the world’. Let me know if you’re interested.

Cheers,
Ádám

#182100
Aug 9, 2010 at 3:18pm

Hello,

Thank you for the pointer.

After doing a bit more digging around i figured out that:
1) I missunderstood how to setup UDPSend. It turns out that I made a function “udpsend localhost 11100″ but just doing a bang on that device did not work. Once I hooked up and sent in a message “port 11100″ I saw the debug show that it bound to that port.

2) Yup, i found out that I have to look at the OSC format but I think for what i’m doing right now I’ll be OK without using the OSC format (Max->C#).

I’ll see how far I get with my current path over the next day or two. If I need the code after that I’ll let you know.

In one repect I’m surprised I can turn off the OSC format and just send raw UDP data.

Thanks for the help,
Brett

#182101
Sep 6, 2010 at 8:42am

Hello Siska,

I am actually working on a project needing to receive raw UDP data.
I want to receive data from motion capture:

http://www.xsens.com/en/general/mvn

These data are not OSC format.

When I use the udpreceive object using the OSC-full-packet-designation (I put “foo” as symbol), I get messages like this in the MAX window:
Fullpacket 664 75947888
But I don’t know if I can get the full message, and how…

If I remove the symbol, I get the messages:
OSC expected type string. Dropping message for address MXTP03.

So I think the objects you developped to read/write binary data would be very usefull for me!

Could you share them? I would be very grateful, because I am new to max, and have very few time to do this.
Perhaps I will could help for the documentation?

Thanks,
Sophie

#182102
Sep 6, 2010 at 9:09am

Hi Sophie,

You should check out [mxj net.udp.send] and [mxj net.udp.recv]. You’ll find some other java networking objects from there.

best,
Zachary

#182103
Sep 6, 2010 at 9:47am

Hi Zachary,

Thanks a lot for your quick response. I tried [mxj net.udp.recv].
It seems to work: I receive the UDP messages from moven. The [print] gives me:
MXTP03

But I don’t know how to get the full message? I guess I must develop a new mxj class?

I was watching at the recv class, and I see that it uses Atom objects:

private void receiver(Atom[] a) {
outlet(0, a);
}

So my idea is to create a new java class and try to override this method to parse the Atom[] received.
Do you confirm this is the good way to do it?

Thanks,
sophie

#182104
Sep 6, 2010 at 10:37am

I too would love to be able to receive the full, raw UDP packet rather than having to format in OSC. Are we saying this is possible?

@Siska Adam, do your objects allow this?

Thanks

#182105
Sep 6, 2010 at 11:33am

if you want to build an mxj class for sending/receiving raw udp packets, this might be helpful:

http://www.esbasel.ch/Downloads/UdpSend+RecvRaw.zip

it served me as a starting point for talking to various micro controllers.
volker.

#182106
Sep 6, 2010 at 4:15pm

Thanks a lot Volker, I think this is effectively a very good starting point for me too!
Scatalogic, I think this will help you too.

Volker,
I have some questions about you code, cause I don’t get all UDP messages.
I just created a simple test, with an object:
[mxj UdpRecvRaw @port 7777]
and I put the output in a [print]

I try to get data from moven, which is streaming on port 7777 with a frequency of 60Hz.

Some times I get some data, but not every time… for example, now if I retry I have nothing. Should I initiate the UdpRecvRaw (with a bang, or something)? How do you use it in max exactly?

#182107
Sep 6, 2010 at 5:27pm

did you have a look at the help file, does that work for you?
this is really just a very stripped down version for demonstration, and not very useful like it is in real life.
the outlet of the UdpRecvRaw simply sends a bang, when a packet is received.
also, the received byte array is not handed over to max, but simply printed to the max window.
if you want to pass the packets to max, you’ll have to extend the java class a little.
for my purposes, i found it easier to deal with the data in java.

if you send a stop message to the object, the socket is closed, and you can’t open it again… not very elegant, but this was also for the sake of simplicity.

and yes, 60 Hz sounds like a pretty dense stream…

#182108
Sep 6, 2010 at 8:50pm

Thanks, that looks useful. Will give it a go tomorrow and then dive into Java I guess! I haven’t used it before, but it looks like you’ve done the hard bit already and I need to get started on it sooner or later.

#182109
Sep 6, 2010 at 9:45pm

Thanks Volker,
I was expecting to have to extend a little your class. I was just afraid of not having my full UDP message.
Actually, it was just a problem of size (too big to be printed in the max window).
I have began to parse it and deal with the data in java, and for the moment it works!

Thanks again for your classes, it helped me a lot!

I will upload here my code when I it will be complete. It will be specific for XSens moven format, but it could interest someone, and Scatalogic, it could give you some ideas…

Thanks again!
Sophie

#182110
Sep 7, 2010 at 10:02am

Dear Everybody,

sorry, I was out of city for a few days. For those who are interested in my objects, here’s a temporal link including the TCP and UDP sender and receiver objects (built for the Mac and Windows) with two simple example patches:

http://www.sadam.hu/maxobjects.zip

Please note that I’m still finishing the development of these objects, which means that currently you can only send individual integers (interpreted as unsigned bytes) and lists of integers (also interpreted as unsigned bytes). There will be a new set of objects with a few extra possibilities and proper documentation probably at the end of this month. Please check back on http://www.sadam.hu at that time.

#182111
Sep 8, 2010 at 8:03am

Brilliant, thanks Adam that has saved me a load of guff!

#182112
Sep 10, 2010 at 1:15am

has anyone succeeded in get UDP datapacks out of Volker’s java class and into the Max environment? having trouble with that.

#182113
Sep 10, 2010 at 2:37pm

I’m working with Billy on his project. Neither of us have much experience with MXJs. I edited the for() loop where it prints data to the Max window to this:

[code]
for(int i=0; i

post( "index: "+i+"tsigned: "+bbuf[i]+"tunsigned: "+ (0xFF&(int)bbuf[i]));
outlet(i,Atom.newAtom(bbuf[i]));
}
[/code]

If you hook up a print object, it prints the correct values to the Max window, but they are not recognized by number or message boxes. In fact, Max seems to be interpreting them as bangs. Converting the bytes to ints first does not seem to help. Any idea what I’m doing wrong here?

Thanks,
Zach

#182114
Sep 10, 2010 at 6:04pm

>> for(int i=0; i

is this a typo? i+2 is not good. you should properly increment i, if you want to get all bytes out.

something like:

for(int i=0; i

outlet(0, (0xFF&(int)bbuf[i]));

works for me.

#182115
Sep 11, 2010 at 7:42pm

I actually changed i+2 as it threw an error. The reason I was incrementing by two was an adhoc solution to the way the data was formatted on the send side (incorrect conversion from ints to chars leaving the every other byte empty).

So, you’re saying you don’t need to use the Atom class to get this data into Max?

#182116
Sep 11, 2010 at 10:48pm

It appears you’re on Windows, but just in case you’re not there is an object called aka.datagram (http://www.iamas.ac.jp/~aka/max/) that lets you create a datagram and send it with udpsend, and similarly decode a datagram to Max from udpreceive.

#182117
Sep 12, 2010 at 5:28pm

>> I actually changed i+2 as it threw an error.
you’d need something like i+=2 to increment by two.

>> So, you’re saying you don’t need to use the Atom class to get this data into Max?
yes.
take a look at the api
/Applications/Max5/java-doc/api/index.html

#182118
Sep 12, 2010 at 6:01pm

Got it- I had some trouble finding the api reference. Thanks!

#182119
Dec 8, 2010 at 3:14am

Hi Developers,

sorry for cross-posting. Although I promised a release of the final version of the streaming externals for the end of September, I only had the time now to polish the thing and publish it:

http://cycling74.com/forums/topic.php?id=29997

Since there were some bugs in the objects that I posted in this thread a couple of months ago, I kindly ask all those who might have had downloaded and used them to delete the old, buggy version and replace it with the new one I just posted.

Thanks,
Ádám

#182120

You must be logged in to reply to this topic.