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.
| | Joseph A. Sarlo | | jsarlo@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.