Hi list,
Is there any potential problem using [else/blocksize~ ] and setting the switch~ settings of a subpatch?
blocksize~.c tells me that outlet_float is called during the "dsp" method. Will "set" messages to sub-patches with [switch~] during "dsp" interfere with dsp graph generation?
I have a solution (a subpatch named "switchbang") to delay the output by one dsp cycle. [inlet] // bang input | [switch~] [bang~] | [outlet]
But I'm wondering if I'm being overly cautious.
Chuck
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
Gesendet: Donnerstag, 16. Januar 2020 um 16:34 Uhr Von: "Charles Z Henry" czhenry@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] Any problems else/blocksize changing subpatch blocking during dsp?
Hi list,
Is there any potential problem using [else/blocksize~ ] and setting the switch~ settings of a subpatch?
blocksize~.c tells me that outlet_float is called during the "dsp" method. Will "set" messages to sub-patches with [switch~] during "dsp" interfere with dsp graph generation?
I have a solution (a subpatch named "switchbang") to delay the output by one dsp cycle. [inlet] // bang input | [switch~] [bang~] | [outlet]
But I'm wondering if I'm being overly cautious.
Chuck
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi christof.ressi@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
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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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@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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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@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@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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 1/17/20 5:20 AM, Alexandre Torres Porres wrote:
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
is it? your code accesses samplerate and blocksize of a signal (sp[0]->s_n, sp[0]->s_sr). in order to be able to access these signal members, you need an actual signal. so even if it is pointless to actual send some payload in the signal (by connecting some generator to this object), you do need a dummy signal to access its metadata.
gamrds IOhannes
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@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@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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, Jan 16, 2020 at 4:34 PM Alexandre Torres Porres porres@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@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@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, Jan 16, 2020 at 1:03 PM Christof Ressi christof.ressi@gmx.at wrote:
it's certainly not a good idea to (possibly) modify the DSP graph while it's being built.
Or a *great* idea
As I said, the external should use a clock to schedule the message for the next tick.
Here's what seems possible: The canvas "dsp" method gets called on toplevel canvases. It adds all the objects in the canvas with "dsp" methods to an unsorted list. Then, in ugen_done_graph, the main work of setting up the dspcontext struct from block~/switch~ happens. It allocates all the signals, and ugen_doit puts each chain of objects in a queue to have their "dsp" methods run. Then it finally reaches a sub-patch (a canvas object), and its "dsp" method gets called.
The outcome depends on which runs first--the blocksize~ "dsp" method or the sub-patch canvas "dsp" method. Sub-patch blocksizes could still be set, during graph generation, because the block~ parameters aren't even relevant until the sub-patch "dsp" method.
With no signal inlets and no outlets, there's nothing there to force it to come before/after the sub-patch "dsp" method.
If blocksize~ had a signal inlet, you could connect it to a subpatch output and be guaranteed that the sub-patch "dsp" method will be called before the blocksize~ "dsp"
And vice versa (the interesting case): if blocksize~ has a signal outlet connected to some sub-patch inlet, then it's possible to set the sub-patch block~/switch~ parameters during the graph generation, right before they are to be used. But.... I still have questions. Will the block~ "set" method trigger the dsp graph to be rebuilt, at some point when it's already trying to build the graph? What would happen if it did?
Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr Von: "Charles Z Henry" czhenry@gmail.com An: Pd-List pd-list@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
And vice versa (the interesting case): if blocksize~ has a signal outlet connected to some sub-patch inlet, then it's possible to set the sub-patch block~/switch~ parameters during the graph generation, right before they are to be used. But.... I still have questions. Will the block~ "set" method trigger the dsp graph to be rebuilt, at some point when it's already trying to build the graph? What would happen if it did?
This seems like not a problem either. What happens (I predict based on reading) is the current graph gets freed (incomplete as it is), when a sub-patch block/switch object runs its "set" method. It runs "canvas_suspend_dsp" and then "canvas_resume_dsp".
Again not a bug report.... The code was not at all broken with respect to "set" methods. Both orders of sub-patch canvas "dsp" vs blocksize~ "dsp" produce the same result, based on further reading. It's slightly unsettling to output blocksize during "dsp" with the intention of setting subpatch size, but it seems to be efficient and fine to do
-
Alexandre Torres Porres -
Charles Z Henry -
Christof Ressi -
IOhannes m zmölnig