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

[Charles Z Henry]

That looks like a safe choice for most users.  I would expect that
will save you some debugging down the line and do all the same things
you intended in the first place

And knowing how it works will save me from over-patching around it to
feel safer using it

On Thu, Jan 16, 2020 at 9:08 PM Alexandre Torres Porres
<porres at gmail.com> wrote:
>
> well, I just updated the code, see if that's what you're looking for ;)
>
> https://github.com/porres/pd-else/blob/master/Classes/Source/blocksize~.c
>
> I got tons of changes ready to go for the next update of the ELSE library, but now I need to wait for 0.51 to come out as I've already made several changes that rely on the new functionality of inlet~ (plus other things)
>
> cheers
>
> Em qui., 16 de jan. de 2020 às 19:33, Alexandre Torres Porres <porres at gmail.com> escreveu:
>>
>> hey folks, what exactly do I need to do then?
>>
>> can you open an issue on https://github.com/porres/pd-else/issues?
>>
>> thanks
>>
>> 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