This has happened to me 3 times now in the last few weeks, after never having a problem. I swiped up to close the app before rebooting the iPad. The file size was 4 kB. I was in the process of finishing a project and lost a lot of work.
I'm pretty sure the catalyst of this problem is when the app stalls while saving. You have to close the app and reboot. Then your safe for is corrupt. Best advice I got here was to save as a few versions of your track to avoid this.
Do you find anything in the Unsaved Sessions folder ? Have you checked the Auto-Saved file too ?
Also, check if your device has enough free space.
Let us know,
Cheers,
Mathieu.
Hi Mathieu
Nothing in the Unsaved Sessions folder. I was working out of an autosave session, where I was trying out some things before committing them to the actual project. Unfortunately I had made a lot of changes during this time, and lost them all.
The project itself is pretty resource heavy and I remember there being a lot of CPU spikes just before I stopped playback and went into the multitasking menu to swipe up and quit the app. Perhaps the watchdog killed the app off right at that time while it was saving? Not sure.
Anyway, I remembered most of the edits and the project is pretty much done. Still, a bit disconcerting when auto save only works when you switch back into the app after switching out.
Some people may jump on me here, but its your fault, use save and never rely on autosave.
If you swiped and closed the program while it was autosaving, of course the project is corrupt.
1 Autosave should be completely removed or work like any desktop software, and only ever save at specific time intervals after a project has initially been saved by the user.
2 Unsaved sessions should not exist AT ALL.
Both of these things are generally causing this extremely poor habit of expecting B3 to save for you, plus all the other issues they self create by saving extra versions and loss of samples.
This is simply put the worst feature of B3 (And i hate the note entry/edit on the piano roll, so that says something)
B3 should remove all this autosave overly clever nonsense and just work like full desktop apps, because that is what it is competing with, not £3 IOS nonsense apps designed for people who dont want to use a save button.
Yes i understand that a big part of IOS users are braindead and just want to noodle around never saving (that is not pointed at anybody here by the way, just a general observation on IOS usage) but honestly **** them, B3 is too good to pander to the dregs.
To be fair, even the forums that most IOS developers use do this nasty autosave silliness too, the amount of draft messages i have to delete out of my account here that are single words or half saved sentences is unreal.
Autosave/unsaved is IAAs cousin and both should be shot in the face.
A lot of desktop apps do autosave, even Logic. Hell, Logic saved when it crashed most of the time. Taking us back to the 1990s just because you’re apparently more Alive when you’re constantly interrupting your workflow to save makes even less sense than the sometimes broken autosave we have in BM3 now.
What if my case was indeed the watchdog killing the app because I was pushing the iPad too hard, and I had done the save as normal? Is that somehow different?
I’d honestly rather have BM3 autosave in the way Auria Pro does, where each change is a save, and if something is messed up, I have at least 10options over the previous while to go back to. We need more autosave, not less. People just want to make music and making it easier for people to do that is going to determine the viability of doing so on the iOS platform.
I think we need to separate crash recovery and autosave in this discussion.
I always want full control of my saves - at all times. I want the freedom to experiment and discard changes, and commit to disk when I choose. And if I fuck up, it's all on me.
The Adobe suite (which I use all day at work) has bulletproof crash recovery, but leaves save responsibility to the user. This is how it should be done.
You obviously didn't read my post fully.
I said autosave should work how desktop autosave works, IE autosave at specific times after an initial save.
Possibly you do not understand the difference between autosave on desktop (Time based) vs autosave of unsaved sessions on IOS because of user laziness/general IOS bad habits, that bad habit being just turning off the iPad or putting it to sleep or even just swiping up and closing it from the homepage and expecting there to be a save, THIS IS EXTREMELY BAD HABIT (Not your fault by the way, Apple said to do it) and no, no desktop software does this, in general all desktop software asks you if you want to save an unsaved project when you try to close, IOS and Apple decided they wanted to form bad habits and rather than have close or exit buttons on software, they wanted apps to just stay open and store the save in the open app, this has never been fixed since the earliest IOS and it is completely useless for the complicated apps we have now.
If you swipe up and close the app, you should lose the project you are working on, on a desktop that is exactly the same as ctrl+alt+del on windows or forced quit on mac, and if you expect either of those to save for you, it simply wont happen.
Disagree all you like, i am stating facts, not opinion.
Logic crash save, this is impossible, it may give you the last saved autosave which is at a specific time period (Again see difference between desktop autosave and IOS bad habit, laziness autosave) but if you are suggesting that Logic somehow time travels after crashing and then retrieves the data before a crash or constantly saves every second so that any crash has retrievable information, you are wrong.
Each change being a save, that is simply not viable and i doubt that Auria does it, if it does then he is the cleverest programmer on any platform that ever existed, simply put the slowdown that that would cause would make the software unusable.
Why mention the 1990s, autosave has worked the same since then on the desktop and still does, so yeah nothing wrong with that implementation.
You said you swiped and closed the app, nothing to do with any watchdog, bad habit, project lost, not B3s fault, if anything blame Apple for forming bad habits.
"If you swiped and closed the program while it was autosaving, of course the project is corrupt.".
If the save screen freezes for several minutes, you have no choice but to close the program. I am not sure if you were implying that a bug that freezes the app and results in a corrupted file is a user error? It's a legitimate bug and shouldn't be dismissed off hand.
Anyways, the work around for the screen freezes is to save multiple versions using "save as" which I started doing. I appreciated the suggestion and have incorporated it into my workflow.
Im not implying anything, im going by exactly what was typed by @alteredmoods
@alteredmoods said:
The project itself is pretty resource heavy and I remember there being a lot of CPU spikes just before I stopped playback and went into the multitasking menu to swipe up and quit the app. Perhaps the watchdog killed the app off right at that time while it was saving? Not sure.
That is bad habit (expecting the app to save for you) and user error, not a bug, swiping up can not save before quiting, it is a forced quit !!!!
I didn't reference your issue at all, which was caused when you tried to save, not bad habit, a very good habit, not user error, therefore a bug
However, having said all that, i take issue with all IOS users who think that swiping up and closing the program WITHOUT SAVING, is going to result in usable saved data from just before the swipe, it is a forced quit, a last resort (although yes we all close our apps like this after saving, because Apple are A-Holes and want no exit/close buttons, closing like this is good habit, but only if you save first)
There is a big difference between B3 file corruption and shoddy housekeeping.
I simply don’t care enough about this to get into a protracted internet argument, but suffice to say, no, I should not lose my project by merely swiping up. The last time this happened, I didn’t swipe up. BM3 should either be saving, every chance it gets, or not writing at all. End of story. If I am force-quitting, why’s it trying to write to a file?
I don’t care about what Apple suggests or doesn’t, if they enforce bad habits or don’t, or whatever. I just want to make music. And I’m gonna use the tool that makes it easiest for me to do that. BM3 is one of the best tools and, save for this issue that recently came up for me, has been a joy to use. I also use Auria all the time. I do work, I quit the app, I restart the app, it carries on right where I left off. So, somehow, somebody has managed to make it work. Perhaps you can go on the Auria Forum if you are more interested.
Absolutely ridiculous !!!
Yes i am normally very moderate around here and do try to keep the peace, but when people are blaming their own misinformed laziness as B3 bugs, sorry, it just doesn't wash.
Yes there is an issue in B3 with corrupted files, yours wasn't even close to it.
I became a lurker only because of the behavior of our moderator, sorry. Apparently, this forum is very quiet, which is strange given the notoriety of BM3. Maybe am I not the only one to find his attitude too harsh...
Concerning this topic, I share the opinion of @alteredmoods, there is nothing to add
@Sygma said:
Who is going to moderate the moderator now lol ?
To be fair i was extremely moderate here, I could have been very very honest about the absurdity of what was being asked for, but that would have not been nice.
Here is a very simple and common example of how silly the idea of save after every change is.
1 load a sample on to a pad
Autosave
2 Normalise sample
Autosave, new normalised sample created
3 Reverse sample
Autosave, new reversed sample created
4 Didn't like reverse, undo,
Autosave, new unreversed sample created
In 3 clicks, 3 samples were created, infinite space is not an option on iPad, good housekeeping is.....well it is good really.
B3 is not a toy app and the features do and should reflect this, that includes expecting users to understand saving.
Pretty sure @mathieugarcia doesn't want his program writing corrupt files in any scenario; lazy, uninformed users or not. But you win, dude, you apparently need to.
When you force quit, the app doesn't have a chance to respond in any way. If you use this technique with other apps, such as Auria, I'm amazed you haven't encountered corruption and lost data elsewhere.
Like I said, if you force quit it doesn't wait for the app to complete what it was doing, it just dumps the app and flushes the RAM. It's almost impossible to build an app that can safely withstand an instantaneous quit at any moment.
Hell, even games consoles tell you not to cut the power when they are saving. lol
Can you not comprehend that YOU forced the app to quit while it was saving, YOU created the corrupt file, it was YOUR fault, not B3s
Of course @mathieugarcia doesn't want any corrupt files, trust me, i know that better than anybody, however B3 did not corrupt the file, YOU did.
This is not about winning, stop being so immature, this is about YOU understanding that YOU could have prevented the situation by not force quitting too early, YOU lose in this case, YOU lose a session.
Don't worry, you can have the last word, you will never get any advice from me ever again, but if you badmouth B3 for no reason again, i will put you in your place again !!!
Flushing the RAM shouldn't have any bearing at all on what's happening on the disk.
If I force quit an app on a desktop, unless I do it during a save, it should not affect the file on disk. Unless it is actively writing to the file, I should merely fall back to whatever my last save was. That wasn't what happened here. Everybody's so focused on telling me how wrong I am that they aren't paying attention to this. If I'm force-quitting, why is the app writing? And if it's got a lock on the file open for write at all times, that's even worse because any number of things could cause corruption.
I'm through with this. Hopefully the session corruption, whatever the cause, will be fixed in a future update.
@5pinlink said:
Im not implying anything, im going by exactly what was typed by @alteredmoods
@alteredmoods said:
The project itself is pretty resource heavy and I remember there being a lot of CPU spikes just before I stopped playback and went into the multitasking menu to swipe up and quit the app. Perhaps the watchdog killed the app off right at that time while it was saving? Not sure.
That is bad habit (expecting the app to save for you) and user error, not a bug, swiping up can not save before quiting, it is a forced quit !!!!
I didn't reference your issue at all, which was caused when you tried to save, not bad habit, a very good habit, not user error, therefore a bug
However, having said all that, i take issue with all IOS users who think that swiping up and closing the program WITHOUT SAVING, is going to result in usable saved data from just before the swipe, it is a forced quit, a last resort (although yes we all close our apps like this after saving, because Apple are A-Holes and want no exit/close buttons, closing like this is good habit, but only if you save first)
There is a big difference between B3 file corruption and shoddy housekeeping.
I see, thanks for clarifying, I thought you were referring to my post. I understand now. Sorry for mistake. That being said, I don't think force quitting the app should corrupt ones file. I am with @alteredmoods on this one. I don't think it's ridiculous at all.
@alteredmoods said:
I should not lose my project by merely swiping up. The last time this happened, I didn’t swipe up. BM3 should either be saving, every chance it gets, or not writing at all. End of story. If I am force-quitting, why’s it trying to write to a file?
>
This is a fair request, and an issue that I expect will be worked on.
@tk32 said:
I think we need to separate crash recovery and autosave in this discussion.
I always want full control of my saves - at all times. I want the freedom to experiment and discard changes, and commit to disk when I choose. And if I fuck up, it's all on me.
The Adobe suite (which I use all day at work) has bulletproof crash recovery, but leaves save responsibility to the user. This is how it should be done.
Id like to add that this comment is the one I most agree with. I really don't care if there is a working autosave or not as long as there is crash recovery and my actual save does not get corrupted when manual Saving.
@alteredmoods said:
If I'm force-quitting, why is the app writing?
This is your mistake, and what has led to the misunderstanding. The app never 'knows' when you are force quitting - there is no warning... it just suddenly happens because the user decided to do it. Autosave happens when the app chooses, and in your case, you must have been unlucky enough to force quit at the exact moment Beatmaker was trying to write from RAM to disk.
@5pinlink said:
Don't worry, you can have the last word, you will never get any advice from me ever again, but if you badmouth B3 for no reason again, i will put you in your place again !!!
????
Where the hell did I do that? I said "BM3 is one of the best tools"...!
@alteredmoods said:
If I'm force-quitting, why is the app writing?
This is your mistake, and what has led to the misunderstanding. The app never 'knows' when you are force quitting - there is no warning... it just suddenly happens because the user decided to do it. Autosave happens when the app chooses, and in your case, you must have been unlucky enough to force quit at the exact moment Beatmaker was trying to write from RAM to disk.
Yah this makes sense, would a possible solution be for BM3 to have 2 autosaves that would rotate writing over one another, thus avoiding a total corruption of everything. The force quitting is a necessary fact of life on this and many other iOS apps. I get that some here believe autosaves to be some sort of abomination, but if it is in the app it should be stabilized or removed.
Everyone should manually save as well. I am sure @alteredmoods will do more of that in the future.
Save and "Save as" often should be the name of the game everyone.
If the save button were on the main front page discreetly in a corner, this whole issue would become a non one, as it would just become second nature for those not accustomed to manual saving, as it would be directly in front of them. Having to tap what three/ four times to get to the save button I guess makes some people possibly forget.
In another thread about autosaving, I found that B3 autosaves whenever you leave it by either pressing home or bringing up the app switching view, or locking the iPad. So it tried to autosave when you brought up app switching and you forced it close before it was done. Autosave probably should not do that. As far as I've found, there has been no definite confirmation on whether autosave ever saves while B3 is full screen and in focus. I believe it never does, which is why you can lose all of your work over a long period of time if the app crashes and you haven't saved or triggered an autosave by unfocusing the app.
@groovey it would be a non issue if autosave was better explained and if it didn't try to save while opening the app switcher. I do hope they add a save button that's always visible, which has been suggested a couple times in other threads.
Comments
This has happened to me 3 times now in the last few weeks, after never having a problem. I swiped up to close the app before rebooting the iPad. The file size was 4 kB. I was in the process of finishing a project and lost a lot of work.
Hey @alteredmoods,
Do you find anything in the Unsaved Sessions folder ? Have you checked the Auto-Saved file too ?
Also, check if your device has enough free space.
Let us know,
Cheers,
Mathieu.
I'm pretty sure the catalyst of this problem is when the app stalls while saving. You have to close the app and reboot. Then your safe for is corrupt. Best advice I got here was to save as a few versions of your track to avoid this.
Save file not safe for. *
Hi Mathieu
Nothing in the Unsaved Sessions folder. I was working out of an autosave session, where I was trying out some things before committing them to the actual project. Unfortunately I had made a lot of changes during this time, and lost them all.
The project itself is pretty resource heavy and I remember there being a lot of CPU spikes just before I stopped playback and went into the multitasking menu to swipe up and quit the app. Perhaps the watchdog killed the app off right at that time while it was saving? Not sure.
Anyway, I remembered most of the edits and the project is pretty much done. Still, a bit disconcerting when auto save only works when you switch back into the app after switching out.
Some people may jump on me here, but its your fault, use save and never rely on autosave.
If you swiped and closed the program while it was autosaving, of course the project is corrupt.
1 Autosave should be completely removed or work like any desktop software, and only ever save at specific time intervals after a project has initially been saved by the user.
2 Unsaved sessions should not exist AT ALL.
Both of these things are generally causing this extremely poor habit of expecting B3 to save for you, plus all the other issues they self create by saving extra versions and loss of samples.
This is simply put the worst feature of B3 (And i hate the note entry/edit on the piano roll, so that says something)
B3 should remove all this autosave overly clever nonsense and just work like full desktop apps, because that is what it is competing with, not £3 IOS nonsense apps designed for people who dont want to use a save button.
Yes i understand that a big part of IOS users are braindead and just want to noodle around never saving (that is not pointed at anybody here by the way, just a general observation on IOS usage) but honestly **** them, B3 is too good to pander to the dregs.
To be fair, even the forums that most IOS developers use do this nasty autosave silliness too, the amount of draft messages i have to delete out of my account here that are single words or half saved sentences is unreal.
Autosave/unsaved is IAAs cousin and both should be shot in the face.
Couldn’t disagree more.
A lot of desktop apps do autosave, even Logic. Hell, Logic saved when it crashed most of the time. Taking us back to the 1990s just because you’re apparently more Alive when you’re constantly interrupting your workflow to save makes even less sense than the sometimes broken autosave we have in BM3 now.
What if my case was indeed the watchdog killing the app because I was pushing the iPad too hard, and I had done the save as normal? Is that somehow different?
I’d honestly rather have BM3 autosave in the way Auria Pro does, where each change is a save, and if something is messed up, I have at least 10options over the previous while to go back to. We need more autosave, not less. People just want to make music and making it easier for people to do that is going to determine the viability of doing so on the iOS platform.
I think we need to separate crash recovery and autosave in this discussion.
I always want full control of my saves - at all times. I want the freedom to experiment and discard changes, and commit to disk when I choose. And if I fuck up, it's all on me.
The Adobe suite (which I use all day at work) has bulletproof crash recovery, but leaves save responsibility to the user. This is how it should be done.
You obviously didn't read my post fully.
I said autosave should work how desktop autosave works, IE autosave at specific times after an initial save.
Possibly you do not understand the difference between autosave on desktop (Time based) vs autosave of unsaved sessions on IOS because of user laziness/general IOS bad habits, that bad habit being just turning off the iPad or putting it to sleep or even just swiping up and closing it from the homepage and expecting there to be a save, THIS IS EXTREMELY BAD HABIT (Not your fault by the way, Apple said to do it) and no, no desktop software does this, in general all desktop software asks you if you want to save an unsaved project when you try to close, IOS and Apple decided they wanted to form bad habits and rather than have close or exit buttons on software, they wanted apps to just stay open and store the save in the open app, this has never been fixed since the earliest IOS and it is completely useless for the complicated apps we have now.
If you swipe up and close the app, you should lose the project you are working on, on a desktop that is exactly the same as ctrl+alt+del on windows or forced quit on mac, and if you expect either of those to save for you, it simply wont happen.
Disagree all you like, i am stating facts, not opinion.
Logic crash save, this is impossible, it may give you the last saved autosave which is at a specific time period (Again see difference between desktop autosave and IOS bad habit, laziness autosave) but if you are suggesting that Logic somehow time travels after crashing and then retrieves the data before a crash or constantly saves every second so that any crash has retrievable information, you are wrong.
Each change being a save, that is simply not viable and i doubt that Auria does it, if it does then he is the cleverest programmer on any platform that ever existed, simply put the slowdown that that would cause would make the software unusable.
Why mention the 1990s, autosave has worked the same since then on the desktop and still does, so yeah nothing wrong with that implementation.
You said you swiped and closed the app, nothing to do with any watchdog, bad habit, project lost, not B3s fault, if anything blame Apple for forming bad habits.
Force close should come with a warning enabled by default on new iPads...
Warning: force close can lead to lost data and corrupt saves. Are you sure you want to continue? YES/NO
(Power users can disable it in settings)
Hey @5pinlink I take issue with this statement,
"If you swiped and closed the program while it was autosaving, of course the project is corrupt.".
If the save screen freezes for several minutes, you have no choice but to close the program. I am not sure if you were implying that a bug that freezes the app and results in a corrupted file is a user error? It's a legitimate bug and shouldn't be dismissed off hand.
Anyways, the work around for the screen freezes is to save multiple versions using "save as" which I started doing. I appreciated the suggestion and have incorporated it into my workflow.
Im not implying anything, im going by exactly what was typed by @alteredmoods
That is bad habit (expecting the app to save for you) and user error, not a bug, swiping up can not save before quiting, it is a forced quit !!!!
I didn't reference your issue at all, which was caused when you tried to save, not bad habit, a very good habit, not user error, therefore a bug![;) ;)](https://intua.net/forums/resources/emoji/wink.png)
However, having said all that, i take issue with all IOS users who think that swiping up and closing the program WITHOUT SAVING, is going to result in usable saved data from just before the swipe, it is a forced quit, a last resort (although yes we all close our apps like this after saving, because Apple are A-Holes and want no exit/close buttons, closing like this is good habit, but only if you save first)
There is a big difference between B3 file corruption and shoddy housekeeping.
I simply don’t care enough about this to get into a protracted internet argument, but suffice to say, no, I should not lose my project by merely swiping up. The last time this happened, I didn’t swipe up. BM3 should either be saving, every chance it gets, or not writing at all. End of story. If I am force-quitting, why’s it trying to write to a file?
I don’t care about what Apple suggests or doesn’t, if they enforce bad habits or don’t, or whatever. I just want to make music. And I’m gonna use the tool that makes it easiest for me to do that. BM3 is one of the best tools and, save for this issue that recently came up for me, has been a joy to use. I also use Auria all the time. I do work, I quit the app, I restart the app, it carries on right where I left off. So, somehow, somebody has managed to make it work. Perhaps you can go on the Auria Forum if you are more interested.
Absolutely ridiculous !!!
Yes i am normally very moderate around here and do try to keep the peace, but when people are blaming their own misinformed laziness as B3 bugs, sorry, it just doesn't wash.
Yes there is an issue in B3 with corrupted files, yours wasn't even close to it.
Who is going to moderate the moderator now lol ?
Actually, he does a pretty good job of moderating himself.
I hope you have more to contribute to this topic than just poking with a stick, @Sygma
I became a lurker only because of the behavior of our moderator, sorry. Apparently, this forum is very quiet, which is strange given the notoriety of BM3. Maybe am I not the only one to find his attitude too harsh...
Concerning this topic, I share the opinion of @alteredmoods, there is nothing to add
To be fair i was extremely moderate here, I could have been very very honest about the absurdity of what was being asked for, but that would have not been nice.
Here is a very simple and common example of how silly the idea of save after every change is.
1 load a sample on to a pad
Autosave
2 Normalise sample
Autosave, new normalised sample created
3 Reverse sample
Autosave, new reversed sample created
4 Didn't like reverse, undo,
Autosave, new unreversed sample created
In 3 clicks, 3 samples were created, infinite space is not an option on iPad, good housekeeping is.....well it is good really.
B3 is not a toy app and the features do and should reflect this, that includes expecting users to understand saving.
Pretty sure @mathieugarcia doesn't want his program writing corrupt files in any scenario; lazy, uninformed users or not. But you win, dude, you apparently need to.
@alteredmoods
When you force quit, the app doesn't have a chance to respond in any way. If you use this technique with other apps, such as Auria, I'm amazed you haven't encountered corruption and lost data elsewhere.
Like I said, if you force quit it doesn't wait for the app to complete what it was doing, it just dumps the app and flushes the RAM. It's almost impossible to build an app that can safely withstand an instantaneous quit at any moment.
Hell, even games consoles tell you not to cut the power when they are saving. lol
Can you not comprehend that YOU forced the app to quit while it was saving, YOU created the corrupt file, it was YOUR fault, not B3s
Of course @mathieugarcia doesn't want any corrupt files, trust me, i know that better than anybody, however B3 did not corrupt the file, YOU did.
This is not about winning, stop being so immature, this is about YOU understanding that YOU could have prevented the situation by not force quitting too early, YOU lose in this case, YOU lose a session.
Don't worry, you can have the last word, you will never get any advice from me ever again, but if you badmouth B3 for no reason again, i will put you in your place again !!!
@tk32
Flushing the RAM shouldn't have any bearing at all on what's happening on the disk.
If I force quit an app on a desktop, unless I do it during a save, it should not affect the file on disk. Unless it is actively writing to the file, I should merely fall back to whatever my last save was. That wasn't what happened here. Everybody's so focused on telling me how wrong I am that they aren't paying attention to this. If I'm force-quitting, why is the app writing? And if it's got a lock on the file open for write at all times, that's even worse because any number of things could cause corruption.
I'm through with this. Hopefully the session corruption, whatever the cause, will be fixed in a future update.
I see, thanks for clarifying, I thought you were referring to my post. I understand now. Sorry for mistake. That being said, I don't think force quitting the app should corrupt ones file. I am with @alteredmoods on this one. I don't think it's ridiculous at all.
>
This is a fair request, and an issue that I expect will be worked on.
Id like to add that this comment is the one I most agree with. I really don't care if there is a working autosave or not as long as there is crash recovery and my actual save does not get corrupted when manual Saving.
This is your mistake, and what has led to the misunderstanding. The app never 'knows' when you are force quitting - there is no warning... it just suddenly happens because the user decided to do it. Autosave happens when the app chooses, and in your case, you must have been unlucky enough to force quit at the exact moment Beatmaker was trying to write from RAM to disk.
????
Where the hell did I do that? I said "BM3 is one of the best tools"...!
My goodness, you got issues man.
Yah this makes sense, would a possible solution be for BM3 to have 2 autosaves that would rotate writing over one another, thus avoiding a total corruption of everything. The force quitting is a necessary fact of life on this and many other iOS apps. I get that some here believe autosaves to be some sort of abomination, but if it is in the app it should be stabilized or removed.
Everyone should manually save as well. I am sure @alteredmoods will do more of that in the future.
Save and "Save as" often should be the name of the game everyone.
If the save button were on the main front page discreetly in a corner, this whole issue would become a non one, as it would just become second nature for those not accustomed to manual saving, as it would be directly in front of them. Having to tap what three/ four times to get to the save button I guess makes some people possibly forget.
In another thread about autosaving, I found that B3 autosaves whenever you leave it by either pressing home or bringing up the app switching view, or locking the iPad. So it tried to autosave when you brought up app switching and you forced it close before it was done. Autosave probably should not do that. As far as I've found, there has been no definite confirmation on whether autosave ever saves while B3 is full screen and in focus. I believe it never does, which is why you can lose all of your work over a long period of time if the app crashes and you haven't saved or triggered an autosave by unfocusing the app.
@groovey it would be a non issue if autosave was better explained and if it didn't try to save while opening the app switcher. I do hope they add a save button that's always visible, which has been suggested a couple times in other threads.