jit.cellblock issues - Corrupted output in Max 6 but fine in Max 5

    Macciza
    Mar 27 2013 | 4:07 pm
    Hi All Bizarre problem with jit.cellblock output in M4L using Max 6 but same patch is fine in Max 5 . . .
    Values of first row are Auto Filter, Auto Filter Amp, Amp - in first four columns
    Auto Filter shows up as 0 0 "Auto ilter" (missing F) in message box and in Max window, but shows correctly as 0 0 Auto Filter in print @popup 1 in patch. Amp shows up properly in all these places . . .
    After processing output with [ zl slice ] I get "Auto inter" because that is what seems to be coming out as per above . . . After further processing with [ zl reg ] and [ zl group ] it gets even weirder . . .
    "Auto ilter" Auto F lter" A p Am - is what I am ending up with ??? This is meant to be sent out as an OSC message but is useless . . "Auto Filter" "Auto Filter" Amp Amp - is what I am expecting and can't seem to work out what the problem is
    Strange enough that jit-cellblock is doing weird stuff but the following stuff is even stranger . . . Are there any known bugs/problems with jit.cellblock, or any reason for the [ zl ] processed stuff??
    Hope I have explained enough as it is part of a larger patch that doesn't really allow me to post an example as such Any suggestion or advice would be greatly appreciated
    Cheers
    • Andrew Pask
      Mar 27 2013 | 6:21 pm
      HI ,
      Yeah sorry - you'll need to dig it out of your patch, hopefully the message interaction with cellblock will be easy enough to capture
      Let's have a look - cellblock got a complete rewrite for Max 6
      -A
    • Macciza
      Mar 28 2013 | 7:11 am
      Hi Andrew Thanks for the quick response, though it seems like I have 'jumped the gun' a little with my error report . . It seems instead that it is an issue with [ sprintf ] returning wrong results in Max 6 compared to it's Max 5 results!! ??
      I teased the relevant parts out of the larger project where the various parts are encapsulated and recreated a basic version which demonstrates the heart of the problem. Here are two identical patches that demonstrate the problem of Max 6 chopping of a character compared to Max 5. I tried to include as much as I could of the process, which means the [ 2 ] message box needs to be triggered as it is [loadmess]'d in the patch. This obviously ruins the required functionality as the end result is meant to be used in an OSC message but will no longer match.
      Hopefully it should be reproducible at your end, as it seems verifiable across various systems at my end. It would be great if you could offer an alternative means of obtaining proper results in Max 6, or at least use it to chase down the problem.
      This works as expected . . .
      ----------begin_max5_patcher----------
751.3oc4X9saZCCEFWZ2EdJrhTuqCkisy+1c8l8RLplBfK0sgDTrQi1p9tuX
6jUncIXBCmMsKHVwwX+wubNe9XdYhm+7xcLgO5Knug77dYhmmtKUGdM264uN
a2h7LgdX9qYBQ1Jl+0lmIY6j59CPAnY9e5lsxRzW44RV0L+1AcWYgTveloFH
fmFzzcw107hblTOw325rbqrsWno2MYxE2yKV88J1BoQtjHZ8Lgh.P0fCBTMP
xz.zsMeI9RsxJm+vmww6qkhr0Zs3eSEOKu8IlkU9zFlYA78Q2pdxqSlntbsk
.pf8i5U7C7YSEaCqXIRvjmBVfSEKTHVABZPnpIlZfSGTIbzoR1iHUjidsOAr
PFHVHwoplDRuXg5Lr7.WNcAKOedd4hGO+zEZOoKTcdBMDq+omnuCHcg.x.PP
NWTGaWih1OCBIcYvfuntITZhlKlFBdZXOlIXmEezELTKJZOu1KqSabjI2QcM
MoOeVHYrcTjn4n7y2gEeTb.DSJTswRX2dIvP13YdVwpgm.0EXJEOsddY9Ec2
GRrNHAL69.3f97YgnwNXopd5Ym7lOCHhYuMiigdYxf1R9OtY6Le2UHGfMVuA
5zJbZuExAiu2qSqxMAardAaXCL5lutvigZLdITc7RXZeoSoiMQDap3Ex6PWI
tRbYKfgnqok.lBb603cz2j94bTEa04yCbe7vbzmzHywg5iGwN0ysClvkkYW1
i.0ThajNBwj8zEQFxNy0w4+iUIGkzDVjZQkbz+qJjqAMfwH4XExc19I5Ys9.
jEu+OiRKMU+GxIQ41pEsSU6AVQuItkLgjWjI4kE6On5DcD7qAcOe4Rl94sLa
Me4lx533FQzwaMq0TnMZ5Pgew0D0FME5TMkZijT5F6NLgsPSQNkRzChc+8JJ
wow2pC6eTHAtMVBrImCb6at2sbcnoX2poXKBm.2JIanD1oQ313LoN0kCkjM4
boN88VrEJJw4VkGSQtMcKxREA+UksQOCFUeyqS9IW.oe7A
-----------end_max5_patcher-----------
      This one does not work as expected - in both 6.0.7 and 6.1
      ----------begin_max5_patcher----------
784.3oc4X10aaBCEFVZ2Q9UXgTuKKB+Aes65M6Ow5zDj3l5VBfvNc8C0+6Ce
Lz0tUnlzLqf1EADFi8KO4bd8w73BO+7p63RezWPeC4483BOOnIcCdcW64uK6
t0EYRna963RY1Vt+Ry8T76TP6An.zE9e578pJzWEEJdyE98cpb+NQYAWAi.o
qw5L05qDka+QCesxn.JksJbIJJNcUvRDIHPeBmrJ.88tGRrAlrp7q+LIte3u
rpTUlsiC257FQVwKl3p8p9YF20poI080byz56+73qGJo3A3FXxp.cqOsXg9v
RKATI+msx6u3ScCulWtAI4p2DK3QvBIVCBVTh9TLy.mAnR37hJY2fzQNfPeK
rPeervH5SIzQwB6zDKWKTqVyKJxKpVeyTSWHoPnPH1jtjfgzE5PHfNUDvFBA
EBYaPbKJ5+cLQxPFLjI6lDaBIRB0mnDs0xflIjSy3igfgVgnW30dfgNIvwzj
w7YwIyJGEEJGULUG1NbfiMj.GqiUFxKAO4EdHCAj7rxsG8Dng.Sk79c4UG.a
f7GbHXyhIAi4yhilUAKMsyJe3EeFMAhZvAX5FiGEJgGs.Fm41dg+GpRNVD.j
PiCb5nExgmYduezpbMrggSrgM34k46A5wPYPILTCLBSGKaJcVQDYcinTcI5L
4YxIW.SHXqPifrnjQMdmWKR+PApguc57.VBhx.RvFkGwmtVtCvDgpJaxaAxT
hKESLaPbLhb7VYtMf9jsRNJyXqFFYQkbr+qJjqGMlsM+dEx4V+DnOs6qr7O+
XTv6gt8WyIY09l08yP2pBne+hrgKUhxLknp7E8Q+Q.Pjm6zUhMa3v8C5eLgL
KufCT3s+CyV4.S06pmvW0o+o5IzF8Pcmdn1nmVSbD1M5gXgdhbFdvVnFlyTS
jEpwc+UwrTMtgMwVnlDmolDKTSpyTiMdx5M33n.GaRpz6E0Ux40oLCnG2Y4X
SVN1cIVXaVwB6PKYaxsvtaEclEQOIGXvroZrr55a4MxtgDDRa8oWW0nuLZIb
onzbILh9M7aE88OdgdzdZwu.KUEdXA
-----------end_max5_patcher-----------
      Cheers MM
    • Jeremy
      Mar 28 2013 | 10:05 am
      Although this patcher helped me find a totally different bug (and thank you!), it's actually functioning correctly (sort of). One of the differences between Max 5 and Max 6 involved improved support for UTF8 character encoding. You are using the 'itoa' object to create the character '2' (STX) and concatenate it with the symbol "Auto Filter". This creates the symbol "2Auto Filter", which isn't really displayable, resulting in the visual corruption you're seeing (the symbol is actually intact).
      We can look into the display issue, but I question whether you really intend to create the symbol "2Auto Filter".
      Best, Jeremy
    • Macciza
      Mar 28 2013 | 11:14 am
      Thanks heaps The original code was not developed by me, though I am currently troubleshooting/working at getting it functional again as it ceased working with Max 6 and is being updated now to work with Live 9. I must admit I was a bit unsure of the actual intention of that particular section of code and why it was doing the int to asccii conversion, even though it was functional in Max 5 and with Live 8. It is using a live.observer to trigger the process that collects the current devices in Live tracks to get them into the cells and then being cycled through to update an external control system via OSC so that any particular device on any track can then be accessed via its stored location and device name for edit controls. I will try to see if I can find out what the original developers views.ideas/intention was with it all, or perhaps just try and recode that section in someway so that I can get it to work. Realising of course that it may be difficult to venture an opinion without actually seeing the whole system, any suggestions on possible approaches would be appreciated. I guess I need to to get it back from being a symbol to an actual text representation that can be sent and recognised via OSC.
      Thanks heaps MM
    • Macciza
      Apr 02 2013 | 6:48 am
      Hi Again The 2 is an additional 'control' character sent with the messages so it does make some sense and seem to work despite the visual issue. Thanks for the help on this issue.
      Are you aware of any particular changes to the [ this patcher ] object?? Where as previously it has reported the location of a sub patcher as being in Cycling74 etc where it exists . . Now with Live 9 it seems to report the location of the M4L device that it is part of?? This has caused a patch to no longer work and need to be minorly rewritten to get the path again. Just wondering .. .
      MM