[PD-dev] more information on the gui getting stuck on 0.42.5

[Miller Puckette]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev