directgumby

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.

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."  

udp-sendrecieve-to-non-max-objects

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

https://cycling74.com/forums/using-raw-binary-data-in-a-patch

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.

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.

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.

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.

I am actually working on a project needing to receive raw UDP data.

I want to receive data from motion capture:

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:

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?

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

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.

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?

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

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:

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:

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 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? 

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?

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?

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.

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.


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.

I have some questions about you code, cause I don't get all UDP messages.

I just created a simple test, with an object:

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?

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]

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?


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...

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.

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


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.

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 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!

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:

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 www.sadam.hu at that time.

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

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

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


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:

post( "index: "+i+"tsigned: "+bbuf[i]+"tunsigned: "+ (0xFF&(int)bbuf[i]));

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?

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?

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

>> 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.


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?

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?


It appears you're on Windows, but just in case you're not there is an object called aka.datagram (

 that lets you create a datagram and send it with udpsend, and similarly decode a datagram to Max from udpreceive.

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.


>> 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?

/Applications/Max5/java-doc/api/index.html

>> 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


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

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


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:

https://cycling74.com/forums/announce-the-sadam-library-version-2010-12-07

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.

UDP Send/recieve to non MAX objects