Hi everyone,

I am interested in TCP/IP communication from the Unix server to the Pure Data. I have it realized using sockets on the Unix server side, and netclient on the Pure Data side. I exploited the chat-server tutorial for this.

Now the problem lies that the server is streaming the data out as a "string" message delimited with ";"

My question is, is there a way to send something other than string message to Pure Data, like byte-stream or serialized number stream? Can Pure Data receive such messages?

Since string takes too many bytes to transfer, for example number "1024;" is already 5 bytes, while any integer number is just 4 bytes.

/b/umping for greater good

UPDATE: For everyone that stumbles upon this post in search for the answer.

Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages.
So the solution for the problem posed above:
My question is, is there a way to send something other than string message to Pure Data, like byte-stream or serialized number stream? Can Pure Data receive such messages?

The solution is to use [tcpclient], it can receive byte-stream data.

Now I have another problem regarding the data read, on how to convert it back to usable numbers.

From my UNIX server I am sending a structure

typedef struct {
int var_code;
int sample_time;
int hr;
float hs;
} phy_data;

Sample data might be 2 1000000 51 2000.56

When recieved and printed in Pure Data I get output like this:

>>>: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69

You can notice number 2 and number 51 clearly, I guess the others are correct as well. Might be some network inversion of LSB/MSB.

How can I get these numbers back to a usable format?

Sending to the list might help as Martin Peach is signed up there, so you might address your question straight to him..

Thank you for the suggestion, I did as you proposed.
I will post the answer here once resolved.

Hi,

i had the same problem connecting Blender to PD. I'm using the [udpreceive] object.

In PD extended theres an object [moocow/bytes2any]. It converts from bytes(bytestring) to a PD list. After that you can use the [route] object as usual.

greets, kq

Can you explain how did you do the conversion using [moocow/bytes2any] and [route], or post a sample patch.
I am stuck heavily on this.

Hey,

i hope this helps. My message from Blender consists of a bytestring (address, stuff you want to send, 0). The 0 is used to delimit the message which is spit out by the bytes2any object. After that you can route the list by the address you gave it. See the attachment.

kq

http://www.pdpatchrepo.info/hurleur/UdpTest.pd

Apparently, I was right about the inverted data in network communications.
Is there a method for correct endianness in Pure Data, like these C functions:

ntohs()--"Network to Host Short"
ntohl()--"Network to Host Long"

UPDATE:
Thanks for the code kompaqt.core, I'll test it immediately.

Hey happilylazy,

i never heard of those functions, and obviously got lucky to get it working without any proper networking knowledge. If it helps, my python code uses (socket.AF_INET,socket.SOCK_DGRAM) which should be the standard udp socket. I read about AF_INET in the ntohl() function descripition. So if my python message is reversed then the bytes2any object is able to get it in the right order.

kq

Thank you for your input and your code [kompaqt.core], looking at (socket.AF_INET,socket.SOCK_DGRAM) I realized that I was using the wrong endian method on my UNIX server, it has to be ntohl().
Now I got it correct, and I am receiving data (bytes) in the correct order.

>>>: 0 0 0 2 0 10 114 26 0 0 0 51 0 16 242 78

Sample data might be 2 1000000 51 2000.56, which could be read in the data ... somewhat

xxx---------------------------------xxx
which is exactly the opposite of the wrong initial condition
>>>: 2 0 0 0 104 34 9 0 51 0 0 0 235 50 48 69
xxx-----------------------------------------------xxx

Now my question is, how do I get four compact numbers to work with?
Now I have a series of bytes, at least in the correct order.

I haven't been able to extract the data using [bytes2any] and [route], so I prepared a small patch to demonstrate the problem, maybe you can show me by modifying it?

http://www.pdpatchrepo.info/hurleur/server_comm.pd

Hi again,

i tried your patch but didn't get out the real values. It seems the [bytes2any] produces some weird ascii stuff.

You might want to check out the pdstring-help.pd in pd/extra/moocow and http://puredata.hurleur.com/sujet-2533-ascii-float .

Maybe you just need to delimit every value you are sending with " " (space?) or a 0 byte. My message in Blender looks like: <bytesfrom int/float/string>+" "+<anotherbyte>+" "+etc.

Otherwise i have no idea what could be wrong. But it seems your close to the real deal.

Hope you can figure it out, kq

[solved]
BUT BEFORE FOLLOWING THIS, NOTE THAT FLOATING POINT NUMBER IS SOMETHING THAT YOU DON'T WANT TO PARSE, IF YOU LIKE YOUR NERVES.

The first problem is
1. Error was in using on the server side an ntohl() on a float number, which corrupts it heavily. Mark my words, ntohl() is an enemy of the float.
Just receive it reversed and manually work out the conversion, you HAVE to do it manually anyways

2. Float is a complex standard, even more complex when Pure Data converts everything to decimal partially per byte. Separate Mantissa, Exponent and Sign using bitwise operators [<<][>>], and work out the float conversion.
Follow this thread for Mantissa, that one is the hardest Convert floating point number from binary to a decimal number

Good luck ^^