hi We have a laser pointer that is being tracked and broadcasting on an ip two lists of XY data from a C# application Is there a way i can listen to it in pd by just listening to that socket? I tried netserver and netclient but it does not connect. Can pd listen to this socket without a netsend on that machine?
On 02/16/12 15:59, Pagano, Patrick wrote:
hi We have a laser pointer that is being tracked and broadcasting on an ip two lists of XY data from a C# application Is there a way i can listen to it in pd by just listening to that socket? I tried netserver and netclient but it does not connect. Can pd listen to this socket without a netsend on that machine?
[netsend]/server/client speak a protocol called FUDI, which you C# application is most likely not speaking.
you might want to use objects that don't make any assumptions on the application layer protocol, such as [tcpclient]/[tcpserver]/[udpclient]/[udpreceive] depending on the transport layer your application is using (tcp/ip or udp?)
fgmdasr IOhannes
Le 2012-02-16 à 16:38:00, IOhannes m zmölnig a écrit :
[netsend]/server/client speak a protocol called FUDI, which you C# application is most likely not speaking.
FUDI is fairly close to not having any protocol at all. It's quite close to just using things like printf("%f %s",myFloat,mySymbol). You just have to be able to send a semicolon terminator.
This is fairly easy to justify such a claim : /usr/bin/netsend and /usr/bin/netreceive are actually TCP client/server tools : they don't do any FUDI encoding or decoding on their own.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 02/16/12 16:46, Mathieu Bouchard wrote:
Le 2012-02-16 à 16:38:00, IOhannes m zmölnig a écrit :
[netsend]/server/client speak a protocol called FUDI, which you C# application is most likely not speaking.
FUDI is fairly close to not having any protocol at all. It's quite close to just using things like printf("%f %s",myFloat,mySymbol). You just have to be able to send a semicolon terminator.
sure.
unfortunately [netreceive] and friends will not output any data until the semicolon terminator is encountered, which i guessed might have been the problem of not receiving any data.
gmaser IOhannes
On 02/16/12 16:50, IOhannes m zmölnig wrote:
unfortunately [netreceive] and friends will not output any data until the semicolon terminator is encountered, which i guessed might have been the problem of not receiving any data.
which should read like: [...the problem of not] seeing any data inside Pd; [netreceive] will receive the data well and accumulate it in a growing(?) buffer....
mfgasdr IOhannes
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
pp
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of IOhannes m zmölnig [zmoelnig@iem.at] Sent: Thursday, February 16, 2012 10:38 AM To: pd-list@iem.at Subject: Re: [PD] socket object?
On 02/16/12 15:59, Pagano, Patrick wrote:
hi We have a laser pointer that is being tracked and broadcasting on an ip two lists of XY data from a C# application Is there a way i can listen to it in pd by just listening to that socket? I tried netserver and netclient but it does not connect. Can pd listen to this socket without a netsend on that machine?
[netsend]/server/client speak a protocol called FUDI, which you C# application is most likely not speaking.
you might want to use objects that don't make any assumptions on the application layer protocol, such as [tcpclient]/[tcpserver]/[udpclient]/[udpreceive] depending on the transport layer your application is using (tcp/ip or udp?)
fgmdasr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
[netreceive 7777] | [print]
though you will have to deal with semicolons separately....
as for splitting strings, have a look at zexy's [symbol2list]
fgmasdr IOhannes
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote:
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way).
Roman
i cannot find iemnet for OSX
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Roman Haefeli [reduzent@gmail.com] Sent: Thursday, February 16, 2012 11:41 AM To: pd-list@iem.at Subject: Re: [PD] socket object?
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote:
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way).
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/16/12 17:50, Pagano, Patrick wrote:
i cannot find iemnet for OSX
never mind, it won't help you here (in fact, it will make things a little bit more complicated, as with mrpeach/tcpclient you can at least hope that the chunks you get will make sense in a way, whereas the iemnet will guarantee that you need to take proper care of the stream)
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
what's wrong with [symbol2list]?
given that the protocol is rather simple, you might also simply try to parse it yourself (which would make it robust against packet fragmentation as well)
fgmadsr IOhannes
We have tried using the symbol2list object to parse the data, but where things seem to fall apart is when we try to give any arguments that contain a comma. Is there some sort of a literal break character (like "" in unix) that we can use in pure data to give the comma character as an argument?
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of IOhannes m zmölnig [zmoelnig@iem.at] Sent: Thursday, February 16, 2012 12:01 PM To: pd-list@iem.at Subject: Re: [PD] socket object?
On 02/16/12 17:50, Pagano, Patrick wrote:
i cannot find iemnet for OSX
never mind, it won't help you here (in fact, it will make things a little bit more complicated, as with mrpeach/tcpclient you can at least hope that the chunks you get will make sense in a way, whereas the iemnet will guarantee that you need to take proper care of the stream)
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
what's wrong with [symbol2list]?
given that the protocol is rather simple, you might also simply try to parse it yourself (which would make it robust against packet fragmentation as well)
fgmadsr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/16/12 18:12, Pagano, Patrick wrote:
We have tried using the symbol2list object to parse the data, but where things seem to fall apart is when we try to give any arguments that contain a comma. Is there some sort of a literal break character (like "" in unix) that we can use in pure data to give the comma character as an argument?
[44( | [makefilename %c]
fgmadr IOhannes
Le 2012-02-16 à 18:01:00, IOhannes m zmölnig a écrit :
given that the protocol is rather simple, you might also simply try to parse it yourself (which would make it robust against packet fragmentation as well)
What is packet fragmentation and why is it preferable to take it into account even when not necessary ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On 02/16/12 19:16, Mathieu Bouchard wrote:
What is packet fragmentation and why is it preferable to take it into account even when not necessary ?
tcp/ip is a stream-based protocol and has no notion of "packets" like udp (which is a packet-based protocol).
meaning: if you send "1 2 3 4 5" this may be received as
- one block "1 2 3 4 5" OR
- two blocks "1 2" and " 3 4 5" OR
- two blocks "1 " and "2 3 4 5" OR
- six blocks "1", " 2 ", "3", " ", "4" and " 5" OR
- somehow else
no assumption must be made on how the data is fragmented on the receiver side". otoh, tcp/ip guarantees that data is received in order, so if you send to messages "1 2 " and "3 4 5" one after another, the resulting stream is guaranteed to be "1 2 3 4 5", wheras with UDP you might get "3 4 5" and "1 2 ".
therefore, if you want to be parse your data correctly, you must not assume that you get "1 2 3 4 5" as one message out of [tcpfoo]. instead you should parse the stream for some terminating sequence ";" or CRLF or whatever and re-packetize the stream.
it might only _seem_ to be "not necessary" in a given situtation, simply because you were observing some messages that came out correctly.
mvasrd IOhannes
On 2012-02-16 13:26, IOhannes m zmölnig wrote:
On 02/16/12 19:16, Mathieu Bouchard wrote:
What is packet fragmentation and why is it preferable to take it into account even when not necessary ?
tcp/ip is a stream-based protocol and has no notion of "packets" like udp (which is a packet-based protocol).
meaning: if you send "1 2 3 4 5" this may be received as
- one block "1 2 3 4 5" OR
- two blocks "1 2" and " 3 4 5" OR
- two blocks "1 " and "2 3 4 5" OR
- six blocks "1", " 2 ", "3", " ", "4" and " 5" OR
- somehow else
no assumption must be made on how the data is fragmented on the receiver side". otoh, tcp/ip guarantees that data is received in order, so if you send to messages "1 2 " and "3 4 5" one after another, the resulting stream is guaranteed to be "1 2 3 4 5", wheras with UDP you might get "3 4 5" and "1 2 ".
therefore, if you want to be parse your data correctly, you must not assume that you get "1 2 3 4 5" as one message out of [tcpfoo]. instead you should parse the stream for some terminating sequence ";" or CRLF or whatever and re-packetize the stream.
it might only _seem_ to be "not necessary" in a given situtation, simply because you were observing some messages that came out correctly.
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
Martin
On 02/16/12 19:39, Martin Peach wrote:
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
from the application's point of view, tcp/ip _is_ a serial connection. i don't think there is any guarantee that the ip-packets are not re-fragmented during transmission.
nevertheless, in practice you are right that you will experience problems more easily with large IP packets, and smallish ones (like the ones we were originally talking about) might hardly ever be effected.
fgmadr IOhanne
here is a quick patch with it working, but i am getting this funky error to the pd window i assume it's fromthe grid not updating properly?
pp
while executing ".x2e38c10.c delete 2e391b0POINT" ("uplevel" body line 1) invoked from within "uplevel #0 $cmds_from_pd"(Tcl) INVALID COMMAND NAME: invalid command name ".x2e38c10.c" while executing ".x2e38c10.c delete 2e391b0POINT" ("uplevel" body line 1) invoked from within "uplevel #0 $cmds_from_pd"(Tcl) INVALID COMMAND NAME: invalid command name ".x2e38c10.c"
Hi Martin
On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote:
On 02/16/12 19:39, Martin Peach wrote:
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes).
nevertheless, in practice you are right that you will experience problems more easily with large IP packets, and smallish ones (like the ones we were originally talking about) might hardly ever be effected.
No, also the smallish ones are affected. See above. I experienced that with Pd.
Roman
On 2012-02-16 16:38, Roman Haefeli wrote:
Hi Martin
On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote:
On 02/16/12 19:39, Martin Peach wrote:
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes).
The [mrpeach/tcp*] classes don't make any assumptions about content, they just output lists of floats as they arrive. It seems more efficient to do that than to output individual floats. Whatever is handling the output of a [tcp*] should be able to decide for itself where the packet boundaries are. I don't assume that a list is necessarily the same length as a packet.
nevertheless, in practice you are right that you will experience problems more easily with large IP packets, and smallish ones (like the ones we were originally talking about) might hardly ever be effected.
No, also the smallish ones are affected. See above. I experienced that with Pd.
You can get multiple user-packets inside one TCP or UDP packet, but I have never seen a small one broken in two. For an http reply the web page can arrive spread over several packets, and the connection closes when all the packets are in. I don't have any problems with those.
It can be interesting to use Wireshark to look at what's actually in the packets.
Martin
On Thu, 2012-02-16 at 17:01 -0500, Martin Peach wrote:
On 2012-02-16 16:38, Roman Haefeli wrote:
Hi Martin
On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote:
On 02/16/12 19:39, Martin Peach wrote:
As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets.
I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes).
The [mrpeach/tcp*] classes don't make any assumptions about content, they just output lists of floats as they arrive. It seems more efficient to do that than to output individual floats. Whatever is handling the output of a [tcp*] should be able to decide for itself where the packet boundaries are. I don't assume that a list is necessarily the same length as a packet.
In practice, it only makes senses to deal with lists instead of single numbers (performance wise) when you don't need to look at the content of the data at all, for instance when you just proxy it to some other receiver (file, comport, netsocket, etc.).
However, whenever you need to parse the protocol, you need to serialize the data anyway (since the list length doesn't give you any useful information) and doing that in user-space is much slower than the external doing it on its own. This is the is the case I consider the common one. This is why I still think, that the output shouldn't be lists, but a stream of floats.
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-16 23:01, Martin Peach wrote:
The [mrpeach/tcp*] classes don't make any assumptions about content, they just output lists of floats as they arrive. It seems more efficient to do that than to output individual floats. Whatever is handling the output of a [tcp*] should be able to decide for itself where the packet boundaries are. I don't assume that a list is necessarily the same length as a packet.
i don't think [mrpeach/tcp*] is doing anything wrong here. on the low-level side, you get buffers of data from the socket. [mrpeach/tcp*] passes these buffers into user-land as they are. great!
theer's a reason why [iemnet/tcp*] does it slightly differently (that is: serialize the data):
- explicitely break the false sense of security of the user, that tcp/ip
could be packet oriented; because from user experience (mainly roman's netpd) it shows that you must take re-fragmentation into account if you want to make a stable system. if you receive the stream as multi-byte chunks the user therefore ought to serialize it manually.
- for performance reasons, it is way more efficient to do the
serialization in C than in Pd.
]btw, you can turn off automatic serialization with [iemnet/tcp*", but i would not advise to do so.
fgjmasdr IOhannes
still no luck i've never tried this before using regexp in python we were able to use list methods and line splits but i am having a hard time getting two lists of numbers extracted
pp ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Pagano, Patrick [pat@digitalworlds.ufl.edu] Sent: Thursday, February 16, 2012 11:50 AM To: Roman Haefeli; pd-list@iem.at Subject: Re: [PD] socket object?
i cannot find iemnet for OSX
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Roman Haefeli [reduzent@gmail.com] Sent: Thursday, February 16, 2012 11:41 AM To: pd-list@iem.at Subject: Re: [PD] socket object?
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote:
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way).
Roman
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
Here's a pdlua script to do that, it should work with pd-extended. It's quite simple to customize for any ascii packet such as yours that has a fixed structure.
Martin
On 2012-02-16 11:50, Pagano, Patrick wrote:
i cannot find iemnet for OSX
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Roman Haefeli [reduzent@gmail.com] Sent: Thursday, February 16, 2012 11:41 AM To: pd-list@iem.at Subject: Re: [PD] socket object?
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote:
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way).
Roman
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
i get bytes2pp ...counldn't create i downloaded both files i am on extended 42.5 on a mac
pp
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Martin Peach [martin.peach@sympatico.ca] Sent: Thursday, February 16, 2012 12:56 PM To: pd-list@iem.at Subject: Re: [PD] socket object?
Here's a pdlua script to do that, it should work with pd-extended. It's quite simple to customize for any ascii packet such as yours that has a fixed structure.
Martin
On 2012-02-16 11:50, Pagano, Patrick wrote:
i cannot find iemnet for OSX
using bytes to any and mr peach's tcpclient i am able to get the data back to the same thing max was spitting out
print: [[[6171 , 520]] , [[590 , 655]]] but i cannot seem to strip off the brackets correctly
i can strip off one delineator so it seems
i will try gridflow next
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Roman Haefeli [reduzent@gmail.com] Sent: Thursday, February 16, 2012 11:41 AM To: pd-list@iem.at Subject: Re: [PD] socket object?
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote:
On 02/16/12 16:46, Pagano, Patrick wrote:
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]]
and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers?
moocow's "pdstring" library might come in handy.
you could also try to do something like this:
[tcpclient 7777] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]<-[connect localhost 7777(
This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way).
Roman
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
okay i'll give that a go pp ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] on behalf of Martin Peach [martin.peach@sympatico.ca] Sent: Thursday, February 16, 2012 1:42 PM To: Pagano, Patrick Cc: pd-list@iem.at Subject: Re: [PD] socket object?
On 2012-02-16 13:39, Pagano, Patrick wrote:
i get bytes2pp ...counldn't create i downloaded both files i am on extended 42.5 on a mac
You probably need extended 43.1 for that, or build loaders/pdlua for yourself.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2012-02-16 à 15:46:00, Pagano, Patrick a écrit :
Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]] and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10
See GridFlow's [ascii_to_f]
helpfile @ http://gridflow.ca/help/ascii_to_f-help.html
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
Mathieu Bouchard -
Pagano, Patrick -
Roman Haefeli