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