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

[Charles Z Henry]

On Thu, Jan 16, 2020 at 4:34 PM Alexandre Torres Porres
<porres at gmail.com> wrote:
>
> hey folks, what exactly do I need to do then?
>
> can you open an issue on https://github.com/porres/pd-else/issues?

It's a choice--depending on what your intended behavior is, you might
go one way or another with it

I had just observed that I could use "blocksize~" with "switch~" for a
patch I'm writing.  I wanted to have a subpatch always run with 2x its
parent blocksize and overlap 2.  And with a [switch~]/[blocksize~]
pair, I can very easily do that.  I can set the blocksize with a
single parameter and it sets the proper mode for the sub-patches, or I
can just make an instance of it (with no arguments) in an existing
reblocked parent and have it inherit its blocksize.  It works exactly
as I want.

It's not a bug---nothing's broken as far as I can tell.  But I think
there is indeterminacy as is.   I wasn't sure, so I just hedged by
bets by delaying the messages. got the job done.  Then I came back
around to ask the question what it might do and what might break if a
patch actually sent messages to a sub-patch

So, I guess the thing to do (if you're interested) is add the signal
inlets/outlets to blocksize~ so you can specify the order of the "dsp"
methods.  Then, you could reliably investigate what happens when you
start using the blocksize to change patch behavior while the graph is
being built

If you're not *so* interested in figuring out how to break Pd, you
might just add the delay code.  It at least resolves the determinacy
issue and prevents users from stumbling into errors

> Em qui., 16 de jan. de 2020 às 16:08, Christof Ressi <christof.ressi at gmx.at> escreveu:
>>
>> 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" <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