Re: [PD] Execute command from Pd

2017-05-29 Thread patrice colet
Le 29/05/2017 à 11:40, Roman Haefeli a écrit : My main problem is still that I find it hard to kill a still running command, especially when I want to kill a specific one when many are running. The kill command should do the trick, it needs PID, and this should appear in stdout by doing

Re: [PD] Execute command from Pd

2017-05-29 Thread Claude Heiland-Allen
On 29/05/17 23:30, Peter P. wrote: > In cases where pd is started from the command line one could write a > wrapper script that gets the directory of the patch file that would have > to be passed to pd as argument. The script could then relay this info to > pd using pdsend probably. pd has a

Re: [PD] Execute command from Pd

2017-05-29 Thread Peter P.
* Roman Haefeli [2017-05-29 22:58]: > On Mon, 2017-05-29 at 13:15 -0600, Dan Wilcox wrote: > > Seconded. IMO something like [getdir] should be included with > > vanilla, perhaps as part of get canvas info functionality. > > I can't think of any case where relative to Pd's

Re: [PD] Execute command from Pd

2017-05-29 Thread Roman Haefeli
On Mon, 2017-05-29 at 13:15 -0600, Dan Wilcox wrote: > Seconded. IMO something like [getdir] should be included with > vanilla, perhaps as part of get canvas info functionality. I can't think of any case where relative to Pd's start location is useful (on macOS it seems to always be /, no matter

Re: [PD] Execute command from Pd

2017-05-29 Thread Dan Wilcox
Seconded. IMO something like [getdir] should be included with vanilla, perhaps as part of get canvas info functionality. I’m using [getdir] for things like this in PdParty and I have a few abstractions for working with paths (p_*): https://github.com/danomatika/rc-patches/tree/master/rc

[PD] aAaA: any attributes and arguments in Pd vanilla (v. 0.1) Re: Feature Proposal

2017-05-29 Thread padovani
Found this thread ( https://lists.puredata.info/pipermail/pd-list/2016-08/115936.html) some days ago... and then I have forked the IOhannes abstraction that Matt Barber mentions to deal with any number of arguments and to implement the attribute tag recognition. This approach could be used to

Re: [PD] Execute command from Pd

2017-05-29 Thread Antoine Rousseau
> > 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

Re: [PD] Execute command from Pd

2017-05-29 Thread Roman Haefeli
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

Re: [PD] Execute command from Pd

2017-05-29 Thread Antoine Rousseau
> > 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

Re: [PD] Execute command from Pd

2017-05-29 Thread Roman Haefeli
On Mon, 2017-05-29 at 10:50 +0200, Antoine Rousseau wrote: > for full duplex: > > pdreceive 5678 | your_command | pdsend 6789 & > > see attached patch (using ggee/shell, but would also works with e.g > motex/system). > Thansks. From what I understand this allows you to write to talk to the

Re: [PD] Execute command from Pd

2017-05-29 Thread IOhannes m zmoelnig
On 2017-05-29 11:05, Jack wrote: > Something like this ? : > > [netreceive -u 5678] > | > [print] > > You can also add 2>&1 if you want to redirect error. This could give > something like : > > $ ls 2>&1 | pdsend 5678 localhost udp > > or or $ (./test.sh | pdsend localhost udp) 2>&1 |

Re: [PD] Execute command from Pd

2017-05-29 Thread Roman Haefeli
Dear Max, Dear Chris Please read the my first post in this thread. There I roughly described in which ways [popen] and [system] are different (and not suitable for my case). Roman On Mon, 2017-05-29 at 17:12 +0800, Chris McCormick wrote: > On 29/05/17 17:03, Max wrote: > > > > What about your

Re: [PD] Execute command from Pd

2017-05-29 Thread Chris McCormick
On 29/05/17 17:03, Max wrote: What about your own moonlib/popen? How do ggee/shell, motex/system and moonlib/popen compare? 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? Cheers, Chris. --

Re: [PD] Execute command from Pd

2017-05-29 Thread Jack
Something like this ? : [netreceive -u 5678] | [print] You can also add 2>&1 if you want to redirect error. This could give something like : $ ls 2>&1 | pdsend 5678 localhost udp or $ output=$(ls 2>&1) ; echo -e "$?\n$output" | pdsend 5678 127.0.0.1 udp The first line will give you the

Re: [PD] Execute command from Pd

2017-05-29 Thread Max
What about your own moonlib/popen? How do ggee/shell, motex/system and moonlib/popen compare? On 2017년 05월 29일 10:50, Antoine Rousseau wrote: for full duplex: pdreceive 5678 | your_command | pdsend 6789 & see attached patch (using ggee/shell, but would also works with e.g motex/system).

Re: [PD] Execute command from Pd

2017-05-29 Thread Antoine Rousseau
for full duplex: pdreceive 5678 | your_command | pdsend 6789 & see attached patch (using ggee/shell, but would also works with e.g motex/system). cheers Antoine Rousseau http://www.metalu.net __ http://www.metaluachahuter.com/