[PD] [announce] py 0.0.1 python script object

[Karl MacMillan]

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)
-- 
---------------------
Karl W. MacMillan                                 
Computer Music Department                        
Peabody Institute of the Johns Hopkins University
karlmac at peabody.jhu.edu                         
mambo.peabody.jhu.edu/~karlmac