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

[Christof Ressi]

> Or a *great* idea

Certainly not. As I've said, it's possible to crash Pd in various ways.

Christof

> Gesendet: Freitag, 17. Januar 2020 um 07:36 Uhr
> Von: "Charles Z Henry" <czhenry at gmail.com>
> An: Pd-List <pd-list at lists.iem.at>
> Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp?
>
> On Thu, Jan 16, 2020 at 1:03 PM Christof Ressi <christof.ressi at gmx.at> wrote:
> >
> > it's certainly not a good idea to (possibly) modify the DSP graph while it's being built.
>
> Or a *great* idea
>
> >As I said, the external should use a clock to schedule the message for the next tick.
>
> Here's what seems possible:
> The canvas "dsp" method gets called on toplevel canvases.  It adds all
> the objects in the canvas with "dsp" methods to an unsorted list.
> Then, in ugen_done_graph, the main work of setting up the dspcontext
> struct from block~/switch~ happens.  It allocates all the signals, and
> ugen_doit puts each chain of objects in a queue to have their "dsp"
> methods run.  Then it finally reaches a sub-patch (a canvas object),
> and its "dsp" method gets called.
>
> The outcome depends on which runs first--the blocksize~ "dsp" method
> or the sub-patch canvas "dsp" method.  Sub-patch blocksizes could
> still be set, during graph generation, because the block~ parameters
> aren't even relevant until the sub-patch "dsp" method.
>
> With no signal inlets and no outlets, there's nothing there to force
> it to come before/after the sub-patch "dsp" method.
>
> If blocksize~ had a signal inlet, you could connect it to a subpatch
> output and be guaranteed that the sub-patch "dsp" method will be
> called before the blocksize~ "dsp"
>
> And vice versa (the interesting case): if blocksize~ has a signal
> outlet connected to some sub-patch inlet, then it's possible to set
> the sub-patch block~/switch~ parameters during the graph generation,
> right before they are to be used.
> But.... I still have questions.  Will the block~ "set" method trigger
> the dsp graph to be rebuilt, at some point when it's already trying to
> build the graph?  What would happen if it did?
>
> > > Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr
> > > Von: "Charles Z Henry" <czhenry at gmail.com>
> > > An: Pd-List <pd-list at lists.iem.at>
> > > Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp?
> > >
> > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> > >
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>