Hey all,
I had an idea for a performance that uses the communication channel between the PD-gui and PD as the raw material of the performance. So this question has two parts:
#1. How can I start PD so that the PD GUI commands get sent to the regular PD port, as well as to a second port using a netreceive? I guess something like tee for sockets?
#2. Any ideas on interpreting this data, it should all be ; delimited, so netreceive should see it fine, and there should be no illegal characters in it. How could I intrepret it rawly though? perhaps using any2ascii to convert each character into an ASCII value?
Thanks all! This would be on OSX and/or linux.
..b.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 2, 2006, at 6:18 PM, B. Bogart wrote:
Hey all,
I had an idea for a performance that uses the communication channel between the PD-gui and PD as the raw material of the performance. So this question has two parts:
#1. How can I start PD so that the PD GUI commands get sent to the regular PD port, as well as to a second port using a netreceive? I
guess something like tee for sockets?
Look at netcat, I'll bet it can do this. Or you might be able to do
this with a second instance of Pd running a patch that does this.
.hc
#2. Any ideas on interpreting this data, it should all be ; delimited, so netreceive should see it fine, and there should be no illegal characters in it. How could I intrepret it rawly though? perhaps using any2ascii to convert each character into an ASCII value?
Thanks all! This would be on OSX and/or linux.
..b. _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.
- Eldridge Cleaver
I read:
#1. How can I start PD so that the PD GUI commands get sent to the regular PD port, as well as to a second port using a netreceive? I guess something like tee for sockets?
not necessary see below,
#2. Any ideas on interpreting this data, it should all be ; delimited, so netreceive should see it fine, and there should be no illegal
ngrep -d lo | nc localhost 6543 # or whatever port your netreceive uses
characters in it. How could I intrepret it rawly though? perhaps using any2ascii to convert each character into an ASCII value?
hmmm there /shouldn't/ be any but then again ...
HTH
x
Hi!
Thanks for the cool intro to ngrep and netcat, pretty slick.
So I went with your method, though ngrep prints a lot of extra data on top of what goes over the sockets. So I have a sed script in between that takes care of filtering out a lot of the junk.
So I'm getting the commands in PD, BUT I am not getting them the same as I see them in the console running ngrep.
When I don't pipe to a socket I see the commands fly by as I move the mouse and create objects. Once I send this data to PD I get a horrid lag and the messages seem to come in massive spurts with large waits in between I could not see how to change any possible buffer size in netcat to a single line... (flush on \n)
Same thing happens with netcat and pdsend.
Any ideas how I can do this so that the data I have coming into my second socket at least is somewhat (with 1s, rather than over 10s) in sync with the data going back and forth between the PD GUI and PD.
I'll check out Marc's software suggestions, but I'm doing this performance on OSX.
Once I get it to work I'll send an email with the whole command I end up using.
Thanks,
b.
CK wrote:
I read:
#1. How can I start PD so that the PD GUI commands get sent to the regular PD port, as well as to a second port using a netreceive? I guess something like tee for sockets?
not necessary see below,
#2. Any ideas on interpreting this data, it should all be ; delimited, so netreceive should see it fine, and there should be no illegal
ngrep -d lo | nc localhost 6543 # or whatever port your netreceive uses
characters in it. How could I intrepret it rawly though? perhaps using any2ascii to convert each character into an ASCII value?
hmmm there /shouldn't/ be any but then again ...
HTH
x
On 5 Jan 2006, at 3:41 AM, B. Bogart wrote:
When I don't pipe to a socket I see the commands fly by as I move the mouse and create objects. Once I send this data to PD I get a
horrid lag and the messages seem to come in massive spurts with large waits in between I could not see how to change any possible buffer size in
netcat to a single line... (flush on \n)
just a guess but.. is it because the data isn't being passed out of
netreceive until a ; comes along to end each message?
simon
nope, the data is litered with ";"s
It looks like PD is choking on the amount of data (but that seems unlikely) causing the buffer to fill up and then finall it gives up and lets it all out.
I got around this my using a fast metro and fifop to hold my own buffer of the stream "send 100 messages, then wait 5s, then send another 100" so that I can control how the data gets spit out.
I tested it this way:
#1. use the ngrep | sed stuff and send it to console Result: I see the messages streamed fine, one by one to console.
#2. send stdin to send from console into PD using the netcat command Result: I see no buffering, each messages arrives when I send it. Of course I can't send data I type as fast as PD does.
#3. send a captured file of the same PD data to netreceive Result: Acts just the same as #4
#4. shorthand: ngrep | sed | netcat Result: hundreds of messages build up before netreceive sends anything, then all of a sudden I get a huge flood of messages at once, then another lull and so on.
Maybe its really simple:
A. ngrep grabs the network data GUI -> PD B. We process and send this to PD C. PD then sends part of it back to the GUI (showing the data in GUI)
So its maybe just the feedback loop that is causing this behavoir, and it is afterall the feedback process that I'm interested in.
the PD gui as a kind of iterative chaotic equation, though I have not plotted it. It does tend towards periodic...
Since I don't get a single message at netreceive until a few hundred get sent, the feedback look has a large delay befor it folds back into itself...
Again I don't want to use a second PD instance since the data I want to work with the is creation of the patch that works with the data!
I'm performing the peice on saturday, so I hope I can make an mp3/ogg and put it up for all.
..b.
simon wise wrote:
On 5 Jan 2006, at 3:41 AM, B. Bogart wrote:
When I don't pipe to a socket I see the commands fly by as I move the mouse and create objects. Once I send this data to PD I get a horrid lag and the messages seem to come in massive spurts with large waits in between I could not see how to change any possible buffer size in netcat to a single line... (flush on \n)
just a guess but.. is it because the data isn't being passed out of netreceive until a ; comes along to end each message?
simon
It looks like PD is choking on the amount of data (but that seems unlikely)
whats unlikely aobut that? its not hard to make software choke, especially when involving feedback loops..
Again I don't want to use a second PD instance since the data I want to work with the is creation of the patch that works with the data!
in software feedback overload situations it does help to have a second instance, with the first one niced to a suitable level so that the second one can actally record to a file and transcieve to the d/A properly. but usually the first one goes nuts and crashes jackd and causes unpredictable CPU spikes so you really want a second computer..or a tape deck...
Hey Carmen,
Its working fine for what I'm looking for now.
the more DSP I put into the patch (which is not much, like 3 oscelators and some (yes expensive) canvas manipulation the more fun and messy it gets, actually the patch maxes out the g4 laptop easily.
I'll try and make a recording and post it.
.b.
carmen wrote:
It looks like PD is choking on the amount of data (but that seems unlikely)
whats unlikely aobut that? its not hard to make software choke, especially when involving feedback loops..
Again I don't want to use a second PD instance since the data I want to work with the is creation of the patch that works with the data!
in software feedback overload situations it does help to have a second instance, with the first one niced to a suitable level so that the second one can actally record to a file and transcieve to the d/A properly. but usually the first one goes nuts and crashes jackd and causes unpredictable CPU spikes so you really want a second computer..or a tape deck...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
carmen -
CK -
Hans-Christoph Steiner -
simon wise