JIT.OP - Why do I have to send matrix twice to get the right result in such a basic patch?

loadmess's icon

Help! I tried everything that I could think of and I can not figure out a solution.
I'm trying to do a very basic calculation with jit.op, but somehow I have to send the matrices twice to get the expected result from JIT.OP.
Check the patches below to recreate the problem.
First Click, you get the wrong result: 0 1 2 3 4
Second Click, the right result appears: 0 1 1 1 1

I decided later to try the calculation with jit.expr and then jit.gen.
Now the problem seems arbitrary, I don't know if it is a patching problem or something deeper.
It's driving me crazy...

why.maxpat
Max Patch

why2.maxpat
Max Patch

why3.maxpat
Max Patch

why4.maxpat
Max Patch

Thank you!

loadmess's icon

In case anyone stumbles here, the problem was identified here:
https://www.facebook.com/groups/961274147281218/permalink/5558920777516509



and the solution found is this:

kLSDiz's icon

Beautiful Max idiosyncrasies, known in other software projects as "bugs".
:)

Rob Ramirez's icon

when adapt is enabled for jitter matrix operators then the the object will adapt to the left-most inlet, causing the object to be re-initialized when an input is received in that inlet. less a bug and more an unexpected behavior. solution is to set @adapt 0 and simply use jit.matrixinfo to initialize the object for cases where you need to set the right-inlet before setting the left inlet.

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


loadmess's icon

It's good point Rob Ramirez.
Sounds inefficient to me though, but I'm not sure if there's a big computational difference.
In my case, I'm using lots of operators and right to left matrix coordination, so ends up changing a patcher quite a lot and increases the clutter.

I imagine another solution with a attribute to tell the jitter object to expect the same type of matrices between left and right inlet. Something like the @scalarmode in vexpr.