Something is making my patch "dirty". How do I find out what it is?
At some point, while editing a medium sized patch, my patch has gone "dirty' in that simply opening the file (and not editing anything) makes it so the file shows up as needing to be saved (the little red mac OS 'close' button gets that dark dot, telling me the file has been edited).
Now it's a pretty sizable patch, so deleting small sections of it until I find out what's causing this 'edit' will take a while.
Is there a way to print out what's causing the 'edit', or do I have to manually delete bits until I find out what it is?
And even if I do find out what it is, is there something that could be causing this? (As far as I know I only have a handful of loadbangs/loadmesses, there are some [forward]s and empty [r]s which I don't use too often).
Ok, did a bunch of deleting/testing and it looks like my polybuffer~s with @embed 1 are the problem.
I don't remember this happening before, but it's possible it has and I never noticed? Actually checking the polybuffer~ helpfile, and opening that up makes the helpfile "dirty".... hmm....
These are the polybuffer~s in question:
(I get the "dirty" outcome with these in my main patch (with the referenced files in place) as well as in an empty patch (with no referenced files in place))
I can't reproduce the problem in both Max 6.08 and 6.1.10 on Mac OS , not using max 7, could it be a bug in max7 ?
If nothing else works, one can still send clean message to max, to surpress save dialog on patcher close,
but the interesting question is what is causing the behaviour...
I remeber in the past having some similar issues, but can't remember exactly with what objects.
Usually retyping objects name and arguments solved it.
Hmm interesting. I just checked in Max6 (6.1.9) and it's not coming up "dirty", so it appears to be Max7 specific.
Also just double checked on two machines (10.10 and another on 10.11), and both Max7s (7.2.2) have the "dirty" polybuffer~ problem, with both the polybuffer~.maxhelp and my patch(es).
Updating to 7.2.3 to see if that changes anything.
This is currently a bug that we are aware of. As a workaround, you can set the dirty bit of a patcher with a message to thispatcher:
probably a classic like loadbang->flonum ?
did you already try to save-in once more?
Just as a note, I am finding, if I make changes to a preset in a subpatch, the patch is not marked as dirty, so there is no prompt to save before closing. Sending a 'dirty' message to a thispatcher object, when storing a preset to a preset object in the subpatch, does fix the problem. I don't think this is necessarily a bug, because in some cases maybe you would otherwise be wanting to set thispatcher with a 'clean' message in other design cases. Just a thought :)