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

[Alexandre Torres Porres]

while we're at it, why do I need

class_addmethod(blocksize_class, nullfn, gensym("signal"), 0);

in  blocksize_tilde_setup ?

bang~ doesn't have it, but if I take it out, pd crashes, but I don't think
I need to have this and it's pointless to be able to connect a signal into
this object

cheers

Em sex., 17 de jan. de 2020 às 00:08, Alexandre Torres Porres <
porres at gmail.com> escreveu:

> 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200117/46229687/attachment.html>