On Jul 19, 2008, at 7:24 PM, Jack wrote:
Le 19 juil. 08 à 17:25, zmoelnig@iem.at a écrit :
Quoting Claude Heiland-Allen claudiusmaximus@goto10.org:
[dumpOSC 5555] needs to be able to bind to network port 5555, if something else is already using it (or if the previous user of the port hasn't timed out completely) then dumpOSC will fail to create.
which btw, is by design and not a bug. it is the very same behaviour as the [netreceive] object has.
This is a real problem with [netreceive]. For example when Pd crash, if you open your last patch, Pd can't create your [netreceive] with the same port. Is it possible to force to close connection on this port to solve the problem ?
Try running 'killall pd' to make sure there isn't a hung pd process
still running. Otherwise, you have to wait for the OS to free the
network port. That's not a pd-specific problem, but network sockets
in general.
.hc
++
Jack
and before i forget it: have i already said that i would advice everybody to _not_ use [dumpOSC] (as part of the OSCx library) and instead use mrpeach's [udpreceive] and [unpackOSC]?
fadrm IOhannes
This message was sent using IMP, the Internet Messaging Program.
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
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom