Saving a project when its files have been reordered
I cannot find any way to manually/explicitly save a project in Max 8. Instead, the project appears to get automatically saved on close, provided a change has been detected. The problem is that I have found a type of change that does not get detected and that will not be saved unless there are other types of change:
When a new file (patcher or code) is added, it is added to the end of the patcher or code section of the file list shown in the project. I can reorder the files by drag and drop. But, if I close the project after adding files and reopen the project before reordering the files, the reorder get lost if I then close the patcher without also do some other type of change, such as removing or adding a file.
I'm hoping this is just a beginner's mistake on my part, that there's some way to manually save the project I'm just not seeing. Or perhaps there's some other trick to making the reorder be recognised when Max checks for changes on closing the project.
Meanwhile, my workaround is to remove a file from the project and add it back in, a dummy change that forces Max to save the project and my changes to the file order when I close the project.
I was wrong . The workaround I described does not work for me after all. Even if I remove a file, add it back in and change its position, it always gets restored to the same position in the file list.
My new workaround is to change Project Items Sort Order in Project Inspector from Manual to Ascending :
This way, the items are shown in alphabetical file name order within category (Patchers, Code etc.) rather than the increasingly arbitrary order I get when the sort order is manual.
Does anyone else get the problem where, when a project's Project Items Sort Order is Manual, a manual reorder of the items with drag and drop is not conserved when the project is closed and later reopened?
I found another workaround. In Project Inspector, set Project Items Sort Order to Manual and turn off Show Patcher Dependencies:
If Project Items Sort Order is Manual and Show Patcher Dependencies is On, the impossibility of saving item order changes might be understandable if patchers with dependencies were automatically placed at the top. But that's not the case:
Unless there's a rationale I'm not understanding for this behaviour, I suspect it's a bug.
I've worked out the rationale, though the documentation is not explicit. So I'm now fairly sure this behaviour is by design, not a bug. Consider the attached demo project as an example:
Project Items Sort Order is Manual and Show Patcher Dependencies is enabled:
The Project Settings documentation page of Max 8 Reference explains Show Patcher Dependencies as follows:
When enabled, implicit dependencies are displayed in the Project window. (default = on)
Here's how that rule is implemented in the example project:
With Project Items Sort Order set to Manual, a patcher that contains an abstraction is shown above the patcher to which the abstraction refers. And a patcher that contains a bpatcher is shown above the patcher to which the bpatcher refers. The names of the two parent patchers describe their relationships to their respective child patchers.
There's a fifth patcher, Cat, that has no dependency relationships with any of the project's other patchers. Let's try moving it with the mouse to a position between a parent patcher and its child patcher:
So far, so good:
Now let's close the project and reopen it. When the project is closed, any changes to it, in this case a change to the manually defined item order, should be saved. But here's the item order when the project is reopened:
The independent Cat patcher is no longer between the abstraction parent and child patchers. Nor has it returned to its previous position at the end of the list. Instead it has been moved to immediately below the child patcher and before the bpatcher parent/child pair.
Similarly, if the independent patcher is moved to between the bpatcher parent and child patchers, then when the project is closed and reopened, the independent patcher will be positioned below the bpatcher child patcher.
Max 8 Reference contains no further documentation for Show Patcher Dependencies. And the only documentation for Project Items Sort Order is its inclusion in the screenshot of the Project Inspector window on the Project Settings page. So there's no explanation of the relationship between those two settings. That omission presumably results from either oversight or, perhaps, an assumption that the relationship is intuitive and/or self-explanatory.
i find all this automatic stuff more complicated than creating a manual order.
when i start a project, i create a folder for it, and put everything which belongs to it and is requried by it into this folder. i usually begin on the desktop, which is in my search path, later move it into the max folder.
in a modern versions of max this would be typically in /packages.
i always have one folder with my abstractions, and when i feel the need to change something, i copy the file manually into the project folder, which may contain project-specific abstractions.
while normal abstractions are named "signature.filename", project specific abstractions are named "signature.project.filename".
bpatchers and poly patchers usually get an additional "bp" or "po" after the signature.
it is not only easy to remember while patching, it is also easy to search and sort.
where required, for example for complex, major patches, i am creating versions manually by making a copy and adding a vesion number ("110.dumbapp.main2-05.maxpat")
i mostly load files into compiled objects by the inspector - and try to avoid using collections, prototypes, snippets, scripting or the media browsers wherever possible - at least for the initial call or save of a patcher file in a new poject.
unnecessary to add that i of course also dont trust automatic backup nonsense from lenovo or apple and do that manually, too.
There are lots of promising tips there, thanks.