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

Ivica Ico Bukvic ico at vt.edu
Thu Mar 18 02:39:44 CET 2010


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







More information about the Pd-dev mailing list