I have been using Python directly as the glue language in a DSP environment for some time now (as well as using Joe's GriPD) and have had no noticeable timing issues. I do, however, use Python 2.0 which does not include a garbage collector, only reference counting, which IMHO is more predictable. However, Python is designed such that as long as you don't do anything wacky with "pointers" such as cyclical structures, the garbage collector should never even kick in for a noticeable amount of time.
In general, I think it's more useful to try these kinds of things IN CONTEXT before worrying about their apparent limitations, because of the advantages of moving to such a flexible system can be pretty great.
On Fri, 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.