Watch out for using itoa to set message box text
Just wanted to post that I found a nasty but interesting problem i had today with itoa connected to the right inlet of a message box.
When i happened to have the bad luck of getting certain unexpected integers as input (I'm reading from an EEPROM over MIDI), it put characters into the message box that were then saved with the patch and caused max to crash next time the patcher was opened - with a completely unhelpful crash log that at first suggested a java related crash. Eventually I found the culprit using a text editor on the patch file - max had created what i assume is invalid json:
, {
"box" : {
"maxclass" : "message",
"text" : "" çàˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ"",
"id" : "obj-46",
"fontname" : "Arial",
"fontsize" : 12.0,
"numinlets" : 2,
"numoutlets" : 1,
"outlettype" : [ "" ],
"patching_rect" : [ 9.0, 605.0, 252.0, 18.0 ]
}
}So I replaced the "text" attribute with something reasonable, and it worked again (whew! i otherwise i would have lost a days work on this 1.5MB patch).
So all Max patchers - watch out and don't use itoa to set a message box or other persistent text if you're not sure what's going to come through it :)
that is very interesting indeed...and there's a chance that other objects might do it too: coll? textedit? dialog?
Reminds me of some nasty problems I had awhile back where certain invisible control characters suddenly made the patch un-parseable and therefore unopenable. Very disconcerting, I guess I had inserted them totally by accident while patching. With some searching around I was able to see that certain text editors have a "zap gremlins" function which gets rid of these kinds of text...gremlins. Worked great. I think there have been improvements in Max's ability to read through such issues, but it seems you have found another weak point...
yes - very possibly could be a problem with other objects too. Once again TextWrangler saves the day - can't recommend that piece of software highly enough.