I have been working on a patch which needs a counter that increments by the value input and splits the output, if count decreases it goes out one side, increases out the other. Fairly simple but I am having issues with restricting its range, mod works wonderfully, but 5 mod 24 is not the same as 5 mod 32, so count gets screwed up if you change the mod, which can and does happen in this patch. Select works but it greatly increases the number of things I need to update when changing the length, can over shoot, gets confused easily and requires more logic to deal with counting by anything but 1/-1 to insure it does reset which just means more objects I need to update when changing length, it becomes a complicated easy to screw up mess quickly. Just looking for some ideas, seem to be trapped in these two paths and can not see anything else, Here is my simple but flawed [mod] based counter to clarify my ramblings.

EDIT: forgot to say, trying to keep it vanilla.

@oid Maybe not the most elegant (and I might not have understood) but this will I think do as you wish...... counts.pd
An input of zero will bang both up and down with the previous counter value.
You will maybe want to change the [*] back to [+] as it was in your example.
And then putting [mod] back into the patch I am even less sure the result is what you are looking for..... countsmod.pd
David.

@whale-av You almost recreated my patch perfectly Guess I did not explain as well as I thought and/or my simple patch is not as clear as I thought, yours and mine do the exact same thing, just slightly different methods of failure. The issue is that as the counter gets higher the mod gets off, if the counter is at 76 and the mod is 12, output will be 4, set mod to 22 and now the output will jump to 11 on the next count since 77 mod 22 is 11. So, it needs to be reset often, say everytime it hits 0, but than mine will have the same issue as yours, when mod wraps around the 0 will go to the negative side but it needs to stay on the positive. So, the positive out should go, 0 1 2 3 0 1 2 3 for a mod of four, not stick the 0 on the negative and the negative should wrap from 0 back to 4 if going backwards.

And I just realized how to fix it, just needed to add a change so I can reset the counter at the hot inlet. I had discounted this because it sent pd into an infinite loop, never occurred to me to just keep that loop from happening. Still interested in any other ideas for this sort of thing anyone may have.

And the patch for anyone who may need such a thing. count.pd

EDIT: still has one problem, changing the mod to a number smaller than the current output will cause a jump, so ideas on how to deal with that gracefully would be appreciated.

@oid Maybe something like this: modcounter.pd

@ingox Thats good, took a little figuring. Is the [t f] below the [+ $1} vestigial or does it serve a purpose that is beyond me? Seems to work fine without. You always give me a new use of route and @whale-av always gives me a new use of spigot, it never seems to fail. I neglect both of those objects too much and should spend some time learning to use them in less straight forward ways.

@oid Yeah, this trigger can be removed. [route] can do different things, but here i just used it in the way it seems to be originally intended, to distinguish separate cases (counting up or down) and send them to different routes.

Another design.

And another one

@ingox I meant how it is combined with the conditional test and [pack], kind of like a sort in place.

@Il-pleut I like that one with [v], gets me thinking.