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 'com

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 -send

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 start location is > usef

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 w

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 dete

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 http

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 system

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 stdi

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 | pd

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. -- http:/

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 return

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). ch

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/