<div dir="ltr">while we're at it, why do I need<div><br></div><div><div>
<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:12px;line-height:normal;font-family:Menlo;color:rgb(93,108,121)">class_addmethod(blocksize_class, nullfn, gensym("signal"), 0);</p><div><br></div><div>in <span style="color:rgb(15,104,160);font-family:Menlo;font-size:12px">blocksize_tilde_setup </span>?</div><div><br></div><div>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</div><div><br></div><div>cheers</div>
</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 17 de jan. de 2020 às 00:08, Alexandre Torres Porres <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">well, I just updated the code, see if that's what you're looking for ;) <div><br></div><div><a href="https://github.com/porres/pd-else/blob/master/Classes/Source/blocksize~.c" target="_blank">https://github.com/porres/pd-else/blob/master/Classes/Source/blocksize~.c</a><br></div><div><br></div><div>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)</div><div><br></div><div>cheers</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 16 de jan. de 2020 às 19:33, Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">hey folks, what exactly do I need to do then? <div><br></div><div>can you open an issue on <a href="https://github.com/porres/pd-else/issues" target="_blank">https://github.com/porres/pd-else/issues</a>?<br><div><br></div><div>thanks</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 16 de jan. de 2020 às 16:08, Christof Ressi <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
> Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr<br>
> Von: "Charles Z Henry" <<a href="mailto:czhenry@gmail.com" target="_blank">czhenry@gmail.com</a>><br>
> An: Pd-List <<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>><br>
> Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp?<br>
><br>
> On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi <<a href="mailto:christof.ressi@gmx.at" target="_blank">christof.ressi@gmx.at</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
> > Christof<br>
><br>
> Yes it *could*, but I'm unclear on the timing. I've read and<br>
> consulted the d_ugen.c code recently but . The block parameters are<br>
> derived from block/switch and coded into the dspcontext struct which<br>
> gets generated for each canvas. The parameters have to be known<br>
> before "dsp" gets called in the current canvas (which would trigger<br>
> the "blocksize~" output), but is the sub-patch dspcontext already<br>
> built? I'll try to follow up later today and try to answer it<br>
><br>
> That ambiguity could be resolved by looking at the "bang~" code. I<br>
> just think it's an interesting question what is possible to happen as<br>
> it is currently written<br>
><br>
> bang~ sends properly timed messages by using:<br>
> t_clock *x_clock; //in the data structure<br>
><br>
> x->x_clock = clock_new(x, (t_method)bang_tilde_tick); // in the "new" method<br>
><br>
> static void bang_tilde_tick(t_bang *x) // added "tick" method<br>
> { outlet_bang(x->x_obj.ob_outlet); }<br>
><br>
> and<br>
> clock_delay(x->x_clock, 0); // in the "perform" routine<br>
><br>
> Chuck<br>
><br>
><br>
><br>
> _______________________________________________<br>
> <a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>