Re: [PD] Execute command from Pd

[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/



2017-05-28 20:06 GMT+02:00 oliver :

> cyrille henry wrote:
>
>> if the comand you execute is somthing like :
>> ls | pdsend 5678 localhost udp
>>
>> then you can get the result of the command in pd event if the object
>> used have no feedback.
>>
>
> thanks !
> but how would this work the other way round ?
>
> best
>
> oliver
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
#N canvas 756 157 567 445 10;
#X obj 60 146 ggee/shell;
#X obj 63 307 netsend;
#X msg 63 214 connect localhost 5678;
#X obj 62 387 netreceive 6789;
#X obj 62 407 print fromnet;
#X msg 89 268 send hello world;
#X text 24 34 1: run your command (here "cat"):;
#X text 26 189 2: connect the netsend:;
#X text 27 252 3: send a message to your command:;
#X obj 63 330 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X text 27 368 4: receive the answer here:;
#X msg 335 253 disconnect;
#X obj 308 50 cnv 15 250 40 empty empty empty 20 12 0 14 -260097 -66577
0;
#X msg 308 94 pkill -f "pdreceive 5678";
#X obj 308 116 t a b;
#X text 313 56 5:you MUST kill before quiting Pd! (else Pd will hang)
, f 35;
#X text 462 423 A.Rousseau 2017;
#X text 86 7 UNIX SHELL I/O EXAMPLE;
#X msg 60 53 pdreceive 5678 | cat | pdsend 6789 &;
#X connect 1 0 9 0;
#X connect 2 0 1 0;
#X connect 3 0 4 0;
#X connect 5 0 1 0;
#X connect 11 0 1 0;
#X connect 13 0 14 0;
#X connect 14 0 0 0;
#X connect 14 1 11 0;
#X connect 18 0 0 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

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


cheers

Antoine Rousseau
http://www.metalu.net  __ 
http://www.metaluachahuter.com/ 




2017-05-28 20:06 GMT+02:00 oliver >:


cyrille henry wrote:

if the comand you execute is somthing like :
ls | pdsend 5678 localhost udp

then you can get the result of the command in pd event if the object
used have no feedback.


thanks !
but how would this work the other way round ?

best

oliver


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 code of your command and next
lines the stdout or stderr (redirected in stdout).
++

Jack



Le 28/05/2017 à 20:06, oliver a écrit :
> cyrille henry wrote:
>> if the comand you execute is somthing like :
>> ls | pdsend 5678 localhost udp
>>
>> then you can get the result of the command in pd event if the object
>> used have no feedback.
> 
> thanks !
> but how would this work the other way round ?
> 
> best
> 
> oliver
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 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.
> 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 | pdsend 7778 localhost udp

this will give you the stdout on port , and the stderr on 7778.

or

using the `annotate-output` program (on a Debian system you can get this
from the `devscripts` package):


$ annotate-output + ./test.sh | pdsend  localhost udp

this will prefix the output with "O:" (for stdout) and "E:" (for
stderr), so you can simply use [route O: E:] to distinguish between the
two streams.
it also sends some informational (prefix "I:") data, from which you can
get the exitcode of the program (once it finishes).
in the above example, i suppressed all timestamping. omit the "+" if you
want timestamps as well.


ghsdmr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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
stdin of the launched command. That's a neat trick.

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. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 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]


Antoine Rousseau
  http://www.metalu.net  __
http://www.metaluachahuter.com/



2017-05-29 11:40 GMT+02:00 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
> stdin of the launched command. That's a neat trick.
>
> 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.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

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




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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://www.metalu.net  __
http://www.metaluachahuter.com/



2017-05-29 13:28 GMT+02:00 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 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
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

[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 detect other kinds of "pseudo" types!

I hope it is usefull for other people!
http://git.nics.unicamp.br/nicspd/patchTools/AnyArgumentsAndAttributes

Cheers,
José

2016-08-18 13:08 GMT-03:00 Roman Haefeli :

> Hey all
>
> After having worked with Python a bit, I'm very intrigued by the many
> useful data containers it provides (tuples, lists, sets,
> dictionaries).
>
> At the same time, I am sometimes troubled by the inflexibility of
> arguments in Pd. Writing abstractions that deal with a variable number
> of arguments is hard. Even retrieving the number of specified arguments
> inside the abstraction is hard. Also, if you have fixed argument part
> and a variable part, you need to make sure that the variable part is
> put at the end of the argument list, otherwise there is no way to
> distinguish them.
>
> I'm just thinking loud here and do not have any idea, how hard it would
> be to implement in Pd. I'm just trying to raise a discussion about the
> topic. Here some (probably not very thought-through) ideas:
>
>
> == GROUPING IN ABSTRACTION ARGUMENTS ==
> Allow grouping of atoms, so that you can pass a whole list to one
> single argument like this:
>
> [myabs ( one two 3 ) 4 five]
>
> inside the abstraction:
>
> $1 would evaluate to 'list one two 3'
> $2 would evaluate to '4'
> $3 would evaluate to '5'
>
> == GETTING NUMBER OF ARGS ==
> With the same example:
>
> [myabs ( one two 3 ) 4 five]
>
> inside the abstraction:
>
> $# would evaluate to '3' (number of arguments given)
>
> == GROUPING IN MESSAGES ==
> [1 2 ( 97 98 99 ) 4 5(
> |
> [$2 (
>
>
> would give '97 98 99'
>
> == NAMED ARGUMENTS ==
>
> [myabs freq=440 vol=1]
>
> inside the abstraction:
>
> $freq would evaluate to '440'
> $vol would evalute to '1'
>
> If a certain argument is not specified as creation argument, it would
> evaluate to '0' (similar to existing behavior).
>
>
> == USE CASE ==
> [oscformat] takes an arbitrary number of arguments to create an OSC
> address. While I find this the cleaner and more pd-like way than
>  /one/two/three, this has big draw-back. You currently cannot pass the
> OSC address (containing an arbitrary number of address fields) to an
> abstraction when using [oscformat]. The number of arguments must known
> beforehand when using this format. With [packOSC] from the osc library,
> you can do:
>
> [myabs /base/address]
>
> and therein:
>
> [packOSC $1/freq]
>
> which evaluates to /base/address/freq.
>
> By allowing grouping of arguments, one could achieve the same without
> resorting to long symbols (which has other drawbacks). In the main
> patch you could create:
>
> [myabs ( base address )]
>
> and therein:
>
> [oscformat $1 freq]
>
> and [oscformat] would actually see 'base address freq'.
>
> There are many other cool things you could do. It would allow to create
> lists of lists, which can be easily split again later (which is
> currently very hard to do and involves a lot of serializing and using
> delimiters or prepended number-of-elements). Generally, it would allow
> to create much more flexible abstractions.
>
> Any feedback welcome.
>
> Roman
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 


> On May 29, 2017, at 10:30 AM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Antoine Rousseau mailto:anto...@metalu.net>>
> Subject: Re: [PD] Execute command from Pd
> Date: May 29, 2017 at 6:40:26 AM MDT
> To: Roman Haefeli mailto:reduz...@gmail.com>>
> Cc: Pd-list mailto:pd-list@lists.iem.at>>
> 
> 
> 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://www.metaluachahuter.com/ 
> 

Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 where you double-
clicked a patch). On the other hand, I can think of quite a few cases
where relative to patch would be desired. [shell] is only one example.
But also when opening patches by message to Pd, it would make much more
sense to load them relative to the current patch (though that might not
be an advertised feature of Pd).

If the notion that relative to patch is superior to relative to Pd
would find wide adoption, we often wouldn't even need something like
[getdir].

But I agree, that something like [getdir] in vanilla would be handy.

Roman


> I’m using [getdir] for things like this in PdParty and I have a few
> abstractions for working with paths (p_*): https://github.com/danomat
> ika/rc-patches/tree/master/rc
> 
> > On May 29, 2017, at 10:30 AM, pd-list-requ...@lists.iem.at wrote:
> > 
> > From: Antoine Rousseau 
> > Subject: Re: [PD] Execute command from Pd
> > Date: May 29, 2017 at 6:40:26 AM MDT
> > To: Roman Haefeli 
> > Cc: Pd-list 
> > 
> > 
> > > 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://www.metaluachahuter.com/
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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
> useful (on macOS it seems to always be /, no matter where you double-
> clicked a patch). On the other hand, I can think of quite a few cases
> where relative to patch would be desired. [shell] is only one example.
> But also when opening patches by message to Pd, it would make much more
> sense to load them relative to the current patch (though that might not
> be an advertised feature of Pd).
> 
> If the notion that relative to patch is superior to relative to Pd
> would find wide adoption, we often wouldn't even need something like
> [getdir].
> 
> But I agree, that something like [getdir] in vanilla would be handy.
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.

(2cents)
P

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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 command line argument that is useful for this kind of
thing.  Using pdsend from a startup script is prone to a race condition
(how do you know when pd is ready to recieve the message?).


Claude
-- 
https://mathr.co.uk

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Execute command from Pd

[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  'command & echo $!'




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list