When I distribute the script together with my Pd project, I'd rather want it relative to the patch, otherwise the script won't be found on other users' machines.
As you need [ggee/shell], then why not using also [ggee/getdir] to know where your patch is located ?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-05-29 13:28 GMT+02:00 Roman Haefeli reduzent@gmail.com:
On Mon, 2017-05-29 at 13:03 +0200, Antoine Rousseau wrote:
And does anybody know if any of them are blocking so that the timing of an external script is deterministic from within Pd's logical timeframe?
afaik only [system] is blocking, while [shell] and [popen] use Pd polling system through Pd main loop.
I find it hard to kill a still running command, especially when I want to kill a specific one when many are running.
I would suggest writing your own script, that would call jacktrip, and which would take an additional (but ignored) ID parameter, which could then be used to identify each of the processes, to allow killing them individually with pkill.
For instance:
[my_script.sh ID1 ACTUAL_PARAMETERS &] | [shell or system or popen]
then:
[pkill -f my_script.sh ID1 &] | [shell or system or popen]
I am currently using the following script that outputs the command's PID (thanks to Jack for his help in this):
#!/bin/bash while read line do echo "$line" done < <($@ 2>&1 & echo "PID $!")
Using a script has its own complications, though. Unfortunately, [shell] opens scripts relative to Pd's start location. So using a local script is not portable. When I distribute the script together with my Pd project, I'd rather want it relative to the patch, otherwise the script won't be found on other users' machines.
I am still not quite satisfied with the available options yet. Will experiment/think some more.
Anyway, thanks a lot for your thoughts.
Roman