(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim agitato816@gmail.com:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
this very much sounds like a problem with floating point precision overrun.
an [f] object (and actually *any* number within the Pd universe) will
hold a single precision 32bit floating point number, which can only
represent *consecutive* integer values up to 16777216.
(consecutive means, that [f] can hold representations of both (e.g.)
1000023 and 1000024).
if the numbers go higher, singple precision floats will have gaps
bigger than 1.0 inbetween them (e.g. the next number after 16777216
representable by [f] is 16777218) - this breaks a counter that
increments 1 (since 16777216+1 will be evaulated to ~16777216!)
the solution is actually quite simple: never allow your number to grow
as big as that.
in your counter this means, that the feeback part, must include the [%
6] (so the numbers in the counter will only ever stay in the range
0..6):
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
btw, you ASCII rendering of the patch did not use [trigger]. you
should always use it when you want to connect multiple inlets to a
single outlet.
mfgsdr IOhannes