This is definitely an issue, but it is one that already is a problem for PD. The most obvious example is that data is written to a socket to drive the current PD gui. Those calls to write on the socket are not garunteed to complete in bounded time any more than the Python interpreter is (in fact, I would argue that there is more of a chance of the socket blocking than the Python gc interrupting things). I think that this external is likely to work just like PD does now - pretty well for most cases. To get something that works well all of the time is going to require multi-threading and the ability for externals to easily spawn background threads that communicate with the main message passing system asynchrously. There are a lot of Dannenberg papers on these issues - I can get specific references if you want.
Karl
On Fri, 2002-03-29 at 22:34, 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.
-- (jfm3)
Computer Music Department
Peabody Institute of the Johns Hopkins University karlmac@peabody.jhu.edu
mambo.peabody.jhu.edu/~karlmac