Hi Ivo - It's unsafe to issue messages from inside a DSP routine, because the message could eventually cause tables to relocate or even a rebuild of the DSP chain. The safe thing is to schedule the message using clock_delay().
examples are snapshot~ and (more complicatedly) fiddle~ and bonk~. cheers Miller On Wed, Mar 17, 2010 at 09:39:44PM -0400, Ivica Ico Bukvic wrote: > 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 > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev