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.
<br><br>Best,<br>Eric<br><br><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br><br>On Dec 5, 2006, at 10:13 PM, Mathieu Bouchard wrote:
<br><br>> On Wed, 6 Dec 2006, Thomas Grill wrote:<br>><br>>> currently there's no low-priority messaging in Miller's pd<br>>> version, but there is in the devel branch. It's one of the<br>>> features that have been there for some time and i'm trying to
<br>>> provide a patch for Miller, so that it can make it into vanilla PD<br>>> some time in the future. Hopefully the auto-discard mechanism of<br>>> the patch tracker will blow up before that time. Don't expect the
<br>>> feature to be available soon.<br>><br>> So, how does one use that feature?<br>><br>> Is it that all the audio is high-priority and all the non-audio is<br>> low-priority?<br><br>Isn't that basically the way it is now? Correct me if I am wrong,
<br>but isn't audio data processed first in each cycle, then message data?<br><br>FYI: Max since 4.3 (I believe) has two audio threads, a high priority<br>and a low priority. "qelems" and the defer() functions give you
<br>access to the low priority thread in externals. Another detail of<br>not is that the threads are cooperative, not pre-emptive. If a give<br>process doesn't defer(), then it won't give up that thread until its<br>done processing.
<br><br>.hc<br><br></blockquote></div><br>