On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi <[email protected]> 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
