I'm trying to increment two sets of numbers in a loop. One set comes out in the correct order; the other comes out in the reverse order. How can I make this work correctly? I've attached a simplified patch that demonstrates the problem. It should print
0 0
1 1
2 2
3 3
4 4
Instead it prints
0 4
1 3
2 2
3 1
4 0

loop_test.pd

1. Do not split the control flow without [trigger]
2. Why don't you use [until] ?

@FFW I had the control flow correct in my example. Adding [trigger] didn't fix the problem. Here's my example with [trigger]. The numbers incremented in the [i] object still come out in the wrong order. It appears that they are coming out in LIFO order when they should be coming out in FIFO order.

loop_test.pd

This is your triggerized patch:

You can see the right branch is triggered before the top-most [t f f] feeds the [pack] so the numbers are all generated by the loop before they was printed.
EDIT: you stack computation branch and they are released deepest to shallowest so numbers are reverted.

@FFW said:

EDIT: you stack computation branch and they are released deepest to shallowest so numbers are reverted.

I don't understand your comment. Why aren't the numbers coming out in the order in which they were computed? This seems like a bug to me. Is this behavior documented?

@jamcultur It's not a bug -- it's normal behavior.

It's documented in the html manual: https://msp.ucsd.edu/Pd_documentation/resources/chapter2.htm#s2.4.2

2.4.2. Depth first message passing
Whenever a message is triggered in Pd, the receiver may then send out further messages in turn, and the receivers of those messages can send yet others. So each message sets off a tree of subsequent messages. This tree is executed in depth first fashion.

"Depth first" means that, when a value comes out of an object's outlet, that branch of the tree must continue all the way to its end before the same outlet can go down a different branch, or before the same object can send data out of a different outlet.

Take a simpler example:

When the random number goes down the [* 2] branch, it must continue down to the [print secondValueCalculated] before it can advance down the [print firstValueCalculated] branch. The whole [* 2] branch must 100% complete.

Humans might look at this patch and think, "Well, the 'print first' branch is simpler, so, intuitively it should be done first." Computers don't think like that.

In code (I'll use SC), it would look like:

(
~func1 = {
    var number = 10.rand;
    ~func2.value(number);
    "first value = %\n".postf(number);
};

~func2 = { |number|
    var result = number * 2;
    "second value = %\n".postf(result);
    result
};

~func1.value;
)

->

second value = 14
first value = 7

~func1 specifies to do ~func2 first, then print. The Pd patch is the same.

I wish Pd's documentation called more attention to looping formulas that Just Work. Users often end up just trying to figure it out for themselves and getting tied in knots.

A for loop goes like this: for(i = 0; i < count; i++) { loop body }

That is, in C, there's a standardized way to write a counting loop -- following the formula avoids confusion. In Pd, there does exist (what should be) a standardized way to write a counting loop, and just like in C, following the formula avoids confusion -- but the formula isn't well enough known, and tricky for users to discover.

hjh