On 03/31/2017 10:38 PM, Csaba Láng wrote:
But a new problem came up, that a killed frozen pd-extended connected via udpsend to a puredata vanilla patch does not reconnect after restarting both from a script, as in the console it is printed that udp still connected. How could i make a dynamic port number in both independent patches?
this depends on which objects you are using for network communication. at least the iemnet receiver objects (maybe also the mrpeach objects) allow you to not specify a port (defaulting to a random available port) *and* to query that port. if you are bound to objects that don't allow to query the current port (afaik [netreceive]), you could just check whether the port was successfully opened from within the patch (by try-connecting to the [netreceive] and sending some special ping message, and checking whether it came through), and if not iterate to the next port number.
then you'd need a way to communicate the port number to the watchdog pd (e.g. by writing that number to a known file).
personally i'd make sure that:
already known when the watched process is going to be started; this way you can communicate the port-number simply via a "-send" argument)
most likely i would write the watchdog in some other language, like python, rather than Pd; and I would make it do all the job-control (starting and killing the watched program), rather than putting all/parts of that logic into a 3rd application (your shell script that launches both the watchdog and the watched program)
btw, what is the reason you use pd-vanilla and pd-extended in parallel (it seems PdX is only used as a watchdog). when starting Pd from the cmdline, there shouldn't be any problems starting to instances of the same "app" (the don't-open-two-instances logic is hidden in the pd-gui, but when starting Pd from the cmdline you usually run the pd-dsp binary (which then force-starts a pd-gui))
gfmards IOhannes