Thank you Thomas, hc and others for helpful feedback. The function I'm deferring is doing asynchronous DSP, not messaging. Essentially a barrage of intensive DSP thrown at the contents of a buffer (array in Pd land) that will hopefully be done in time to be played back in the main perform loop. Actually a lot of it is working on Pd now, but there are a few functions that do reliably crash Pd, even though they're not CPU-expensive. Quite possibly some memory indiscretion. I'll report back on any further findings.
Best, Eric
On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
On Wed, 6 Dec 2006, Thomas Grill wrote:
currently there's no low-priority messaging in Miller's pd version, but there is in the devel branch. It's one of the features that have been there for some time and i'm trying to provide a patch for Miller, so that it can make it into vanilla PD some time in the future. Hopefully the auto-discard mechanism of the patch tracker will blow up before that time. Don't expect the feature to be available soon.
So, how does one use that feature?
Is it that all the audio is high-priority and all the non-audio is low-priority?
Isn't that basically the way it is now? Correct me if I am wrong, but isn't audio data processed first in each cycle, then message data?
FYI: Max since 4.3 (I believe) has two audio threads, a high priority and a low priority. "qelems" and the defer() functions give you access to the low priority thread in externals. Another detail of not is that the threads are cooperative, not pre-emptive. If a give process doesn't defer(), then it won't give up that thread until its done processing.
.hc