what are you looking for? just the python script or do you want also the pyext scripts? i mean there are two ways to use this, the first is from python, the second from PD via pyext.

Pagano, Patrick wrote:

Thanks Chris Does anyone know where the scripts [which I thought were python] live that fetch images from the internet and bring them into pd via GEM?

-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Chris McCormick Sent: Monday, December 14, 2009 10:52 AM To: pd-list@iem.at Subject: [PD] PyPd

Hi All,

I finally packaged up some code I've had lying around for a while and added it to PdParser to make PyPd - classes for interfacing with Pd from inside Python.

You can use Pd.py to launch Pd as a subprocess and communicate with it via sockets. You can use PdParser.py to parse .pd files.

http://mccormick.cx/projects/PyPd/

I started these classes quite a while ago, but their ongoing development is being driven primarily by RjDj projects.

Chris.

---

http://mccormick.cx

---

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

---

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

if you want to use it from python just take scripts.py it has some examples of how to use it in the botton of the file. If you want to use it from PD you need all the files, scr.py and search.py just wrap scripts.py with pyext classes, in this case check script_examples.pd . There is some other utilities in the library, check the readme file for details. let me know any question, i have not tested it for a while so some parts might not work if the websites have changed their URL query system.

http://www.ixi-audio.net/content/download/pynetutils.tar.gz

enrike

Pagano, Patrick wrote:

Both would be wonderful I saw a useful version with freesound in ptml, but I would like to find the images too

pp

-----Original Message----- From: altern [mailto:altern2@gmail.com] Sent: Monday, December 14, 2009 12:31 PM To: Pagano, Patrick Cc: pd-list@iem.at Subject: Re: [PD] PyPd

what are you looking for? just the python script or do you want also the pyext scripts? i mean there are two ways to use this, the first is from python, the second from PD via pyext.

Pagano, Patrick wrote:

...

Thanks Chris Does anyone know where the scripts [which I thought were python] live that fetch images from the internet and bring them into pd via GEM?

-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Chris McCormick Sent: Monday, December 14, 2009 10:52 AM To: pd-list@iem.at Subject: [PD] PyPd

Hi All,

I finally packaged up some code I've had lying around for a while and added it to PdParser to make PyPd - classes for interfacing with Pd from inside Python.

You can use Pd.py to launch Pd as a subprocess and communicate with it via sockets. You can use PdParser.py to parse .pd files.

http://mccormick.cx/projects/PyPd/

I started these classes quite a while ago, but their ongoing development is being driven primarily by RjDj projects.

Chris.

---

http://mccormick.cx

---

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

---

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

On Dec 14, 2009, at 11:31 PM, Chris McCormick wrote:

On Mon, Dec 14, 2009 at 10:50:44PM -0500, Hans-Christoph Steiner
wrote:

...

This looks quite useful. Is the process management pretty robust? I have a big python script for running help patches and unit tests. It mostly works quite well, but occasionally there is some weird bug
in a patch that causes the pd process to hang without notification.

I guess it depends how the pd process is "hanging". If it's a proper
crash then Pd.py will fire a callback method which you can override. I have
never had the pd process just hang ( [bang( -> [until]? ) before so I don't know
how it would react. Maybe I should test that.

Hanging as in not responding, but not quitting. I guess bang/until
would do that. Its tricky to catch. I guess there needs to be some
kind of ping.

...

Here's my script:

http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/scripts/load_eve...

Looks good.

...

I suppose this script should use PyPd.

Well, I don't know. If it works well now then why change it? :)

I don't actually use the subprocess module, rather a Popen, which is
probably a mistake. That's probably because I started it before the subprocess
module was available. I like how you are auto-generating the netreceive patch.
I am just including it in the patches/ subdirectory. I guess my way gives the
author flexibility to use [python-interface] in their own patch as a
singleton for communicating with Python.

Basically because you know your script better I think it would be a
good idea to stick with it until there is a compelling reason to change and
learn something new.

We are using it primarily for managing a long-running Pd process
rather than a one-shot unit test. Maybe your script is more sensible for tests
which just fire and then exit immediately.

The advantage of this using PyPd for the unittest scripts is that PyPd
becomes more robust in the process. The only issue in my mind is
whether PyPd has the same goal in terms of monitoring the pd process.
I can't see why not, but I suppose there could be a reason.

.hc

Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith

On Dec 15, 2009, at 6:48 AM, Chris McCormick wrote:

On Mon, Dec 14, 2009 at 11:40:30PM -0500, Hans-Christoph Steiner
wrote:

...

On Dec 14, 2009, at 11:31 PM, Chris McCormick wrote:

...

On Mon, Dec 14, 2009 at 10:50:44PM -0500, Hans-Christoph Steiner

Hanging as in not responding, but not quitting. I guess bang/until would do that. Its tricky to catch. I guess there needs to be some kind of ping.

I will test it, but that faces the same old can of worms with
[until], which is to say, what if the user just passed a very very large number to
until? (e.g. if they are processing a very long list).

Yup, no easy answer. This is where the timeout comes in. I can't
think of another way.

...

The advantage of this using PyPd for the unittest scripts is that
PyPd becomes more robust in the process. The only issue in my mind is whether PyPd has the same goal in terms of monitoring the pd
process. I can't see why not, but I suppose there could be a reason.

I am quite happy for you to use PyPd in your unit test script. :)

What do you mean by "the same goal in terms of monitoring the pd
process"?

The goal of PyPd is two things: 1) provide an easy way to launch,
communicate with, and shut down an instance of Pd. 2) provide an easy and
general way to parse Pd files in order to extract useful information from them.

Those both sound good. For the unittests, #1 seems more important. I
guess the question is whether you want to deal with the until/timeout
problem in PyPd. I.e. tracking whether a Pd process stops responding
and providing a way to kill/restart it.

.hc

Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom

On Fri, Dec 18, 2009 at 01:11:16PM -0500, Hans-Christoph Steiner wrote:

...

I will test it, but that faces the same old can of worms with [until], which is to say, what if the user just passed a very very large number to until? (e.g. if they are processing a very long list).

Yup, no easy answer. This is where the timeout comes in. I can't think of another way.

Yes, I see that in the case of unit tests, which are pretty much always meant to run for a finite time and then exit, the upper bound of the run time is a known quantity on a reasonably fast CPU. A timeout in this case is a fine solution.

...

The goal of PyPd is two things: 1) provide an easy way to launch, communicate with, and shut down an instance of Pd. 2) provide an easy and general way to parse Pd files in order to extract useful information from them.

Those both sound good. For the unittests, #1 seems more important. I guess the question is whether you want to deal with the until/timeout problem in PyPd. I.e. tracking whether a Pd process stops responding and providing a way to kill/restart it.

This doesn't belong in the library, but providing your own watchdog/timeout would be easy, and killing/restarting Pd is the whole point of the library so that should be easy too. Basically you should sub-class the Pd class to build something with that functionality. Email me off list if you get stuck or need tips on doing that. This could be as simple as spawning a separate thread which sleeps for 10 seconds and then kills Pd if the unit test is still running, or exits if it receives a special Event() from the main loop before then.

Yesterday I improved the exiting routine for RjDj, so hopefully it's quite robust now. I can see that you will already need two things added to PyPd:

• Ability to specify which Pd to execute.
• Make sure Pd can be restarted once it's been killed.

The first one is quite minor, and the second one is just a matter of testing, so I'll try and make them soon.

Chris.

http://mccormick.cx