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
_______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
