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 < [email protected]> 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 < > [email protected]> 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" <[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
