Brennon Bortz

Good grief, Cycling '74. We've been asking for years, and I can't be the only one who's indescribably tired of crashes. For God's sake, implement autosave. _This_ is a feature for which I won't actually complain about paying such steep upgrade prices.

Good grief, Cycling '74.  We've been asking for years, and I can't be the only one who's indescribably tired of crashes.  For God's sake, implement autosave.  _This_ is a feature for which I won't actually complain about paying such steep upgrade prices.


seriously-its-time-for-autosave

I've been working with Max for Live for almost 3 years now, Max stand alone for almost 2.5 and to be honest I never missed this option. In fact; I'm not too sure I'd applaud the addition of it. Because it would mean the environment itself needs more resources, first to keep track of time and at specific intervals to start doing something which, depending on your patch, could very well get even heavier on the resources.

When working with specific audio experiments I don't want any chance of interference by something as trivial as this.

Besides; what's the big deal in remembering to hit control-s before you test something which could potentially crash?

We're talking about a routine firing on the order of minutes to hours, and saving a text file on the order of a few to several hundred kilobytes. The resources required to do this are trivial--_nowhere near_ the resources required to create 'interference'.

The big deal in remembering is two-fold. On the one hand, one sometimes simply forgets to do so--the entire reason for autosave. On the other hand, _anything_ can potentially crash. I've found, after many years of working with Max, that it's rarely the case that something I think could potentially cause a crash is what does so--often just the opposite.

We're talking about a routine firing on the order of minutes to hours, and saving a text file on the order of a few to several hundred kilobytes.  The resources required to do this are trivial--_nowhere near_ the resources required to create 'interference'.

The big deal in remembering is two-fold.  On the one hand, one sometimes simply forgets to do so--the entire reason for autosave.  On the other hand, _anything_ can potentially crash.  I've found, after many years of working with Max, that it's rarely the case that something I think could potentially cause a crash is what does so--often just the opposite.


I often sketch and brainstorm in a patch and then if I'm into it I fork it off into a new version, so autosave would muck that up, though with the way lion/mountainlion are going, I need to get used that paradigm either way.

since ever i am even hacking the the command-S (save into...) key command and menu entries

out of programs such as photoshop, cubase, PT ... for exactly that reason.

since ever i am even hacking the the command-S (save into...) key command and menu entries
out of programs such as photoshop, cubase, PT ... for exactly that reason.

Correctly designed autosave avoids this issue by autosaving to a separate file. When recovering from a crash, the existence of this file is checked and dealt with if necessary. Otherwise, this file never overwrites the 'actual' file until one saves explicitly. Really, it's not that difficult to design in a way that does not interfere with one's workflow, as well as in a way that can be enabled/disabled at will.

Correctly designed autosave avoids this issue by autosaving to a separate file.  When recovering from a crash, the existence of this file is checked and dealt with if necessary.  Otherwise, this file never overwrites the 'actual' file until one saves explicitly.  Really, it's not that difficult to design in a way that does not interfere with one's workflow, as well as in a way that can be enabled/disabled at will.


Brennon is right here. There are no disadvantages to anyone if it's done right, and its a huge advantage to the many that that are frustrated by the (sometimes all too frequent) crashes. It's become a common enough feature in professional apps, we should expect to have such an option.

Well, about those professional apps... I'm working with Ableton Suite, Reason, several Komplete components (Absynth, Guitar Rig 5 pro and the Reaktor & Kontakt players), Samplitude.

None of them, not even Reaktor (Max' direct competition in some way), have an auto-save feature.

So quite frankly I don't think its as commonly used as you say here.

Well, about those professional apps...   I'm working with Ableton Suite, Reason, several Komplete components (Absynth, Guitar Rig 5 pro and the Reaktor & Kontakt players), Samplitude.

So quite frankly I don't think its as commonly used as you say here.


Crash avoidance isn't as big a deal for me (though I have thrown my fists up to the angry "crash my max after figuring out something awesome/new" gods. It's just that when I'm doing experimenting I can just close the file, knowing that it will be just as I had left it (without autosave saving over my good patch with bad ideas).

Among other reasons, this is the main reason why I've not messed with projects yet. The "no saving" thing freaks me out there. (It's also hyper-poorly documented).

Crash avoidance isn't as big a deal for me (though I have thrown my fists up to the angry "crash my max after figuring out something awesome/new" gods. It's just that when I'm doing experimenting I can just close the file, knowing that it will be just as I had left it (without autosave saving over my good patch with bad ideas). 

Among other reasons, this is the main reason why I've not messed with projects yet. The "no saving" thing freaks me out there. (It's also hyper-poorly documented).


ShelLuser, you've mentioned several 'professional-ish' applications in a tiny, tiny corner of the software world. The fact that both Apple and Microsoft have provided APIs to autosave/versioning functionality (to which Rodrigo alludes) hint at the fact that in the much, much larger world of software development that programs like these occupy, this is at least a desirable feature for plenty of development houses.

At the end of the day, you just can't argue that there aren't plenty of folks who have stability issues in Max (though you may not be amongst us...) Some of us, myself included, have had these issues across many versions and different systems and platforms--in other words, while it may be particular to mine or others' experimentation styles, it is not particular to this or that OS or 'box'.

The issue is underscored by something else that Rodrigo mentioned--experimentation. When I'm working on an article or paper, it's easy enough to segment my workflow. Finish a paragraph, save the file, finish a paragraph, save the file (although I avoid the issue in my text editor with a neat little feature called autosave, ironically...) In Max, things are different. My workflow is not nearly as easily segmented, however. I experiment around, like Rodrigo, find different things that I like. Try something new...move one to a different part of the patch...etc. It's likely just my ADHD-addled brain, but when I'm working like this, my concentration is focused wholly on experimenting creatively--not on making sure I'm always saving.

Sure, it's an excuse. Sure, things would be better if I just formed a new habit. The problem is that when a program has proven over time to have stability issues, the onus most certainly should not on me as a user to pick up the slack and do the developer's job for him. Furthermore, the responsibility certainly would be mine in open-source relationship, but most certainly not when I'm also picking up the 500-&%$!ing-dollar tab.

In other words, if C74 is going to charge what they do for a license, I'm not out of line in asking for a feature that is relatively straightforward to implement, makes up for the places where stability is...lacking, and does not affect those users who do not wish to use it. I'm not the first person who has been frustrated with this issue, and certainly not the last.

Oh, and by the way, this comes up regularly on the NI and Ableton forums, as well. Strangely though, when I search the forums of my lowly text editor for 'autosave', no one's clamoring for them to remove this God-forsaken workflow because it's just ruining everything they do...

ShelLuser, you've mentioned several 'professional-ish' applications in a tiny, tiny corner of the software world.  The fact that both Apple and Microsoft have provided APIs to autosave/versioning functionality (to which Rodrigo alludes) hint at the fact that in the much, much larger world of software development that programs like these occupy, this is at least a desirable feature for plenty of development houses.

At the end of the day, you just can't argue that there aren't plenty of folks who have stability issues in Max (though you may not be amongst us...)  Some of us, myself included, have had these issues across many versions and different systems and platforms--in other words, while it may be particular to mine or others' experimentation styles, it is not particular to this or that OS or 'box'.

The issue is underscored by something else that Rodrigo mentioned--experimentation.  When I'm working on an article or paper, it's easy enough to segment my workflow.  Finish a paragraph, save the file, finish a paragraph, save the file (although I avoid the issue in my text editor with a neat little feature called autosave, ironically...)  In Max, things are different.  My workflow is not nearly as easily segmented, however.  I experiment around, like Rodrigo, find different things that I like.  Try something new...move one to a different part of the patch...etc.  It's likely just my ADHD-addled brain, but when I'm working like this, my concentration is focused wholly on experimenting creatively--not on making sure I'm always saving.

Sure, it's an excuse.  Sure, things would be better if I just formed a new habit.  The problem is that when a program has proven over time to have stability issues, the onus most certainly should not on me as a user to pick up the slack and do the developer's job for him.  Furthermore, the responsibility certainly would be mine in open-source relationship, but most certainly not when I'm also picking up the 500-&%$!ing-dollar tab.

In other words, if C74 is going to charge what they do for a license, I'm not out of line in asking for a feature that is relatively straightforward to implement, makes up for the places where stability is...lacking, and does not affect those users who do not wish to use it.  I'm not the first person who has been frustrated with this issue, and certainly not the last.

Oh, and by the way, this comes up regularly on the NI and Ableton forums, as well.  Strangely though, when I search the forums of my lowly text editor for 'autosave', no one's clamoring for them to remove this God-forsaken workflow because it's just ruining everything they do...


There are two applications which come to mind with a decent autosave/versioning method:

1. Logic: Saves a seperate copy, when the application crashes. Though, this might be counterproductiv for Max, because the last patching step might well have been the one which makes the patch crash - possibly rendering the saved copy useless.

2. XCode: Let's you make incremental snapshots of your whole project. I usually make a snapshot, before starting critical/overall changes to the code. I think this would be very beneficial for Max, especially for large patches with many subpatches.

I'm using a similar approach in Max by simply using "compress folder" in Finder.

There are two applications which come to mind with a decent autosave/versioning method:
1. Logic: Saves a seperate copy, when the application crashes. Though, this might be counterproductiv for Max, because the last patching step might well have been the one which makes the patch crash - possibly rendering the saved copy useless.

2. XCode: Let's you make incremental snapshots of your whole project.  I usually make a snapshot, before starting critical/overall changes to the code. I think this would be very beneficial for Max, especially for large patches with many subpatches.
I'm using a similar approach in Max by simply using "compress folder" in Finder.

Interesting question... Well, I'm sure some way of autosaving could be helpful (although I don't really have crashes with Max -- most of my crashes happen because of bad patching which, once fixed, never happen again). The problem is, that it's very hard to define what an appropriate way of autosaving would be for a Max patch. Sometimes patching is 'programming' in the sense that one has a specific goal to achieve and just wants to 'put it on paper'. In these cases autosaving can be very handy. However, this is not always the case. When patching is part of the artistic development, one would usually keep copies of several stages, maybe go back and open a new 'branch'; sometimes the latest version of the patch is not the 'best' one; for instance, it happens many times that I deliberately 'forget' to save my patches, as the saved version works as a reference to what I can go back each once in a while.

One could tell me to save the 'branches' with new names. The problem is that for me in person is less confusing to store a mid-sized patch in my short-term memory for a couple of hours than to remember what 20-30 filenames meant the day before. So I really prefer to have saved the things that really _need_ to be saved and stored for future use.

Another problem arises with resource management. I know quite a lot of people who always create huge patches with everything stored inside the patch, therefore having patches occupying several MBs. In that case, proper autosaving (depending on the algorithm that decides what needs to be saved) might add a lot of garbage, which after a while might end up in hundreds of MBs of garbage. As a person who can't afford external drives (therefore I'm constantly running out of disk space), this would annoy me a lot.

To make a long story short: autosaving could indeed be a great feature. The problem is that there are so many different styles of using MaxMSP that I doubt that there could be an autosaving policy that would fit the needs of the majority.

I would LOVE to have a "Save Version" feature - when selected, a window pops up with a recommended version number (so the first time you use it it would suggest "patchername_v1.1" or something, and you could simply hit enter to go with it, or type "1.1.1" to go off on a subversion branch). This could save a copy with the new appended filename, or perhaps somehow keep version history within the file itself? I'm sure many of you do something like this manually, but it would be handy to have a a command in Max that simplifies the process.

Siska raises some important concerns about this, however I feel like this feature could satisfy Max users if it had appropriate configurability.

Samplitude uses a .bak file to keep a cosntantly updated autosave file. It doesn't interfere at all with what you choose to save under the original file. Every grown up software should have this in my opinion. There is no downside.

I don't personally feel the need for an auto save function in Max. That said perhaps one solution would be for a save object. This could accept arguments for how frequent saves are and file names.

One potential problem with autosave is that it doesn't affect abstractions that you might be editing. For example, if you're editing abstraction "foo" and Max creates a backed up version, there's no guarantee that the changes in it have propagated to the files that you have open which may require "foo". (in fact, if it's doing a "Save as..." it's guaranteed not to!) My preference is simply to save early, save often.

If there were to be versioning software in Max, my vote would be for Git, as SVN is a PITA when moving things around. I've used Git with Max, and they play together quite well.

One potential problem with autosave is that it doesn't affect abstractions that you might be editing.  For example, if you're editing abstraction "foo" and Max creates a backed up version, there's no guarantee that the changes in it have propagated to the files that you have open which may require "foo".   (in fact, if it's doing a "Save as..." it's guaranteed not to!)  My preference is simply to save early, save often.

If there were to be versioning software in Max, my vote would be for Git, as SVN is a PITA when moving things around.  I've used Git with Max, and they play together quite well.


 object would be indeed very elegant. :-)

@foldh: Nice. A properly written [autosave] object would be indeed very elegant. :-)


Siska, I'm afraid you're conflating the ideas of autosaving and versioning. Treating them independently addresses all of your concerns save file sizes. As far as those go, I could write some Javascript that could generate patches on the order of hundreds of megabytes, but truthfully, if a patch is this large, there's a larger problem with one's approach that should be considered. In reality, I've made and seen ridiculously large, complex patches that weigh in at a few megabytes. To be completely honest, I couldn't even conceptualize how to build a patch as large as what you've stated without Javascript that instantiates things just for the hell of it...

As far as versioning is concerned, it certainly would be nice, as several others have noted. Here though, I'm simply talking about a safety net for all-too-common Max crashes when patching. At the moment it is, I understand, but it 

 be left up to me as an end-user to build what should be unnecessary habits to make up for the stability shortcomings of my chosen tool. Take any 'mainstream' software package you'd like (Photoshop, an OS, etc.) and introduce a sprinkling of random crashing into the mix, and you'll hear unholy hell from the user community. Whether or not it's addressed is a different matter, but the simple fact remains that (especially) as a (well-)paying customer, it shouldn't be my responsibility. Furthermore, I'm not even screaming for the instabilities to be addressed (and maybe I should be); no, I'm only asking for an easily-implemented 'air bag' of sorts as at least a temporary workaround.

Siska, I'm afraid you're conflating the ideas of autosaving and versioning.  Treating them independently addresses all of your concerns save file sizes.  As far as those go, I could write some Javascript that could generate patches on the order of hundreds of megabytes, but truthfully, if a patch is this large, there's a larger problem with one's approach that should be considered.  In reality, I've made and seen ridiculously large, complex patches that weigh in at a few megabytes.  To be completely honest, I couldn't even conceptualize how to build a patch as large as what you've stated without Javascript that instantiates things just for the hell of it...

As far as versioning is concerned, it certainly would be nice, as several others have noted.  Here though, I'm simply talking about a safety net for all-too-common Max crashes when patching.  At the moment it is, I understand, but it shouldn't be left up to me as an end-user to build what should be unnecessary habits to make up for the stability shortcomings of my chosen tool.  Take any 'mainstream' software package you'd like (Photoshop, an OS, etc.) and introduce a sprinkling of random crashing into the mix, and you'll hear unholy hell from the user community.  Whether or not it's addressed is a different matter, but the simple fact remains that (especially) as a (well-)paying customer, it shouldn't be my responsibility.  Furthermore, I'm not even screaming for the instabilities to be addressed (and maybe I should be); no, I'm only asking for an easily-implemented 'air bag' of sorts as at least a temporary workaround.


You have to also make sure that the air bag is a uniform improvement. If I've got a really processor heavy patch running in performance, the last thing that I want during performance is additional unnecessary overhead. As long as it's possible to turn off, it wouldn't be a big deal. I'd really love to be able to have different Max configurations: one for development with the various bells and whistles turned on, one for performance mode, where everything unnecessary is stripped out. (i.e. probing is turned off, auto-crossfading, etc.)

As an aside, I would note that Max already has a form of backup with pattrstorage; for me, I'm more concerned about losing data than I am about losing code, but I tend to use a lot of abstraction.

You have to also make sure that the air bag is a uniform improvement.  If I've got a really processor heavy patch running in performance, the last thing that I want during performance is additional unnecessary overhead.  As long as it's possible to turn off, it wouldn't be a big deal.  I'd really love to be able to have different Max configurations: one for development with the various bells and whistles turned on, one for performance mode, where everything unnecessary is stripped out. (i.e. probing is turned off, auto-crossfading, etc.)

As an aside, I would note that Max already has a form of backup with pattrstorage; for me, I'm more concerned about losing data than I am about losing code, but I tend to use a lot of abstraction.


This is becoming a rather interesting discussion; and I can just second Peter's comments.

Regarding the comments of autosaving vs. versioning: I know exactly the difference between these things. My point was that a 'dummy' autosave feature wouldn't help that much in the Max world, as sometimes the old version of a patch will become the final one. On the other hand, introducing a more complex autosave feature (which, in a way, would be more close to an embedded versioning tool) would potentially generate a lot of garbage. Not for me -- I always modularize my patches and export modules into smaller abstractions; my biggest single-file patches are no bigger than a couple of hundreds of kBs --, but there's lot of people out there where this could lead to problems.

I also wouldn't compare Max to software like Photoshop. If one needs to make a comparison, I think it would be more fair to compare Max to other programming environments like XCode or Eclipse. In a programming environment it is natural that you get crashes here and there, as long as these crashes are caused by the program you write. When a patch crashes, in 95% of the cases the reason is a bug somewhere in the patch, and not a bug in Max itself. Maybe it would be possible and nice if Max would run the patches on a separate thread, therefore even if my patch crashed, Max would still be alive (when you test your programs in XCode, a crash of your program won't usually cause XCode itself to crash). However, this would also add overhead to the system itself, which again, takes up CPU from the CPU usage that I could have on stage for my patch itself.

Again, what I see is that there are too many different preferences among users for how an autosaving feature should work; nevertheless, I really loved the idea that someone dropped in here, about a 'save' or 'autosave' object that I could simply add to my patch and which would take care for autosaving, with some parameters that could customize the behaviour. This approach could also be useful because I could decide patch-by-patch whether I want to autosave them or not, and I shouldn't always toggle 'autosave on'/'autosave off' in some global setting.

Cheers,
Ádám (which is my first name BTW)


Ádám, I wasn't implying that you didn't know the difference, only that you were mixing the two separate concepts. At the end of the day, autosave addresses precisely the frustrations I've mentioned here--there's just no two ways about it. Autosave, if implemented properly, has 

 implications whatsoever for whatever you choose as the final outcome for a particular patch. Autosave is not an implement for erasing changes, creating a separate version, etc. It simply provides a ('non-destructive', in the sense that it will not overwrite willy-nilly something you've explicitly saved) backup in the event of failure. Autosave (again, if implemented correctly) does not automatically overwrite an existing file when reopening after a crash--it gives you the option to view what was retained before the crash and use this as a starting point 

. In other words, everything you're mentioning in your first paragraph there is a non-issue. And again, if autosave is implemented correctly, you can simply disable it if you continue to think it's going to be a problem...

Furthermore, I never compared Max to Photoshop--I was giving examples of softwares with much larger and influential user bases. There, I'm considering Max generally as commercial software that should be held to a certain standard.

This really isn't about user preference. Versioning is one thing, yes, and a feature upon which user preference would certainly come to bear. This is categorically not what I have brought up, though. About the only preferences one might have are the frequency of saving and whether or not the feature is enabled at all. I'm not talking about a complex, configurable feature. I'm merely proposing a way of accessing retained data in the event of a failure. This is not a feature that fills a hard drive, not a feature that impedes workflow, and not a feature that introduces any negligible overhead.

Ádám, I wasn't implying that you didn't know the difference, only that you were mixing the two separate concepts.  At the end of the day, autosave addresses precisely the frustrations I've mentioned here--there's just no two ways about it.  Autosave, if implemented properly, has no implications whatsoever for whatever you choose as the final outcome for a particular patch.  Autosave is not an implement for erasing changes, creating a separate version, etc.  It simply provides a ('non-destructive', in the sense that it will not overwrite willy-nilly something you've explicitly saved) backup in the event of failure.  Autosave (again, if implemented correctly) does not automatically overwrite an existing file when reopening after a crash--it gives you the option to view what was retained before the crash and use this as a starting point if you so choose.  In other words, everything you're mentioning in your first paragraph there is a non-issue.  And again, if autosave is implemented correctly, you can simply disable it if you continue to think it's going to be a problem...

Furthermore, I never compared Max to Photoshop--I was giving examples of softwares with much larger and influential user bases.  There, I'm considering Max generally as commercial software that should be held to a certain standard.

This really isn't about user preference.  Versioning is one thing, yes, and a feature upon which user preference would certainly come to bear.  This is categorically not what I have brought up, though.  About the only preferences one might have are the frequency of saving and whether or not the feature is enabled at all.  I'm not talking about a complex, configurable feature.  I'm merely proposing a way of accessing retained data in the event of a failure.  This is not a feature that fills a hard drive, not a feature that impedes workflow, and not a feature that introduces any negligible overhead.


I guess it would be great if an official voice from C74 would jump in and say something... ;-)

Totally supporting a smart autosave idea. (in another copied file)

I just crashed again Max6 while saving a patch after working on it, damn.

Well, Alexandre, you should have known to save before playing around with your patch in ways that could have made it unstable. Oh, wait...

Well, Alexandre, you should have known to save before playing around with your patch in ways that could have made it unstable.  Oh, wait...


I was not "playing around", i was quietly patching as always.

(not my fault if all my patches at the moment have bpatchers inside bpatchers containing mxjs)

I was not "playing around", i was quietly patching as always.
(not my fault if all my patches at the moment have bpatchers inside bpatchers containing mxjs)


I was just giving you a hard time, Alexandre...

Nicolas, there are plenty of ways to handle autosave. A monolithic save like you describe would be heavy-handed, indeed, and is not the right way to approach the problem. This is exactly the kind of thing that could 

 introduce 'interference', as it has been called here. On the other hand, it may not. Either way, there are ways to approach an autosave implementation that do not require this.

Nicolas, there are plenty of ways to handle autosave.  A monolithic save like you describe would be heavy-handed, indeed, and is not the right way to approach the problem.  This is exactly the kind of thing that could potentially introduce 'interference', as it has been called here.  On the other hand, it may not.  Either way, there are ways to approach an autosave implementation that do not require this.


Having scanned the thread, I didn't notice anyone mentioning the issue of multiple open copies of the same patcher file. This is an Max idiosyncrasy that has always bothered me, but is advertised as a feature (and I daresay some Max users love it). But you can open multiple copies of the same file and make different changes to each. This can be confusing enough as it is, but with an Autosave it could be even more so.

I'm not saying that this precludes Autosave, but it does mean that any halfway usable/elegant Autosave implementation needs to take this peculiarity of Max into account.

Seriously, it's time for autosave...