More information on this:
I've been playing with Miller's experimental version for Intel OS X (see http://crca.ucsd.edu/~msp/Software/pd-imac-test.mac.tar.gz ) and for the most part, it works great.
[...]
Typing on the computer keyboard (e.g. to enter something in a number box) after focus has just transferred to PD, makes a crunch or pop in the sound right at the moment of the first key press. Subsequent key presses do not interfere with the sound, until focus is switched to another app (or maybe even another PD window -- I can't reproduce this very consistently) and then is returned to PD.
More exacting testing shows that the glitch can be consistently reproduced using the simplest audio patch, [osc~ 400] - [dac~] or even the Media Menu -> Test audio app.
Window focus has nothing to do with it: it is related to time. If a key on the computer keyboard hasn't been pressed for n seconds (n equals about 10 on my system), the next key press causes a significant audio glitch. Further key presses, if made within n seconds, don't cause a glitch. *After any pause of n seconds or more, the next key press causes the glitch.* Also, there need not be any key-input controls on the PD screen; as I said, the simplest audio patch can reproduce this.
I've tried different latency settings and this has had no effect.
The -rt startup flag makes no difference. Completely disabling Dashboard, and effectively disabling Spotlight, makes no difference.
This seems like some bad interaction between the OS key-handling and PD.
I would really appreciate it if: a) someone on PPC OS X could see whether this happens to them. b) someone else running the experimental Intel version of PD (anyone?) could try to replicate this.
Also, I'd appreciate some noob-advice on whether I should I file a bug report on this.
Phil Stone pkstone, ucdavis