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

    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

    • 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
    • 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 . . .
      This one does not work as expected - in both 6.0.7 and 6.1
      Cheers MM
    • 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
    • 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
    • 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 .. .