Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I attached a patch that should reconstruct a long if it's bigendian, although it doesn't give 1000000 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Martin , thank you for everything, I got it working now even with floating point numbers, here is the rundown of the method
[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
- 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 :P
- 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 http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/
Good luck ^^
//Petar
On 13/3/13 1:51 PM, Martin Peach wrote:
I attached a patch that should reconstruct a long if it's bigendian, although it doesn't give 1000000 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote:
Apparently [netclient] on the Pure Data side cannot receive nothing else than ; delimited messages. So the solution for the problem: *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 received 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 and get them in separate variables?
*//Petar*
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I remember having big trouble of communication between gnuradio and pd a few months ago with udp. If you can compile here is a (very crappy sorry) external to conversion. It was done in a hurry but was working well for bytes to float.
I remember float2bytes was not good directly, you have to do:
[f] | [* -1] | [bytes/float2bytes] | [unpack f f f f] | | | | | | | [+ 128] | | | | | | | [% 256] [pack f f f f]
before to send over udp.
hope that helps n
Le 14/03/13 18:41, Petar Jercic a écrit :
Martin , thank you for everything, I got it working now even with floating point numbers, here is the rundown of the method
[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
- 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 :P
- 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 http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/
Good luck ^^
//Petar
On 13/3/13 1:51 PM, Martin Peach wrote:
I attached a patch that should reconstruct a long if it's bigendian, although it doesn't give 1000000 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote: > Apparently [netclient] on the Pure Data side cannot receive nothing > else > than ; delimited messages. > So the solution for the problem: > *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 received 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 and get > them in > separate variables? > > *//Petar* > * > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, I added two externals into svn at http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeac... [b2f] will take four bytes and return a float, while [f2b] takes a float and outputs four bytes. (This is really easy in c...) Of course it only works if the floating-point format is the same at both ends.
Martin
On 2013-03-14 13:41, Petar Jercic wrote:
Martin , thank you for everything, I got it working now even with floating point numbers, here is the rundown of the method
[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
- 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 :P
- 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 http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/
Good luck ^^
//Petar
On 13/3/13 1:51 PM, Martin Peach wrote:
I attached a patch that should reconstruct a long if it's bigendian, although it doesn't give 1000000 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote:
It's probably safer to get the server to send the numbers as ASCII text, to avoid disagreements about endianness and floating-point representation. Then, to extract the numbers, you could use [moocow/bytes2any] or make a custom parser using [pdlua].
Martin
On 2013-03-09 10:55, Petar Jercic wrote: > Apparently [netclient] on the Pure Data side cannot receive nothing > else > than ; delimited messages. > So the solution for the problem: > *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 received 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 and get them in > separate variables? > > *//Petar* > * > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cool,
Should be nice to have them manage list as well, it's better to do that in C when you want to transmit long list of float. Having choice of endianness may be good as well. You can copy both from the externals I've sent yesterday if you want.
best, n
Le 14/03/13 21:04, Martin Peach a écrit :
OK, I added two externals into svn at http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeac...
[b2f] will take four bytes and return a float, while [f2b] takes a float and outputs four bytes. (This is really easy in c...) Of course it only works if the floating-point format is the same at both ends.
Martin
On 2013-03-14 13:41, Petar Jercic wrote:
Martin , thank you for everything, I got it working now even with floating point numbers, here is the rundown of the method
[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
- 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 :P
- 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 http://stackoverflow.com/questions/15393113/convert-floating-point-number-from-binary-to-a-decimal-number/
Good luck ^^
//Petar
On 13/3/13 1:51 PM, Martin Peach wrote:
I attached a patch that should reconstruct a long if it's bigendian, although it doesn't give 1000000 for the sequence you provided...
The floating point numbers are more difficult, you need to separate the sign, exponent and mantissa and then put it all together.
Martin
On 2013-03-13 06:08, Petar Jercic wrote:
Wow, these methods you proposed made me realize 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 :)*
**Now my question is, how do I get four compact numbers to work with?* Now I have a series of bytes, but 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?
//Petar
On 11/3/13 2:31 PM, Martin Peach wrote:
On 2013-03-10 17:58, Petar Jercic wrote:
Sorry, I can't use ASCII text as communication method, since I plan to send large quantities of data at high speed rates, I need to optimize it as much as possible. Compared to streaming bytes, ASCII is inefficient up to a several orders of magnitude.
Is there a method for correct endianness in Pure Data, like these C functions:
ntohs()--"Network to Host Short" ntohl()--"Network to Host Long"
You can do that with Pd like this (ntohs):
[unpack 0 0] | | [* 256] | | | [+ ] | [ \
or
[unpack 0 0] | | | [* 256] | | [+ ] | [ \
for littleendian.
Floats are harder but still possible. The main difficulty is in splitting the incoming stream in the right places. (I think ASCII is not orders of magnitude slower, and it is also less ambiguous).
Martin
On 09/3/13 5:15 PM, Martin Peach wrote: > It's probably safer to get the server to send the numbers as ASCII > text, to avoid disagreements about endianness and floating-point > representation. > Then, to extract the numbers, you could use [moocow/bytes2any] or > make > a custom parser using [pdlua]. > > Martin > > > On 2013-03-09 10:55, Petar Jercic wrote: >> Apparently [netclient] on the Pure Data side cannot receive >> nothing >> else >> than ; delimited messages. >> So the solution for the problem: >> *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 received 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 and get >> them in >> separate variables? >> >> *//Petar* >> * >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 03/15/2013 13:02, Nicolas Montgermont wrote:
cool,
Should be nice to have them manage list as well, it's better to do that in C when you want to transmit long list of float. Having choice of endianness may be good as well. You can copy both from the externals I've sent yesterday if you want.
for what it is worth, i've been working on a set of RTP-objects in the last few days. currently these only handle conversion between lists of float (multichannel deinterleaved) and singed 16 bit integer (multichannel interleaved) but adding other converters is on my TODO list (though formats that meet RTP-profiles are more important)
fgmadrs IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-14 21:04, Martin Peach wrote:
OK, I added two externals into svn at http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeac...
[b2f] will take four bytes and return a float, while [f2b] takes a float and outputs four bytes. (This is really easy in c...) Of course it only works if the floating-point format is the same at both ends.
here's a simple vanilla implementation of [bytes2float]. it's certainly one of the more inefficient things you can do with Pd...
fgmasdr IOhannes
Martin Peach <martin.peach <at> sympatico.ca> writes:
OK, I added two externals into svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeac...
[b2f] will take four bytes and return a float, while [f2b] takes a float and outputs four bytes. (This is really easy in c...) Of course it only works if the floating-point format is the same at both ends.
Martin
Hi all, I'm using OSx 10.8.5 on a macbook pro and pd-extended 0.42.5. I tried to compile Martin's b2f.c from the terminal using these commands:
cc -DPD -O2 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I ./ -o b2f.o -c b2f.c
cc -bundle -undefined suppress -flat_namespace -o b2f.pd_darwin b2f.o
And then copied the *.pd_darwin file to ~/Library/Pd/b2f. Unfortunately, the resulting b2f.pd_darwin is not imported correctly by puredata. I get the following error when trying to create the b2f object:
/Library/Pd/b2f/b2f.pd_darwin: dlopen(/Library/Pd/b2f/b2f.pd_darwin, 10): no suitable image found. Did find: /Library/Pd/b2f/b2f.pd_darwin: mach-o, but wrong architecture b2f ... couldn't create
I used lipo -info b2f.o to check the architecture of the output file, but the answer looks OK:
Non-fat file: b2f.o is architecture: x86_64
Any suggestions? Has anybody tried to compile b2f.c or f2b.c in OSx?
Thank you -Damiano
Hello again, problem solved by adding
-arch i386
to both command lines.
Thank you, anyway Damiano
On Dec 19, 2013, at 6:22 PM, Damiano damiano.zanotto@gmail.com wrote:
Martin Peach <martin.peach <at> sympatico.ca> writes:
OK, I added two externals into svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeac...
[b2f] will take four bytes and return a float, while [f2b] takes a float and outputs four bytes. (This is really easy in c...) Of course it only works if the floating-point format is the same at both ends.
Martin
Hi all, I'm using OSx 10.8.5 on a macbook pro and pd-extended 0.42.5. I tried to compile Martin's b2f.c from the terminal using these commands:
cc -DPD -O2 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I ./ -o b2f.o -c b2f.c
cc -bundle -undefined suppress -flat_namespace -o b2f.pd_darwin b2f.o
And then copied the *.pd_darwin file to ~/Library/Pd/b2f. Unfortunately, the resulting b2f.pd_darwin is not imported correctly by puredata. I get the following error when trying to create the b2f object:
/Library/Pd/b2f/b2f.pd_darwin: dlopen(/Library/Pd/b2f/b2f.pd_darwin, 10): no suitable image found. Did find: /Library/Pd/b2f/b2f.pd_darwin: mach-o, but wrong architecture b2f ... couldn't create
I used lipo -info b2f.o to check the architecture of the output file, but the answer looks OK:
Non-fat file: b2f.o is architecture: x86_64
Any suggestions? Has anybody tried to compile b2f.c or f2b.c in OSx?
Thank you -Damiano
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Damiano -
Damiano Zanotto
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
Nicolas Montgermont -
Petar Jercic