[PD] Any problems else/blocksize changing subpatch blocking during dsp?

Charles Z Henry czhenry at gmail.com
Thu Jan 16 19:07:53 CET 2020


On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi <christof.ressi at gmx.at> wrote:
>
> I also think that messaging an outlet in the "dsp" method is not a good idea and it's better to use a clock with delay 0. The user might take the output of [blocksize~] and accidentally do something which interferes with DSP graph generation, e.g. by resizing an array, creating/deleting objects, etc.
>
> Christof

Yes it *could*, but I'm unclear on the timing.  I've read and
consulted the d_ugen.c code recently but .  The block parameters are
derived from block/switch and coded into the dspcontext struct which
gets generated for each canvas.  The parameters have to be known
before "dsp" gets called in the current canvas (which would trigger
the "blocksize~" output), but is the sub-patch dspcontext already
built?  I'll try to follow up later today and try to answer it

That ambiguity could be resolved by looking at the "bang~" code.  I
just think it's an interesting question what is possible to happen as
it is currently written

bang~ sends properly timed messages by using:
t_clock *x_clock;  //in the data structure

x->x_clock = clock_new(x, (t_method)bang_tilde_tick); // in the "new" method

static void bang_tilde_tick(t_bang *x)  // added "tick" method
{ outlet_bang(x->x_obj.ob_outlet); }

and
clock_delay(x->x_clock, 0);  // in the "perform" routine

Chuck





More information about the Pd-list mailing list