n871

Both in Max 6.1.10 and 7.0.5 I'm experiencing weird behavior from %~

When you increase the values up to 24, everything goes fine. (the value is gated from left to right).

From 25 on it jumps...maybe I misunderstand, but this is how I would expect it to work:

24/12 = 2 (rest =0), so gated to gate 0 (available gates: 0 to 11)

Both in Max 6.1.10 and 7.0.5 I'm experiencing weird behavior from %~
This is my patch:

When you increase the values up to 24, everything goes fine. (the value is gated from left to right).
From 25 on it jumps...maybe I misunderstand, but this is how I would expect it to work:

24/12 = 2 (rest =0), so gated to gate 0 (available gates: 0 to 11)
25/12 = 2 (rest = 1), so gated to gate 1
26/12 = 2 (rest = 2), so gated to gate 2
...

isnt-this-a-huge-bug

This looks like it does the trick, so I guess %~ must be buggy...right?

when 25 %~ 12 + 1 : it outputs 2, BUT gate~ routes it through output number 1

when 26 %~ 12 + 1 : it outputs 3, BUT gate~ routes it through output number 2

when 28 %~ 12 + 1 : it outputs 5, BUT gate~ routes it through output number 4

when 29 %~ 12 + 1 : it outputs 6, BUT gate~ routes it through output number 5

my guess is that there are unseeable rounding approximations here, which go wrong.

Putting a round~ (without argument) between +~ 1 and gate~ doesn't help ; BUT putting a round~ 0.5 solves the issue

yes, i can totally reproduce here ;
when 25 %~ 12 + 1 : it outputs 2, BUT gate~ routes it through output number 1
when 26 %~ 12 + 1 : it outputs 3, BUT gate~ routes it through output number 2
when 28 %~ 12 + 1 : it outputs 5, BUT gate~ routes it through output number 4
when 29 %~ 12 + 1 : it outputs 6, BUT gate~ routes it through output number 5

my guess is that there are unseeable rounding approximations here, which go wrong.
Putting a round~ (without argument) between +~ 1 and gate~ doesn't help ; BUT putting a round~ 0.5 solves the issue


i think this is because the msp modulo works in float only.

try input+1 instead of output +1
i think this is because the msp modulo works in float only.


@roman : it's worse, same bug occurs, plus you get 0 output instead of 12

you may be right on the cause. Still it seems to be a bug and/or problematic, because a signal constant of 3 with a -0 mantisse ≠ a signal constant of 3 with a +0 mantisse, and there is absolutely no way of seeing this. However it's true that generally one avoids to build logic with audio signals.

@roman : it's worse, same bug occurs, plus you get 0 output instead of 12
you may be right on the cause. Still it seems to be a bug and/or problematic, because a signal constant of 3 with a -0 mantisse ≠ a signal constant of 3 with a +0 mantisse, and there is absolutely no way of seeing this. However it's true that generally one avoids to build logic with audio signals.


hehe, input 25 actually shows a result of "2.0" in flonum, but the gate does not get a 2 (int) from it.

a quick workaround would be to add 1.001 instead of 1 to those values.

not sure if it will constantly work until the highest possible signal number, but for a range of 0-10000 it should be ok.

modulo was expr $f1-int($f1/$f2)*$f2. the question is how the int() is implemeted in the modulo msp object...

Isn't this a huge %~ bug?