[PD] [announce] py 0.0.1 python script object

[Joseph A. Sarlo]

I cannot comment on Thomas Grill's python object since I haven't looked at
it yet, but GC is not really an issue for GrIPD since all of the python
code runs in a separate process, and on Linux, at the lowest priority
(SCHED_OTHER) when launched from PD.  So, and correct me if I'm wrong, if
you run PD with -rt, nothing in the GrIPD python process should directly
effect audio calculation (other than memory utilization). The worst that
should happen would be small glitches in GUI response and updates, and the
very worst case scenario would be the GUI becoming unresponsive, but
there's really no way to avoid that issue.  The PD tcl/tk GUI has the same
behavior.

Joe
--
 ______________________________
|
| Joseph A. Sarlo
|
| jsarlo at mambo.peabody.jhu.edu
|______________________________


On 29 Mar 2002, jfm3 wrote:

> I worry a lot about this external, as well as about Joe Sarlo's GrIPD.
> Python is not anywhere near a real time language. Run time environments
> with automatic memory deallocation are very tricky to get to work in
> bounded time. I worry that when a moderate to large amount of Python
> code gets loaded, and the program runs for a while, its garbage
> collection and paging behavior will cause timing failures in even simple
> MIDI processing. Am I just being up tight about all music code being
> bounded time, or does anyone else see this as a real issue?
> 
> On Fri, 2002-03-29 at 20:51, Thomas Grill wrote:
> > here is the first release of a simple python script object.
> 
>