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 christof.ressi@gmx.at 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" czhenry@gmail.com An: Pd-List pd-list@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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list