Hi folks
Just wondering what's going on here...
This patch is supposed to count from 0 to 9 and stop before 10. Somehow, it seems to be doing this backwards, or as far as I can tell, counting then outputting the numbers backwards. A short delay between iterations solves the problem.
I'm a bit puzzled. Am I missing something obvious? Any thoughts?
cheers dafydd
-- www.sideshowmedia.ca
Ouch - sorry - forgot to attach the patch...
On 5/3/06, dafydd hughes dafydd@sideshowmedia.ca wrote:
Hi folks
Just wondering what's going on here...
This patch is supposed to count from 0 to 9 and stop before 10. Somehow, it seems to be doing this backwards, or as far as I can tell, counting then outputting the numbers backwards. A short delay between iterations solves the problem.
I'm a bit puzzled. Am I missing something obvious? Any thoughts?
cheers dafydd
-- www.sideshowmedia.ca
-- www.sideshowmedia.ca
Hallo, dafydd hughes hat gesagt: // dafydd hughes wrote:
On 5/3/06, dafydd hughes dafydd@sideshowmedia.ca wrote:
Just wondering what's going on here...
This patch is supposed to count from 0 to 9 and stop before 10. Somehow, it seems to be doing this backwards, or as far as I can tell, counting then outputting the numbers backwards. A short delay between iterations solves the problem.
I'm a bit puzzled. Am I missing something obvious? Any thoughts?
It's actually a funny little problem. Cyrille gave you a solution, another one would be to use [until] triggered by a float to bang the counter construct just as many times as you want. I prefer to build the "count to some value"-counters using [until].
However you still might be curious why your version did count down instead of up? If yes, read on.
It has to do with the way Pd executes a tree in a patch. There is a little example in the HTML-manual in chapter: "2.3.2. depth first message passing" about this.
The example is four messages:
[A(
/
|
|
[B( [C(
|
[D(
the question is, in which order they fire. Answer quoted:
the order of arrival of messages is either A-B-C-D or A-C-D-B. The "C" message is not done until the "D" one is also, and the "A" is not done until all four are. It is indeterminate which of "B" or "C" is done first;
Now in your counter, you have a loopback connection from the spigot through the bang to the float object, that sent a message to the spigot in the first place. In this case the float object is "not done" until something breaks the loop. So basically Pd's message order makes the whole construct run one full loop until the spigot gets closed, and only then the messages that were stored in the meantime will get printed "from bottom to top", that is, in reverse order. A [del] is one way to fix such situations, you've seen better ways as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank and Cyrille, thanks for your replies. As much time as I spend with my head inside pd, (which is a lot, my wife tells me...) I stilll find myself regularly stumped, often by pd's idiosyncracies, but more often by basic logical and programming principles that I'm still coming to understand. With the folks on this list and their generosity with knowledge, I feel like I'm in good hands.
I should mention that the original idea was to figure out how to break a loop with a bang - I just wanted to read sound file names using textfile and stop at the end. For some reason it seems more difficult in pd than in other languages. Ah well. More learnin' to do.
cheers dafydd
On 5/3/06, Frank Barknecht fbar@footils.org wrote:
Hallo, dafydd hughes hat gesagt: // dafydd hughes wrote:
On 5/3/06, dafydd hughes dafydd@sideshowmedia.ca wrote:
Just wondering what's going on here...
This patch is supposed to count from 0 to 9 and stop before 10. Somehow, it seems to be doing this backwards, or as far as I can tell, counting then outputting the numbers backwards. A short delay between iterations solves the problem.
I'm a bit puzzled. Am I missing something obvious? Any thoughts?
It's actually a funny little problem. Cyrille gave you a solution, another one would be to use [until] triggered by a float to bang the counter construct just as many times as you want. I prefer to build the "count to some value"-counters using [until].
However you still might be curious why your version did count down instead of up? If yes, read on.
It has to do with the way Pd executes a tree in a patch. There is a little example in the HTML-manual in chapter: "2.3.2. depth first message passing" about this.
The example is four messages:
[A( /
|
|
[B( [C( | [D(the question is, in which order they fire. Answer quoted:
the order of arrival of messages is either A-B-C-D or A-C-D-B. The "C" message is not done until the "D" one is also, and the "A" is not done until all four are. It is indeterminate which of "B" or "C" is done first;
Now in your counter, you have a loopback connection from the spigot through the bang to the float object, that sent a message to the spigot in the first place. In this case the float object is "not done" until something breaks the loop. So basically Pd's message order makes the whole construct run one full loop until the spigot gets closed, and only then the messages that were stored in the meantime will get printed "from bottom to top", that is, in reverse order. A [del] is one way to fix such situations, you've seen better ways as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.sideshowmedia.ca
-
dafydd hughes -
Frank Barknecht