I have been working on an abstraction that is essentially a counter that takes an input from a midi CC, numbers greater than 64 increase the count, numbers less than 64 decrease the count, but it needs to be able to have the count modified manually or recieve a new value and take up the count from there. My current solution is shown below in a not quite functional state, messed something up when I cleaned it up to make it legible and now it counts by two and does not take properly to a preset at the first inlet, but it shows my direction, which I doubt is the best path and it has the problem of missing quick changes at the left inlet. Any direction on a better path or how to improve this one would be much appreciated. Trying to stick to vanilla, even if I do not use vanilla in the end result, I still want to figure this out in vanilla.

note: ignore the loadbang > i64 nonsense, no idea how that came to be, it probably did make sense in some earlier evolution.

@oid Maybe this midicounter.pd

@ingox Almost, I knew I had gotten lost in my overly complex, ever growing patch. This gets me almost perfect.

counter.pd
Needed the [- 64] since the input is actually an encoder set to relative output centered around 64, turning the knob faster gives output greater than just 1 and adjusts the value more quickly. The one thing this lacks which my more complex and convoluted solution provided is that the number box attached between its first inlet and outlet was automatically restricted to the range passed to [clip], I have yet to figure out a simple way to achieve that which does not cause stack overflows, but having to manlually set the number box limits is not a huge deal. I have not quite given up on that quite yet.

Thanks for the help.

@oid Put the [clip] between [+ $3] and [t f f]?

@ingox How would that change anything? Is there some dataflow trick that I am missing here?

What I am trying now and seems the much more sensible path is just to use [nbx] and [range $1 $2(, but the arguments in the message do not seem to get replaced by the arguments passed to the abstraction so I get "$2; argument number out of range." I can not quite seem to figure out why this is and every test I can come up with to figure it out, just raises more questions as to the inner workings here.

Ok, so I did [pack $1 $2] > [range $1 $2( and that seems to work. This suggest that messages do not accept abstraction level arguments, only those passed directly to their input, they always have their own scope?

Nearly done with this, the end is in site.

@oid Yes, dollar signs in messages work differently then in objects!
http://write.flossmanuals.net/pure-data/dollar-signs/

@ingox I have read that before, apprently it never sank in without beating my head against it for awhile. Thanks for the help.

Think I have pretty much finished this up, but I have a few questions and would like to know if there is anything that can be improved. I added the part above [moses], it is just a set-reset flip-flop, the first number recieved by the top left inlet is sent to the [color 0 43( message and does not increment the counter, just highlights the connected [nbx] so if you forget what controls what you can find your way without altering the sound. It also sends a bang to the right outlet for resetting any other instences of this abstraction back to black, the top right inlet is the reset. Between [moses] and [+ $3] I added a multiplier that only acts on numbers greater than 1 so you can change the velocity characteristic of the knob sending the CC info, inlet to set multiplier. Inlet next to that is preset input. The chunk on the right sets the range of the [nbx] connected between its inlet and the left outlet.

I have forgotten what my questions were. guess they will wait for tomorrow. Appreciate any critiques or suggestions anyone would like to offer.