Dear list,
I want to create an automatic control of a patch which can freeze. The first patch send every x seconds a signal via osc to an other patch. If the first patch does not respond after x+n seconds the first the second patch runs a shell script to killall pd instances than run a shell script which starts the patches
like this:
/Applications/Pd-0.47-1-64bit.app/Contents/MacOS/Pd /Users/xxx/Desktop/OSCcontrol.pd sleep 5 /Applications/Pd-extended.app/Contents/MacOS/Pd-extended /Users/xxx/Desktop/OSCcontrolsend.pd
every time pd starts, each instance opens twice later even three times and so on. What is the solution? Why this happens?
Is there any hope?
Best,
Popesz
On 2017-03-28 23:18, Csaba Láng wrote:
/Applications/Pd-0.47-1-64bit.app/Contents/MacOS/Pd /Users/xxx/Desktop/OSCcontrol.pd sleep 5 /Applications/Pd-extended.app/Contents/MacOS/Pd-extended /Users/xxx/Desktop/OSCcontrolsend.pd
every time pd starts, each instance opens twice later even three times and so on. What is the solution? Why this happens?
i think this is your OS trying to be helpful and restoring the setup before the crash (one or more instances of your patch), in addition to you loading (yet another) instance of the same patch.
not being an OSX user i don't have any solution at hand.
fgamsdr IOhannes
yes looks like the best solution is to delete the files from the Saved Application folder all files and block it.
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?
Popesz
On Wed, Mar 29, 2017 at 12:04 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2017-03-28 23:18, Csaba Láng wrote:
/Applications/Pd-0.47-1-64bit.app/Contents/MacOS/Pd /Users/xxx/Desktop/OSCcontrol.pd sleep 5 /Applications/Pd-extended.app/Contents/MacOS/Pd-extended /Users/xxx/Desktop/OSCcontrolsend.pd
every time pd starts, each instance opens twice later even three times
and
so on. What is the solution? Why this happens?
i think this is your OS trying to be helpful and restoring the setup before the crash (one or more instances of your patch), in addition to you loading (yet another) instance of the same patch.
not being an OSX user i don't have any solution at hand.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
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:
- the watchdog is a persistent process (that only gets started once)
- the watchtdog acts as the server (e.g. it allocates a port that is
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
-
Csaba Láng -
IOhannes m zmoelnig -
IOhannes m zmölnig