hi
----- Original Message ----- From: "Mike Wozniewski" mike@ozmediasolutions.com To: "PD List" pd-list@iem.at
However, for netreceive, there doesn't seem to be an inlet or any
properties dialog where I can
receive a parameter. It can't be that I have to hardcode it in the object box everytime?!
Any ideas? Mike Wozniewski
you could also create / delete [netreceive] dynamically in a subpatch. i admit this may not be the nice solution, you're looking for.
roman
[netclient]/[netserver] allow multiple, two-way connections, so it
might eliminate the need for dynamic port numbers.
.hc
On May 2, 2005, at 2:56 PM, Mike Wozniewski wrote:
Hi all,
I'm using netsend / netreceive , and I like the fact that I can have
a variable port number with my netsend. ie, I can send a message with:connect localhost $1
However, for netreceive, there doesn't seem to be an inlet or any
properties dialog where I can receive a parameter. It can't be that I
have to hardcode it in the object box everytime?!Any ideas?
Thanks, Mike Wozniewski _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
[netclient]/[netserver] allow multiple, two-way connections, so it
might eliminate the need for dynamic port numbers.
yes, but you need maxlib.
currently there is no way to simply disconnect/reconnect on the receiver-side. dunno why though
mfg.ad.sr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
[netclient]/[netserver] allow multiple, two-way connections, so it
might eliminate the need for dynamic port numbers.yes, but you need maxlib.
currently there is no way to simply disconnect/reconnect on the receiver-side. dunno why though
technically speaking because the socket get's opened in the new() routine. There is nothing against moving it into a separare routine and make it accessable from outside. But then, what happens to netsend objects, that still are connected to a netreceive that changes it's port?
Olaf
Olaf Matthes wrote:
IOhannes m zmoelnig wrote:
currently there is no way to simply disconnect/reconnect on the receiver-side. dunno why though
technically speaking because the socket get's opened in the new() routine. There is nothing against moving it into a separare routine and
well, yes; and there [netreceive] doesn't accept messages to set the port number ;-)
make it accessable from outside. But then, what happens to netsend objects, that still are connected to a netreceive that changes it's port?
and what happens if you close a patch, while still being connected ?
btw, does pd still crash when you do so on tcp/ip ? (that is one of the main reasons i soon started to use UDP)
mfg,.asd.r IOhannes
IOhannes m zmoelnig wrote:
make it accessable from outside. But then, what happens to netsend objects, that still are connected to a netreceive that changes it's port?
and what happens if you close a patch, while still being connected ?
Okay, that's right. But when you close a patch you probably want to stop using it.
btw, does pd still crash when you do so on tcp/ip ? (that is one of the main reasons i soon started to use UDP)
well, in line 343 of x_net.c it says:
/* LATER make me clean up open connections */
I never tried it whether it crashes, but chances are high it does, at least it calls for trouble if we just close the listening socket without closing the connections.
Olaf
Olaf Matthes wrote:
and what happens if you close a patch, while still being connected ?
Okay, that's right. But when you close a patch you probably want to stop using it.
and i guess the same is true, if you want to change the port of [netreceive]. probably there really should be a message [disconnect( to clean up the connection; changing the port must not work as long as there are open connections
I never tried it whether it crashes, but chances are high it does, at least it calls for trouble if we just close the listening socket without closing the connections.
i just did a quick test and it didn't crash; but maybe the test was too naive
mfg.asd.r IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mike Wozniewski -
Olaf Matthes -
Roman Haefeli