Sébastien Gay

I would like to constrain an increasing/decreasing MIDI value between 0 and 127. I came-up with this solution, that, unexpectedly, seems to be  working ;-), but I was wondering if one of the MAX experts had a better/less convoluted one to suggest :

how-to-constrain-accums-output

Thank you MAKEPATCHESNOTWAR I always forget Gen when it comes to this type of logics !

Yeah, same. I just recently discovered we now have a Max version as well so it's a nice excuse to use it where i can :)

accum and incdec would do really well to have some clamping arguments in my opinion, it's such a common issue.  I don't know how easy that is with legacy objects, tho.

agreed, 'incdec' could use 'min'/'max' style attributes.

but i think 'accum' is just that way to serve as an event-based "+=" with added inlet for "*=", otherwise, we have 'counter':

the "-1 +1 accum" method is totally valid for this kind of thing.

constrain? why? where would the data go? i would just [clip 0 127] and then [change] it, that is usually enough. no reason to permanently reset the accum object.

but to come back to the original patch... if you think that [clip] (which performs max(min(..)..) )is to simple for you, you could at least combine those two ifs into a single expr:

Hi Roman. [clip] was my first thought. But, as  far as I can see, it doesn't work : eventhough it outputs values between 1 and 127, [accum] still accumulates values upstream. If you add "1" 200 times, [clip] will output 127, but will have 200 as input.  Then if you send "-1" to [accum], it will output 199, but  [clip]  won't give you 126 right away, as expected ! Hope this makes sense ;-)

This is what I usually use for endless encoders - pretty simple and it's settable (handy if you work with presets), inc and dec could be anything (e.g. if your encoder reacts to different speeds)  - works well.

yes, i see what you mean. there can be various behaviours someone wants from such an encoder, and what you describe is probably much more common than what my example does. :)

we have 27 to 41 different options, including using counter(s) instead of accum as proposed by raja.

but let´s look at approach number 13 first: using a gate to block further input when a boundary is exceeded.

But I sincerely believe VOLKER BÖHM won the first prize for his simple and elegant solution !

It seems so obvious when I see it ! Really inspirationnal. Thank you very much, VOLKER BÖHM.

How to constrain [accum]'s output ?