I am here interested to work for abstractions, starting with this one

which replaces the center top incrementation process.

This abstraction - called "+=1" - looks fine : after one bang, the abstraction outputs the value 1.

But the calling patch doesn't output the value 1 as shown here :

I don't understand that the "+=1" abstracted patch outputs 1, and that this value "1" is not pushed down to the "product" box to make the 1 * 1 operation : who can help discover the error ?

I think there's some stuff in the documentation too, you just need to make sure the cold inlets get their numbers before the hot inlets

But this doesn't give my any clue yet about the example :

The bang initiated in "A" acts the same as in the patch with no abstraction - that is, :
- As it is a bang to the b1 Hot input => the 0 value stored in b1 is pushed to the Hot input of b2,
making the + operation effective to produce the value 1 on b2 output -which is b output in the calling patch.

      - We check for this value as a number box in b output.

So, that does mean - along the cord b-c - that the value 1 SHOULD be there at the Cold input of the mult box in C, while at the same moment a value 1 has been sent to the Hot input of the mult box via A, B-Hot input-B-output, C-Hot input..

But it looks like the value 1 at the output of Counter box has become 0 at the other end of cord

There is one more important concept to grasp here: when several patch cords are coming out of a same outlet, the order in which the data will flow is in accordance to their creation order (that is, the [bng] marked as A will send three bangs and the order in which they will arrive in Maxcount, computeur and B depends on how you created your patch).

To rely on this is very confusing and debugging can be very tricky. To solve this issue, always use an object named [trigger], or simply [t]. Trigger will take a single input and will send them out in a specific order (from the rightmost outlet to the lefmost outlet). Example:

[bng]
|
[trigger b b b]
|      |      |
[zzz(  [bar(  [foo(
|      |      |
+------+------+
|
[print]

If you'd construct the patch above and then look on your pd window, you would see that it printed the following messages in order:

foo
bar
zzz

I hope this helps. Take care,
Gilberto

Thanks for sharing.

Take care and good luck,
Gilberto

In fact, 3 of the 6 connection alternatives between the 3 branches from the initial bang can be a solution - I made them all like a beast

These 3 wrong alternatives are those which execute left branch before the middle one - as a bit of thinking might have assert.

And it is now clear to me that the trigger object helps by visually looking at the order of execution which has been graphically implemented - and the incremental abstraction exercise now works.

So many thanks to all of you ( when I was so reluctant to grasp this bit of intelligence..., at last ) !
I can go on for abstractions.

Just a small correction: a [trigger] is much more than a simple visualization aid for the order of operations; Consider this:

The first trigger will output a float from the rightmost outlet, but it will output a bang (!) from the leftmost outlet. That is, there is no numbers coming from that outlet, so even if you connect a number box to it will stay on zero.

The second trigger will let pass anything that crosses it: that is, bang as input means bang as output, float as input means float as output, and so on.

So you may realize that actually it is a more powerful object than simply a visualization of the order of the cords.

Take care and good luck,
Gilberto

Enlightened..

All the best,
Gilberto