Howdy, the "G05.execution.order" example in Pd shows us how delay lines will always delay at least a block of samples, unless you tweak it by using some subpatches and stuff.
Well, even though the example works as described, I was doing some tests and didn't get the same results.
So it is weird that behaves like that in the example, but when I change the patch or make a new patch it just doesn't behave the same way. Meaning that it will not delay to at least a block in size, but less than that without doing the subpatches thing.
See my patch attached.
So what now, huh?
cheers
so, this is really fishy... here's another patch. Don't know what I did, in which order I connected them, but now the delay won't work for less than an audio block (64 samples)
Nevertheless... if I go into edit mode e reinstantiate the [sig~] object, for example, it'll work! Then if I save the file, it'll work fine when I reopen the patch.
So something about the order where the objects are connected make a difference.
I tried it in Extended 0.42 and vanilla 0.46 by the way
waiting for the pd guru masters to shine their wisdom
one way or another, the "G05.execution.order" example needs to be rewritten I guess.
cheers
2015-08-25 20:17 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Howdy, the "G05.execution.order" example in Pd shows us how delay lines will always delay at least a block of samples, unless you tweak it by using some subpatches and stuff.
Well, even though the example works as described, I was doing some tests and didn't get the same results.
So it is weird that behaves like that in the example, but when I change the patch or make a new patch it just doesn't behave the same way. Meaning that it will not delay to at least a block in size, but less than that without doing the subpatches thing.
See my patch attached.
So what now, huh?
cheers
Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear from looking at the patch. Also, if you perform a cut and paste or rename your objects, you risk changing the order.
Thus it is always safest to use the subpatch, as it will force the order, regardless.
same goes with [send~]/[receive~] as I see it, so [throw~]/[catch~] and [tabsend~]/[tabreceive~] must behave the same way...
2015-08-26 0:46 GMT-03:00 i go bananas hard.off@gmail.com:
Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear from looking at the patch. Also, if you perform a cut and paste or rename your objects, you risk changing the order.
Thus it is always safest to use the subpatch, as it will force the order, regardless.
Yes, you can get 'correct' execution order by just adding your objects in the right order.
what is the "right order" then?
2015-08-26 0:46 GMT-03:00 i go bananas hard.off@gmail.com:
Yes, you can get 'correct' execution order by just adding your objects in the right order. But it is unclear from looking at the patch. Also, if you perform a cut and paste or rename your objects, you risk changing the order.
Thus it is always safest to use the subpatch, as it will force the order, regardless.
the delwrite~ must come first (which is exactly what happens when you force the order by putting the delread~ into a subpatch.
i would also guess that send~ must come before recieve~, etc etc. In all cases , you have to write before you can read.
On 2015-08-26 06:25, Alexandre Torres Porres wrote:
Yes, you can get 'correct' execution order by just adding your objects in the right order.
what is the "right order" then?
it's undefined.
(conceptually) it's the very same as using a fan-out without [trigger]: if you are lucky (or know the interna) you can get your patch working fine without ever needing [t]. but you still rely on undefined behaviour; and relying on undefined behaviour is imho a bug.
fgamsdr IOhannes
it's undefined.
But how is it "undefined behaviour"? For trigger, for example, I understand the order of connections will define the order of messages being sent, right? I mean, every time I've tested it, it worked. But is it at some level really "undefined" and might not work?
and what would the internal workings be for this audio connections? It's still unclear to me
thanks
2015-08-26 4:49 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-08-26 06:25, Alexandre Torres Porres wrote:
Yes, you can get 'correct' execution order by just adding your objects in the right order.
what is the "right order" then?
it's undefined.
(conceptually) it's the very same as using a fan-out without [trigger]: if you are lucky (or know the interna) you can get your patch working fine without ever needing [t]. but you still rely on undefined behaviour; and relying on undefined behaviour is imho a bug.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/07/2015 07:16 PM, Alexandre Torres Porres wrote:
it's undefined.
But how is it "undefined behaviour"? For trigger, for example, I understand the order of connections will define the order of messages being sent, right? I mean, every time I've tested it, it worked. But is it at some level really "undefined" and might not work?
well "might not work" is probably the wrong wording here: i think it's more "might not do what you expect".
many uses of signal processing in the Pd world do not require block synchronicity (e.g. when you build a synth, you mostly won't notice if an envelope triggers 64 samples late). that's why you often get away with the undefined behaviour in signal domain.
and what would the internal workings be for this audio connections? It's still unclear to me
the order of execution for signal objects is (with "execute" i mean "calling the DSP perform routine"):
- all inputs of an object must be filled before it can be executed.
this means:
- whichever object A has an outlet~ that is connected to the inlet~ of
an object B, will be executed before B.
- if the above does not resolve into a unique order of execution, then
the object that was created first will be executed first.
#1 is the reason, why order-forcing works #2 is what we call "undefined" (as you cannot see this from staring at the patch). the reason why the creation order becomes amajor factor is that this maps well to the internal data representation when resolving execution order (objects are added to a linked-list; if some objects have the same priority, the new object will be added at the end (of that priority)).
i hope this explains it.
fmdsf IOhannes
It might be a bit misleading to call this behaviour 'undefined'.
As Alexandre points out, control execution is defined by the order the connections appear in the netlist and so have reliable results each time the patch is run.
It's not really the same problem you have in other languages where there is a runtime ambiguity.
And is probably more an issue with the Pd environment UI than the language specification.
Cheers, Joe
On 7 September 2015 at 19:15, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 09/07/2015 08:01 PM, IOhannes m zmölnig wrote:
i hope this explains it.
forgot this.
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
certainly you could call it "untrustworthy" though...cos there's no way of telling creation order from the GUI, and cut and paste or other re-patching is liable to open your patch to changes which would re-order things.
for all intents and purposes, you're best off thinking of it as totally random.
On Tue, Sep 8, 2015 at 6:13 PM, Joe White white.joe4@gmail.com wrote:
It might be a bit misleading to call this behaviour 'undefined'.
As Alexandre points out, control execution is defined by the order the connections appear in the netlist and so have reliable results each time the patch is run.
It's not really the same problem you have in other languages where there is a runtime ambiguity.
And is probably more an issue with the Pd environment UI than the language specification.
Cheers, Joe
On 7 September 2015 at 19:15, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 09/07/2015 08:01 PM, IOhannes m zmölnig wrote:
i hope this explains it.
forgot this.
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-09-08 11:13, Joe White wrote:
It might be a bit misleading to call this behaviour 'undefined'.
why?
As Alexandre points out, control execution is defined by the order the connections appear in the netlist and so have reliable results each time the patch is run.
It's not really the same problem you have in other languages where there is a runtime ambiguity.
that's only because we have a single runtime, that has a certain implementation which results in a given behaviour for an "undefined" one.
this doesn't make it less "undefined" behaviour.
And is probably more an issue with the Pd environment UI than the language specification.
what *is* the Pd language then? i think that the language of Pd and it's UI are non-separable.
gsdfmasdr IOhannes
It might be a bit misleading to call this behaviour 'undefined'.
why?
a) for the reasons pointed out previously b) by virtue of the fact that Alexandre is questioning it (and I would agree with him)
But how is it "undefined behaviour"? For trigger, for example, I understand
the order of connections will define the order of messages being sent, right? I mean, every time I've tested it, it worked. But is it at some level really "undefined" and might not work?
c) https://en.wikipedia.org/wiki/Undefined_behavior d) I'm being pedantic
what *is* the Pd language then?
i think that the language of Pd and it's UI are non-separable.
Agree on some level but there *is *a formal language in the netlist that is predictable, it's just that no one is expected to actually program with it.
certainly you could call it "untrustworthy" though...cos there's no way of
telling creation order from the GUI, and cut and paste or other re-patching is liable to open your patch to changes which would re-order things. for all intents and purposes, you're best off thinking of it as totally random.
Yeah totally which why I think it's a UI issue and not something to be pushed onto the User as a bug in their code.
On a sidenote:
Does cut and paste actually change the connection order? That's really freaky if so.
On 8 September 2015 at 10:27, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-09-08 11:13, Joe White wrote:
It might be a bit misleading to call this behaviour 'undefined'.
why?
As Alexandre points out, control execution is defined by the order the connections appear in the netlist and so have reliable results each time the patch is run.
It's not really the same problem you have in other languages where there
is
a runtime ambiguity.
that's only because we have a single runtime, that has a certain implementation which results in a given behaviour for an "undefined" one.
this doesn't make it less "undefined" behaviour.
And is probably more an issue with the Pd environment UI than the language specification.
what *is* the Pd language then? i think that the language of Pd and it's UI are non-separable.
gsdfmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
not talking about connection order, but rather creation order. If you cut an object, and then paste it, it will jump to the front of the object queue.
Say you created a [delwrite~] / [delread~] pair, in that order; if you cut the [delwrite~] and then pasted it back, then it would come after the [delread~] and your patch's behaviour would change.
Oh yeah of course
On 8 September 2015 at 11:04, i go bananas hard.off@gmail.com wrote:
not talking about connection order, but rather creation order. If you cut an object, and then paste it, it will jump to the front of the object queue.
Say you created a [delwrite~] / [delread~] pair, in that order; if you cut the [delwrite~] and then pasted it back, then it would come after the [delread~] and your patch's behaviour would change.
On 2015-09-08 11:52, Joe White wrote:
It might be a bit misleading to call this behaviour 'undefined'.
why?
a) for the reasons pointed out previously
???
b) by virtue of the fact that Alexandre is questioning it (and I would agree with him)
i was under the impression that his questions are driven by the urge to understand rather than the urge to critique - so i don't see how that would help raising any claims.
"undefined behavior (UB) is the result of executing computer code written in a programming language for which the language specification does not prescribe how that code should be handled."
the main problem we have is that there is no written down formal language specification of Pd (mainly caused by its author refusing to call Pd a "language" at all). with that in mind, you can (pedantically) argue, that there is cannot be any undefined behaviour in Pd at all.
which doesn't help us at all.
d) I'm being pedantic
??
what *is* the Pd language then?
i think that the language of Pd and it's UI are non-separable.
Agree on some level but there *is *a formal language in the netlist that is predictable, it's just that no one is expected to actually program with it.
hmm, yes, but i think that's the wrong conclusion: i think that the netlist description and Pd are two distinct languages. it just happens that the latter is transpiled into the former before being executed (much like "vala" is first transpiled into "C").
so even if one of the languages does not expose an undefined behaviour in our situation, that doesn't mean that the other won't.
On a sidenote:
Does cut and paste actually change the connection order? That's really freaky if so.
dunno what you mean by "connection order". Pd totally ignores the order of connections; what is important is the order of creation of the connected objects. any yes, Cut'n'paste does change the order of object creation (and hence can have an effect on the actual order of execution.
fgmsdr IOhannes
dunno what you mean by "connection order".
The order of the "#X connect" statements in the patch netlist.
Pd totally ignores the order of connections; what is important is the order of creation of the connected objects.
Technically it doesn't. You can remove and re-add an existing connection and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing the object (and connection) and then re-connecting it back up.
On 8 September 2015 at 11:09, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-09-08 11:52, Joe White wrote:
It might be a bit misleading to call this behaviour 'undefined'.
why?
a) for the reasons pointed out previously
???
b) by virtue of the fact that Alexandre is questioning it (and I would agree with him)
i was under the impression that his questions are driven by the urge to understand rather than the urge to critique - so i don't see how that would help raising any claims.
"undefined behavior (UB) is the result of executing computer code written in a programming language for which the language specification does not prescribe how that code should be handled."
the main problem we have is that there is no written down formal language specification of Pd (mainly caused by its author refusing to call Pd a "language" at all). with that in mind, you can (pedantically) argue, that there is cannot be any undefined behaviour in Pd at all.
which doesn't help us at all.
d) I'm being pedantic
??
what *is* the Pd language then?
i think that the language of Pd and it's UI are non-separable.
Agree on some level but there *is *a formal language in the netlist that
is
predictable, it's just that no one is expected to actually program with
it.
hmm, yes, but i think that's the wrong conclusion: i think that the netlist description and Pd are two distinct languages. it just happens that the latter is transpiled into the former before being executed (much like "vala" is first transpiled into "C").
so even if one of the languages does not expose an undefined behaviour in our situation, that doesn't mean that the other won't.
On a sidenote:
Does cut and paste actually change the connection order? That's really freaky if so.
dunno what you mean by "connection order". Pd totally ignores the order of connections; what is important is the order of creation of the connected objects. any yes, Cut'n'paste does change the order of object creation (and hence can have an effect on the actual order of execution.
fgmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-09-08 12:21, Joe White wrote:
Technically it doesn't. You can remove and re-add an existing connection and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing the object (and connection) and then re-connecting it back up.
ah yes, stupid me.
fgmasr IOhannes
wow, this is quite a technical and theoretical discussion, nice.
but, keeping it simple and trying to avoid this nitty gritty completely, all I'm curious about is if I can *rely* on building a patch with order of creation/connection for both data and audio without trigger and subpatches.
and by that, the question is: if i know what I'm doing in the patch in order to force the behaviour I want, and the patch is working in the way that I want because of that, and Ive saved the file and it is is now behaving the way I want every time I open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
thanks
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-08 12:21, Joe White wrote:
Technically it doesn't. You can remove and re-add an existing connection and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing the object (and connection) and then re-connecting it back up.
ah yes, stupid me.
fgmasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Apologies for derailing the thread
Ive saved the file and it is is now behaving the way I want every time I
open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
(As far as I know) you can be certain that a patch will run repeatedly the same way as long as no modifications to the file are made.
The only caveat would be using an object like random, where its number generator state is remembered for the lifetime of the Pd application running your patch. However, if you reopen the whole application it'll be reset.
On 8 September 2015 at 15:05, Alexandre Torres Porres porres@gmail.com wrote:
wow, this is quite a technical and theoretical discussion, nice.
but, keeping it simple and trying to avoid this nitty gritty completely, all I'm curious about is if I can *rely* on building a patch with order of creation/connection for both data and audio without trigger and subpatches.
and by that, the question is: if i know what I'm doing in the patch in order to force the behaviour I want, and the patch is working in the way that I want because of that, and Ive saved the file and it is is now behaving the way I want every time I open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
thanks
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-08 12:21, Joe White wrote:
Technically it doesn't. You can remove and re-add an existing
connection
and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing the object (and connection) and then re-connecting it back up.
ah yes, stupid me.
fgmasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cause if so, as I understant it, it is "defined", but not to get into the technical discussion about programming languages. It's just a synonym to "reliable", and I think it is important to note that, because otherwise you can give the idea to people that it'll be chaotic and all, when it isn't (that happened to me).
cheers
2015-09-08 11:20 GMT-03:00 Joe White white.joe4@gmail.com:
Apologies for derailing the thread
Ive saved the file and it is is now behaving the way I want every time I
open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
(As far as I know) you can be certain that a patch will run repeatedly the same way as long as no modifications to the file are made.
The only caveat would be using an object like random, where its number generator state is remembered for the lifetime of the Pd application running your patch. However, if you reopen the whole application it'll be reset.
On 8 September 2015 at 15:05, Alexandre Torres Porres porres@gmail.com wrote:
wow, this is quite a technical and theoretical discussion, nice.
but, keeping it simple and trying to avoid this nitty gritty completely, all I'm curious about is if I can *rely* on building a patch with order of creation/connection for both data and audio without trigger and subpatches.
and by that, the question is: if i know what I'm doing in the patch in order to force the behaviour I want, and the patch is working in the way that I want because of that, and Ive saved the file and it is is now behaving the way I want every time I open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
thanks
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-08 12:21, Joe White wrote:
Technically it doesn't. You can remove and re-add an existing
connection
and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing
the
object (and connection) and then re-connecting it back up.
ah yes, stupid me.
fgmasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think that was what I trying to point in my original post.
I believe IOhannes is referring to the fact that by looking at the patch it sometimes isn't possible to evaluate the correct order of operations, and therefore is 'undefined'.
On 8 September 2015 at 15:29, Alexandre Torres Porres porres@gmail.com wrote:
cause if so, as I understant it, it is "defined", but not to get into the technical discussion about programming languages. It's just a synonym to "reliable", and I think it is important to note that, because otherwise you can give the idea to people that it'll be chaotic and all, when it isn't (that happened to me).
cheers
2015-09-08 11:20 GMT-03:00 Joe White white.joe4@gmail.com:
Apologies for derailing the thread
Ive saved the file and it is is now behaving the way I want every time I
open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
(As far as I know) you can be certain that a patch will run repeatedly the same way as long as no modifications to the file are made.
The only caveat would be using an object like random, where its number generator state is remembered for the lifetime of the Pd application running your patch. However, if you reopen the whole application it'll be reset.
On 8 September 2015 at 15:05, Alexandre Torres Porres porres@gmail.com wrote:
wow, this is quite a technical and theoretical discussion, nice.
but, keeping it simple and trying to avoid this nitty gritty completely, all I'm curious about is if I can *rely* on building a patch with order of creation/connection for both data and audio without trigger and subpatches.
and by that, the question is: if i know what I'm doing in the patch in order to force the behaviour I want, and the patch is working in the way that I want because of that, and Ive saved the file and it is is now behaving the way I want every time I open it, can I *rely* that it will always open and work like that if no one edits the file changing the order of connections and everything?
thanks
2015-09-08 9:15 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-08 12:21, Joe White wrote:
Technically it doesn't. You can remove and re-add an existing
connection
and it could change the order.
Re-instantiating objects does the same, I assume the GUI is removing
the
object (and connection) and then re-connecting it back up.
ah yes, stupid me.
fgmasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-09-08 16:29, Alexandre Torres Porres wrote:
cause if so, as I understant it, it is "defined", but not to get into the technical discussion about programming languages. It's just a synonym to "reliable", and I think it is important to note that, because otherwise you can give the idea to people that it'll be chaotic and all, when it isn't (that happened to me).
it won't be chaotic. it also won't change - at least it won't change if you are using the same Pd-runtime.
i would put it that way: Pd currently has a way to explicitely enforce the order of execution of a DSP graph. this behaviour is documented *explicitely*, eg. in G05.execution.order.pd if your patch needs to rely on a certain execution order, you should use the documented way to enforce this execution order.
Pd has a long history of not breaking patches. this is one of its biggest strengths (and one of it's weaknesses, as it prevents fast addition of new features). so if you are using an undocumented way¹ of ensuring that objects are scheduled in order (e.g. by connecting A before B in order to have Pd schedule C before D), chances are high that your patch will still work next year. and the year after.
however, if a major bug was discovered and the only (sane) way to fix this bug would involve invalidating your assumption (that connecting A before B will schedule C before D), then i would argue that breking the current behaviour is *not* a regression (as long as the explicit way to enforce order still works). and then your patch will stop working (when used with Pd-0.63. and when you come complaining i will tell you that you should not have relied on undefined behaviour in the first place.
gfmasdr IOhannes
¹ and no: the fact that G05.execution.order exploits the undocumented behaviour to guarantee that the "wrong" flanger is indeed "wrong", does not count as documentation.
I just wanna know how it works... I'm not really making a case that I'd like to do it, I just want to understand the behaviour of Pd.
but it's funny how everyone emphatically insists to advice it shouldn't be done and stuff. Well, to calm everyone down, I'll come out and say I'll never do such a thing :)
thanks folks
2015-09-09 9:17 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-08 16:29, Alexandre Torres Porres wrote:
cause if so, as I understant it, it is "defined", but not to get into the technical discussion about programming languages. It's just a synonym to "reliable", and I think it is important to note that, because otherwise
you
can give the idea to people that it'll be chaotic and all, when it isn't (that happened to me).
it won't be chaotic. it also won't change - at least it won't change if you are using the same Pd-runtime.
i would put it that way: Pd currently has a way to explicitely enforce the order of execution of a DSP graph. this behaviour is documented *explicitely*, eg. in G05.execution.order.pd if your patch needs to rely on a certain execution order, you should use the documented way to enforce this execution order.
Pd has a long history of not breaking patches. this is one of its biggest strengths (and one of it's weaknesses, as it prevents fast addition of new features). so if you are using an undocumented way¹ of ensuring that objects are scheduled in order (e.g. by connecting A before B in order to have Pd schedule C before D), chances are high that your patch will still work next year. and the year after.
however, if a major bug was discovered and the only (sane) way to fix this bug would involve invalidating your assumption (that connecting A before B will schedule C before D), then i would argue that breking the current behaviour is *not* a regression (as long as the explicit way to enforce order still works). and then your patch will stop working (when used with Pd-0.63. and when you come complaining i will tell you that you should not have relied on undefined behaviour in the first place.
gfmasdr IOhannes
¹ and no: the fact that G05.execution.order exploits the undocumented behaviour to guarantee that the "wrong" flanger is indeed "wrong", does not count as documentation.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/09/2015 03:26 PM, Alexandre Torres Porres wrote:
I just wanna know how it works... I'm not really making a case that I'd like to do it, I just want to understand the behaviour of Pd.
which is fair enough. (and which is why i actually tried to explain it...in the end).
but it's funny how everyone emphatically insists
everyone? i thought it was only me...
to advice it shouldn't be done and stuff. Well, to calm everyone down, I'll come out and say I'll never do such a thing :)
the reason why i'm so hysterical about "undefined behaviour", is that once this information is archived all over the net, it might give people ideas about what they can do. so even if you ask the question from a learning pov, the next reader will just extract the information "connecting A before B will schedule C before D" and use it (and come back to ask why it doesn't work anymore, after they forgot those tricks altogether and cleaned up their patch with some copy'n'paste that broke everything).
gfmdsar IOhannes who always wants the last word...
Alexandre,
Looking at your original question, G05.execution.order says the following:
"If you're writing to and reading from a delay line, you have to get the write sorted before the read or else you'll never get less than a block's delay."
As the others have pointed out, there are basically two ways of "getting the write sorted before the read [in the DSP chain]":
- by accident, or in a way that can't be gleaned from looking at the patch
in Pd (you'd have to take it into a text editor to see that the write was created before the read). 2) on purpose, using subpatches, which is guaranteed both to work and to be inferred from the structure of the patch.
So it's not that the idiom on the left will ALWAYS be off by a block in every instance, but that it may or may not be depending on the unreadable contingencies of how the patch was created. You can rely on this for your own stuff, but if you wanted to send it to someone, they wouldn't be able to tell those contingencies by looking at the patch, so to that user, the behavior is "undefined" in the same way that failing to use a trigger makes message execution order "undefined." The behavior is deterministic under the hood, but your user can't be expected to look under the hood. The G05.execution.order is specifically tailored to show that it can be off by a block, but there's no way to know it just by looking; it's possible a better approach would have been to have shown another one that looked exactly the same but had the other behavior, and then finally the way to make it explicit using subpatches.
====================================================
If you look at the first test patch you attached, you can tell a few things about execution precedence based on patch cords.
- [noise~] runs before [delwrite~], [pd delay-writer], [pd delay-reader],
both [+~] objects, and the [output~] abstractions, because for each of those the [noise~] feeds into it or feeds into something that feeds into it.
- [noise~] may or may not run before [vd~], and likewise [delwrite~] may
run before or after [vd~]. If [delwrite~] runs after [vd~] (because it happened to have been created after), then setting [vd~]'s delay to 0 has it reading what [delwrite~] wrote on the previous block.
- [pd delay-writer] is guaranteed to run before [pd delay-reader] because
of the patch connection between them. If you severed that connection, and then cut and pasted [pd delay-reader], it would now run before [pd delay-writer], until you reconnected the cord. You can try this and hear it change when you reconnect and disconnect the connection.
There are some cases when you actually need a block delay, and you can specify that behavior in the same way.
Yes, send~/receive~ and throw~/catch~ can be off by a block as well, but you can force them to run in sync, again using subpatches (unless it creates a DSP loop).
Matt
On Tue, Aug 25, 2015 at 7:17 PM, Alexandre Torres Porres porres@gmail.com wrote:
Howdy, the "G05.execution.order" example in Pd shows us how delay lines will always delay at least a block of samples, unless you tweak it by using some subpatches and stuff.
Well, even though the example works as described, I was doing some tests and didn't get the same results.
So it is weird that behaves like that in the example, but when I change the patch or make a new patch it just doesn't behave the same way. Meaning that it will not delay to at least a block in size, but less than that without doing the subpatches thing.
See my patch attached.
So what now, huh?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Actually even for one's own patches, Pd is supposed to go into read-only mode when you depend on creation order for deterministic behavior. That is-- it shouldn't let you save the patch after that. But there's a long-standing unfixable bug that lets you do it anyway. I make this joke with some sadness because data structure drawing commands depend on creation order for the drawings' z-order. And I can't think of a better way to do it. (One could use wires to chain them in order but that brings its own problems.)
-Jonathan
On Saturday, September 12, 2015 1:03 AM, Matt Barber <brbrofsvl@gmail.com> wrote:
Alexandre, Looking at your original question, G05.execution.order says the following: "If you're writing to and reading from a delay line, you have to get the write sorted before the read or else you'll never get less than a block's delay." As the others have pointed out, there are basically two ways of "getting the write sorted before the read [in the DSP chain]":1) by accident, or in a way that can't be gleaned from looking at the patch in Pd (you'd have to take it into a text editor to see that the write was created before the read).2) on purpose, using subpatches, which is guaranteed both to work and to be inferred from the structure of the patch. So it's not that the idiom on the left will ALWAYS be off by a block in every instance, but that it may or may not be depending on the unreadable contingencies of how the patch was created. You can rely on this for your own stuff, but if you wanted to send it to someone, they wouldn't be able to tell those contingencies by looking at the patch, so to that user, the behavior is "undefined" in the same way that failing to use a trigger makes message execution order "undefined." The behavior is deterministic under the hood, but your user can't be expected to look under the hood. The G05.execution.order is specifically tailored to show that it can be off by a block, but there's no way to know it just by looking; it's possible a better approach would have been to have shown another one that looked exactly the same but had the other behavior, and then finally the way to make it explicit using subpatches. ==================================================== If you look at the first test patch you attached, you can tell a few things about execution precedence based on patch cords.1) [noise~] runs before [delwrite~], [pd delay-writer], [pd delay-reader], both [+~] objects, and the [output~] abstractions, because for each of those the [noise~] feeds into it or feeds into something that feeds into it. 2) [noise~] may or may not run before [vd~], and likewise [delwrite~] may run before or after [vd~]. If [delwrite~] runs after [vd~] (because it happened to have been created after), then setting [vd~]'s delay to 0 has it reading what [delwrite~] wrote on the previous block. 3) [pd delay-writer] is guaranteed to run before [pd delay-reader] because of the patch connection between them. If you severed that connection, and then cut and pasted [pd delay-reader], it would now run before [pd delay-writer], until you reconnected the cord. You can try this and hear it change when you reconnect and disconnect the connection.
There are some cases when you actually need a block delay, and you can specify that behavior in the same way. Yes, send~/receive~ and throw~/catch~ can be off by a block as well, but you can force them to run in sync, again using subpatches (unless it creates a DSP loop). Matt
On Tue, Aug 25, 2015 at 7:17 PM, Alexandre Torres Porres porres@gmail.com wrote:
Howdy, the "G05.execution.order" example in Pd shows us how delay lines will always delay at least a block of samples, unless you tweak it by using some subpatches and stuff. Well, even though the example works as described, I was doing some tests and didn't get the same results. So it is weird that behaves like that in the example, but when I change the patch or make a new patch it just doesn't behave the same way. Meaning that it will not delay to at least a block in size, but less than that without doing the subpatches thing. See my patch attached. So what now, huh? cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
i go bananas -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Joe White -
Jonathan Wilkes -
Matt Barber