I finally discovered the problem. It is not pd or pd-extended at all. It appears that the original implementation of the wiimote object I based l2ork's threaded version on was causing these issues as some of its output was callback driven from the external cwiid library, rather than being "pushed" by the incoming bang signal. I think this makes sense as when those messages are thrown out-of-sync in respect to the patch tree traversal (or whatever method is being used to do this), all kinds of weird things can happen, like seemingly random truncation of messages which becomes more prominent when the message activity increases.
Now, that I redesigned the object so that it only outputs stuff through non-signal outlets when it receives bang (as it should), I've yet to reproduce a problem which would've been otherwise occurring within seconds, but only if I used wiimote button messages to trigger gui events (keyboard events did not cause any problems whatsoever, which seems to speak in favor of the aforesaid explanation).
So, Hans, this perhaps may be the cause of your problems as well--FWIW you may want to check any less common pd objects you may be using in specific patches and see if they allow for out-of-sync outputs that are threaded separately from Pd's signal tree.
BTW, I would also love to hear thoughts from the hardened Pd devs regarding this. I haven't had a chance to read carefully through the external (design documentation which likely covers this), as my objects were mainly alterations of the existing designs.
Speaking of which, I've also implemented a simple alternative version of the phasor~ that outputs bang every time it completes a period (or as close as it gets to this moment based on pd's audio engine buffer which I believe is 64 bytes). Now I am wondering if having a "bang" outputted from a non-signal outlet whose triggering is dictated by the dsp thread may cause similar problems in the long run and whether I should simply stick to vanilla >~ kinds of solutions for this purpose.
Here's the relevant code (which is essentially identical to the built-in phasor with one notable exception towards the bottom):
t_int *disis_phasor_perform(t_int *w) { t_disis_phasor *x = (t_disis_phasor *)(w[1]); t_float *in = (t_float *)(w[2]); t_float *out = (t_float *)(w[3]); int n = (int)(w[4]); double dphase = x->x_phase + UNITBIT32; union disis_phasor_tabfudge tf; int normhipart; float conv = x->x_conv; tf.tf_d = UNITBIT32; normhipart = tf.tf_i[HIOFFSET]; tf.tf_d = dphase;
while (n--) { tf.tf_i[HIOFFSET] = normhipart; dphase += *in++ * conv; *out++ = tf.tf_d - UNITBIT32; tf.tf_d = dphase; } tf.tf_i[HIOFFSET] = normhipart; x->x_phase = tf.tf_d - UNITBIT32; //here comes the bang inside the dsp thread //is this a bad idea? if (x->x_phase_delta > 0.5 && x->x_phase < 0.5) outlet_bang(x->b_out); x->x_phase_delta = x->x_phase; return (w+5); }
Any advice on this one, particularly from the Pd-dev gurus would be most appreciated!
Best wishes,
Ico