it's certainly not a good idea to (possibly) modify the DSP graph while it's 
being built. As I said, the external should use a clock to schedule the message 
for the next tick.

> Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr
> Von: "Charles Z Henry" <[email protected]>
> An: Pd-List <[email protected]>
> Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking 
> during dsp?
>
> 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
>



_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to