Bug in [scale] with Max 8.3.0

Peter Ostry's icon

Mac mini M1, macOS 12.3.1 (Monterey), Max 8.3.0
I don't know if it happens just on my Mac, but since Max 8.3.0 there is a bug in the [scale] object.

See attached test patch.
Fed by integers 0-127, [scale 0 127 0 127] does not output the numbers
17 21 25 29 34 42 50 58 68 84 100 and 116 (always the same numbers).

Max Patch
Copy patch and select New From Clipboard in Max.

Same happens if I try with floats.
Setting the exponential value to 1. does not help.

double_UG's icon

happens here too, max 8.3 and 8.21 Win10, It works right with gen scale.

Max Patch
Copy patch and select New From Clipboard in Max.

Jean-Francois Charles's icon

Indeed, it's strange that the gen and standard versions of [scale] don't agree.
That said, comparing floating-point numbers with [==] is always a bit touchy. In your patch, you use an integer version of [==], so, the floating point numbers are first floored then tested (so, 16.9999 becomes 16 which is compared to 17).

Max Patch
Copy patch and select New From Clipboard in Max.

Still, you're right, it looks like [scale] has a slight problem.

11OLSEN's icon

@BEN BRACKEN said:

We are aware of and tracking the scale bug, which was present in Max 8.2.1/8.2.2 as well.

Peter Ostry's icon

@Jean-Francois Charles
Sorry to deliver a sloppy testing patch ;-)
I tested also with floats and without rounding the bug was the same, basically.
Cycling'74 agreed after I sent them the bug report.

BTW, [zmap] works, if someone can use it as a temporary replacement.