Thanks,

That thread is on windows, and debian, and seemed solved for pd-0.48.0 (https://lists.puredata.info/pipermail/pd-list/2017-10/120849.html)

I’m on macOS:

Pd-0.48.1 ("") compiled 13:16:11 Jan 7 2018

I attach two patches that if opened the following way, won’t work on the first time:

$ pd -nogui netreceive-patch.pd & pd -nogui netsend-patch.pd 

connecting to port 5004
connecting stream socket: Connection refused (61)

On the second run, it reads:

bind: Address already in use (48)

On Feb 23, 2018, at 3:21 PM, Peter P. peterparker@fastmail.com wrote:

See the mailing list archive perhaps? https://lists.puredata.info/search?P=-nogui+AND+netsend&DEFAULTOP=and&am...

• Fede Camara Halac camarafede@gmail.com [2018-02-23 14:40]:

...

Hi all,

Any reason why sometimes opening 2 instances with -nogui and communicating via netsend and netreceive would fail?

I am careful enought to open the socket first (netreceive) and then to connect. With gui, I have no problem. With -nogui, sometimes the network does not initialize.

I realize I use Gem on one instance and not on the other, so a delay in load time might cause this, and a solution is to put netreceive in the patch with less loadtime, and delay (aka not the Gem patch)

but other than that I am wondering if -nogui would affect communication between instances.

Cheers,

Fede

fdch.github.io/tv

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

So you should first run "killall pd" (and even killall -9 pd when it's stuck), before running you command.

Thanks! You are correct that a pd process with the netreceive is still running. (fun fact, for me at least: When running it from a new terminal, the new netsend started printing on the previous terminal)

Now I tried it on a different mac. I was on macOS 10.9, now on 10.11.6 (same pd)

On first run, connection is established and patch works as expected, which is puzzling.

On second run (after effectively running killall pd, or killall -9 pd):

connecting stream socket: Connection refused (61)

Hi Peter,

I modified the patch so that netsend/netreceive take messages (attached)

The following doesn't work:

$ killall pd $ PORTNUM=5011; pd -nogui -send ";start listen $PORTNUM" -open netreceive-patch.pd & pd -nogui -send ";start connect localhost $PORTNUM" -open netsend-patch.pd connecting stream socket: Connection refused (61)

However, this does work:

$ killall pd $ PORTNUM=5012; pd -nogui -send ";start listen $PORTNUM" -open netreceive-patch.pd* & sleep 1 ; * pd -nogui -send ";start connect localhost $PORTNUM" -open netsend-patch.pd

I guess it's a timing issue?

On Fri, Feb 23, 2018 at 9:43 PM, Peter P. peterparker@fastmail.com wrote:

• Federico Camara Halac camarafede@gmail.com [2018-02-23 18:43]:

...

...

So you should first run "killall pd" (and even killall -9 pd when it's stuck), before running you command.

Thanks! You are correct that a pd process with the netreceive is still running. (fun fact, for me at least: When running it from a new terminal, the new netsend started printing on the previous terminal)

Now I tried it on a different mac. I was on macOS 10.9, now on 10.11.6 (same pd)

On first run, connection is established and patch works as expected,

which

...

is puzzling.

On second run (after effectively running killall pd, or killall -9 pd):

connecting stream socket: Connection refused (61)

Fede, can you confirm that no other Pd instance is running before you start your second instance?

I remember issues with the operating system leaving a port open and thus reserving it for a longer while than the application (Pd in this case) requests it. You could try to use a patch with a different port number when you start it the second time and see if that works.

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list