Just because it doesn't crash in your specific use case doesn't mean it isn't dangerous...
> At least, for my usage case, having a subpatch fixed to overlap 2 of > the parent, I can't crash it either. I mean, I really thrashed it. > It takes a lot of time when it's allocating signals up to 2^22---but > did not crash, resumed. I put the block size on a power of 2 > quantized vertical slider and slung it around. There's not much > latency in changing them in the low blocksizes up to 131,072. Not > bad. > > > > On Fri, Jan 17, 2020 at 3:54 AM Christof Ressi <[email protected]> wrote: > > > > > 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" <[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 1:03 PM Christof Ressi <[email protected]> > > > 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" <[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 > > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
