# [PD] Re: Is this supposed to happen?

Frank Barknecht fbar at footils.org
Wed May 3 20:57:40 CEST 2006

```Hallo,
dafydd hughes hat gesagt: // dafydd hughes wrote:

> On 5/3/06, dafydd hughes <dafydd at 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

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

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__

```