Why PONG works this way?
For a list of numbers from 1-15 (fold at 8) this is what it gives back:
1,2,3,4,5,6,7,8, 6 ,5,4,3,2,1,0
shouldn't I get 7 after 8?
is it a bug or some rounding thing?
For starters, if you're working with integers (as in uzi) then you should work with integers in your expr and pong objects. Oh, wait, pong seems only to work with floats arguments.
Thing is, a fold implementation is going to work with modulo and division operators (your expr breaks for input greater than 15 as well as for negative input), and division in floats is often subtly different from what one might naively expect.
In this case it looks like [pong @mode fold] does have a bit of a bug (and probably a result of on unhelpful rounding). But you could implement your own with a bit of patching and arithmetic.
Off the top of my skull and without any testing, something like:
function fold(n, min, max)
var range = max - min;
n = abs(n - min) % (2 * range);
if (n > range) {
n = (2 * range) - n;
}
return min + n;
value, min, max
[expr ((abs($i1-$i2))%(2*($i3-$i2)))*($i1($i3-$i2))]
-110
your free klingonian to max translation service since 2002
Thanx guys, certainly I can code my own PONG object, the question was if it's a bug or an intentional way of work for PONG. If a bug, then I will submit a ticket, that's all...
On the float/integer thing: "For starters, if you’re working with integers (as in uzi) then you should work with integers in your expr and pong objects."
You can mix these just the system will implicitly cast INTEGER to FLOAT and vica versa, so certainly better if one understand the difference, but in this patch it's irrelevant, i think... ;)
Anyway thanx for the help!
Kevin
my expr is wrong ;) dont have my abstraction here now.
funny how such bugs can survive for several years, isnt it. it seems almost noone is using objects like pong, people all code their own stuff from more basic objects. ;)
The behaviour indeed is different from pong~. By the way, pong was introduced only in max 6.1, probably not many have been using it.
Now we're at it; the attribute with the signal version appears dysfunctional.
@FineCut: If you're clear about the differences between floats and ints, then yeah, you can just let Max typecast. A lot of people tend to think they're all numbers (and infinite precision, to boot), and then get a little surprised that things don't work quite as they expect.
I've been looking a bit more at pong, too, having wondered if the problem was just something strange at the full integer values, but looking at some numbers including fractional values, it just seems as if pong is altogether a bit wonky in fold mode.
Yet another test patch:
oh, you are right, the non-MSP pong is actually new. my bad.
one could still think that people do a quick test of their code before releasing it. this isnt a complaint or anything, these situations just make me wonder.
"fold" and "wrap" is something which looks simple but can drive you mad when you try to build it. nice to see that i am not the only one.
-110