@Martyreasoner i do not think autosave is an abomination, i think autosaving unsaved sessions is an abomination, you completely misunderstood again.
1 No app should EVER autosave unless the user has previously saved, autosave should then save to that saved file and create a backup of the previous save file, this is how all good desktop software works and is also good housekeeping, this gives just two save files (save and backup) and it is impossible to lose anything further back than your previous save/autosave.
2 No app should ever autosave on every change, that would be clunky as anything and near impossible to implement or use, saving isn't realtime.
3 Autosave spacing should always be a user setting, some like it at five minutes, some ten minutes etc.
4 Autosave needs to have a user set timed reminder for samples, if the user sets it to twenty minutes, every twenty minutes if there are unsaved samples a warning will appear "You have unsaved samples" note here that this does not affect autosave session, if that is set to two minutes it will still save every two minutes, but you cant have samples being saved on every autosave session, you would have no storage left after a few hours experimenting with samples.
5 For the obvious reasons of storage, samples should never be autosaved, but no 4 sample save reminder covers this perfectly, this does not affect audio tracks, those should either be in a temporary folder if it is an unsaved session, and moved to the session folders recordings sub folder when the session is saved, or if it is a saved session, saved straight to the session recording sub folder, the temporary folder should be flushed whenever the app starts.
6 On the subject of session folders, when you save a session, you should be able to name it and the session folder will be named accordingly, you should also decide where in the file structure the session is saved, not have to save the session, close the session, find it in the browser, move it to your session folder, and rename it, this is very very clunky behaviour.
7 No app should ever autosave unsaved sessions just to cow to people who cant be bothered to save, it is a completely nonsense feature that has caused no end of trouble (audio files in the wrong saved folder etc)
8 If autosave is to exist, then an indicator must clearly show to the user that it is currently saving, so that they dont force quit while saving.
9 This should go without saying, but not in this thread, Autosave should NEVER save while playing back/Recording.
So yeah, autosave unsaved sessions, abomination yeah, real autosave as above, lifesaver
@Sygma said:
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
Sorry i didn't see this post.
I have edited this reply because i did tell you to contact Intua to have me removed.
But then i checked other IOS forums...
AUM forum = Not strictly dead, but not very busy.
Nanostudio forum = Dead
Auria forum = Not dead but not as active as here.
Audiobus forum = Discussion of Audiobus dead.
Caustic forum = Dead
In fact the only forum busier than this one is Cubasis, and well, that's Cubasis lol, that puts us in seriously heady company hahaha.
So yep, your claims are complete and utter nonsense, you never were a regular poster and on checking back you got uppity after i clamped down on racist and sexist posts, so please, get over yourself and dont even bother posting if it is just to troll
Damn, seriously, second busiest forum in IOSville, OK boys and girls lets make a plan, we have to nail Steinberg hahaha.
@MSandoval said:
Plus save-after-every-change may lead to file corruption if you start editing a file when the process starts.
Which is why you include checkpoints over the last period of recent time (minutes / hours / days) to fall back on in this kind of strategy. You get the best of all worlds: Immediate state save on the main file, checkpoints on that file if in the rare event a save causes corruption, and you still have control over your saves by Saving As.
@5pinlink said:
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.
Personally, I wouldn't be in favour of autosaves triggering whilst I am jamming, recording takes, or twiddling automations.
Perhaps you could set it to trigger only after record or playback was stopped, but TBH I'd still probably disable this feature and keep doing manual saves
Yeah if you look at my list in the post above, i think number 9 is never autosave during record or playback.
But yeah autosave NEEDS to be user selectable off and on, if i have it on it is normally set to an hour or something, in case i get in headspace and forget to save.
@tk32 said:
Personally, I wouldn't be in favour of autosaves triggering whilst I am jamming, recording takes, or twiddling automations.
Perhaps you could set it to trigger only after record or playback was stopped, but TBH I'd still probably disable this feature and keep doing manual saves
Why would that matter at all in your case? I could understand if you were trying to use an early generation iPad but according to your profile you have one that can write to disk at a minimum of 250 MB/s and can typically read at 4x that speed. It just makes zero sense not to autosave with that kind of bandwidth.
It may surprise you to learn this but even iPad pros stutter occasionally, especially when you're running high DSP with a heavy session of AUv3 plugins.
Also bear in mind that for autosave to work it's not just a simple case of updating a single data file. It also has to save any new samples, plugin states, and other dependent audio into the session folder, which will put a momentary strain on CPU and disk writes.
All of which convinces me that I don't want B3 autosaving whilst I am in the middle of making music. I imagine anyone who intends to use B3 for live jams/performances would feel exactly the same.
But yeah autosave NEEDS to be user selectable off and on, if i have it on it is normally set to an hour or something, in case i get in headspace and forget to save.
Couldn’t agree more. And as long as apps do crash I feel like it is an essential feature.
but even iPad pros stutter occasionally, especially when you're running high DSP with a heavy session of AUv3 plugins.
I get that, I've pushed my iPad Pro to the point where music stopped playing.
But that's not due to disk I/O wait, that's due to CPU bottleneck. A bottlenecked CPU doesn't automatically translate to a bottlenecked disk.
Also bear in mind that for autosave to work it's not just a simple case of updating a single data file. It also has to save any new samples, plugin states, and other dependent audio into the session folder, which will put a momentary strain on CPU and disk writes.
Unless you're writing massive amounts of samples in real time (we're talking multiple audio files that are hundreds of megabytes or gigabytes in size, etc.), you're not going to come anywhere near inducing the kind of I/O wait on the disk that bogs performance during any sort of jamming or live act.
All of which convinces me that I don't want B3 autosaving whilst I am in the middle of making music. I imagine anyone who intends to use B3 for live jams/performances would feel exactly the same.
I absolutely want it autosaving while I make music. Because when I'm in the zone, I'm not thinking about saving, I'm just making music. It's silly to cling to the notion that because you did it that way on a desktop, that you should do it that way on an iPad. An iPad is not a desktop, and it doesn't have slow spindles for storage like a desktop does.
Let's just agree to disagree on this point. As long as any future autosave can be disabled we'll both be happy.
Though I do enjoy a healthy debate
Then let's have one, instead of hiding behind veiled personal attacks and snide remarks because you don't happen to agree with what I'm saying.
It's fine to admit when you don't know everything. I never shied away from the fact that my swipe up could have caused data corruption, despite y'all's accusations as to otherwise. Still doesn't take away from the fact that I have had 3 such corruption incidents and I only force quit the app in one. More importantly, it still doesn't take away from the fact that no corruption of any file should be happening.
Your comments tell me you don't have a good understanding of how disk I/O works. I've done enough research and writing up of it to make my eyes bleed. Your scenario has no basis in reality or logic.
Yeah, close it. Nobody's hearing anyone, and the person you're asking to close it is who made it all toxic in the first place. Telling someone you'll "put them in their place" for "badmouthing" an app that they're experiencing a problem with is a good way to catch some hands in some places.
And you're right, I did say that; I kept getting sucked back in because I kept reading things that were just utter nonsense and thought I could dispel outright untruths.
You can delete my account, too. If I need any help with BM3, I'll just use Google. Worst forum experience ever.
I am in half a mind to let the thread stay open and watch this never ending self important uninformed drivel continue, but it has moved from me to @tk32 and now @tk32 is no longer playing, the dummy has been spit and it is back on me hahahahaha.
So yes i will close it.
@alteredmoods feel free to contact intua and complain.
Comments
@Martyreasoner i do not think autosave is an abomination, i think autosaving unsaved sessions is an abomination, you completely misunderstood again.
1 No app should EVER autosave unless the user has previously saved, autosave should then save to that saved file and create a backup of the previous save file, this is how all good desktop software works and is also good housekeeping, this gives just two save files (save and backup) and it is impossible to lose anything further back than your previous save/autosave.
2 No app should ever autosave on every change, that would be clunky as anything and near impossible to implement or use, saving isn't realtime.
3 Autosave spacing should always be a user setting, some like it at five minutes, some ten minutes etc.
4 Autosave needs to have a user set timed reminder for samples, if the user sets it to twenty minutes, every twenty minutes if there are unsaved samples a warning will appear "You have unsaved samples" note here that this does not affect autosave session, if that is set to two minutes it will still save every two minutes, but you cant have samples being saved on every autosave session, you would have no storage left after a few hours experimenting with samples.
5 For the obvious reasons of storage, samples should never be autosaved, but no 4 sample save reminder covers this perfectly, this does not affect audio tracks, those should either be in a temporary folder if it is an unsaved session, and moved to the session folders recordings sub folder when the session is saved, or if it is a saved session, saved straight to the session recording sub folder, the temporary folder should be flushed whenever the app starts.
6 On the subject of session folders, when you save a session, you should be able to name it and the session folder will be named accordingly, you should also decide where in the file structure the session is saved, not have to save the session, close the session, find it in the browser, move it to your session folder, and rename it, this is very very clunky behaviour.
7 No app should ever autosave unsaved sessions just to cow to people who cant be bothered to save, it is a completely nonsense feature that has caused no end of trouble (audio files in the wrong saved folder etc)
8 If autosave is to exist, then an indicator must clearly show to the user that it is currently saving, so that they dont force quit while saving.
9 This should go without saying, but not in this thread, Autosave should NEVER save while playing back/Recording.
So yeah, autosave unsaved sessions, abomination yeah, real autosave as above, lifesaver
Sorry i didn't see this post.
I have edited this reply because i did tell you to contact Intua to have me removed.
But then i checked other IOS forums...
AUM forum = Not strictly dead, but not very busy.
Nanostudio forum = Dead
Auria forum = Not dead but not as active as here.
Audiobus forum = Discussion of Audiobus dead.
Caustic forum = Dead
In fact the only forum busier than this one is Cubasis, and well, that's Cubasis lol, that puts us in seriously heady company hahaha.
So yep, your claims are complete and utter nonsense, you never were a regular poster and on checking back you got uppity after i clamped down on racist and sexist posts, so please, get over yourself and dont even bother posting if it is just to troll
Damn, seriously, second busiest forum in IOSville, OK boys and girls lets make a plan, we have to nail Steinberg hahaha.
@MSandoval disabling this system is not an option yet (hopefully just removed entirely for a real autosave, see points above)
Perfect example of why save after every change is not viable at all, in any realtime app.
Which is why you include checkpoints over the last period of recent time (minutes / hours / days) to fall back on in this kind of strategy. You get the best of all worlds: Immediate state save on the main file, checkpoints on that file if in the rare event a save causes corruption, and you still have control over your saves by Saving As.
Oh look, i typed this in my very first reply.
Full circle lol.
Personally, I wouldn't be in favour of autosaves triggering whilst I am jamming, recording takes, or twiddling automations.
Perhaps you could set it to trigger only after record or playback was stopped, but TBH I'd still probably disable this feature and keep doing manual saves
Yeah if you look at my list in the post above, i think number 9 is never autosave during record or playback.
But yeah autosave NEEDS to be user selectable off and on, if i have it on it is normally set to an hour or something, in case i get in headspace and forget to save.
Why would that matter at all in your case? I could understand if you were trying to use an early generation iPad but according to your profile you have one that can write to disk at a minimum of 250 MB/s and can typically read at 4x that speed. It just makes zero sense not to autosave with that kind of bandwidth.
@alteredmoods
It may surprise you to learn this but even iPad pros stutter occasionally, especially when you're running high DSP with a heavy session of AUv3 plugins.
Also bear in mind that for autosave to work it's not just a simple case of updating a single data file. It also has to save any new samples, plugin states, and other dependent audio into the session folder, which will put a momentary strain on CPU and disk writes.
All of which convinces me that I don't want B3 autosaving whilst I am in the middle of making music. I imagine anyone who intends to use B3 for live jams/performances would feel exactly the same.
Couldn’t agree more. And as long as apps do crash I feel like it is an essential feature.
That wasn't necessary
I get that, I've pushed my iPad Pro to the point where music stopped playing.
But that's not due to disk I/O wait, that's due to CPU bottleneck. A bottlenecked CPU doesn't automatically translate to a bottlenecked disk.
Unless you're writing massive amounts of samples in real time (we're talking multiple audio files that are hundreds of megabytes or gigabytes in size, etc.), you're not going to come anywhere near inducing the kind of I/O wait on the disk that bogs performance during any sort of jamming or live act.
I absolutely want it autosaving while I make music. Because when I'm in the zone, I'm not thinking about saving, I'm just making music. It's silly to cling to the notion that because you did it that way on a desktop, that you should do it that way on an iPad. An iPad is not a desktop, and it doesn't have slow spindles for storage like a desktop does.
Let's just agree to disagree on this point. As long as any future autosave can be disabled we'll both be happy.
Though I do enjoy a healthy debate
@tk32 said:
Then let's have one, instead of hiding behind veiled personal attacks and snide remarks because you don't happen to agree with what I'm saying.
It's fine to admit when you don't know everything. I never shied away from the fact that my swipe up could have caused data corruption, despite y'all's accusations as to otherwise. Still doesn't take away from the fact that I have had 3 such corruption incidents and I only force quit the app in one. More importantly, it still doesn't take away from the fact that no corruption of any file should be happening.
Your comments tell me you don't have a good understanding of how disk I/O works. I've done enough research and writing up of it to make my eyes bleed. Your scenario has no basis in reality or logic.
Not quite sure how to respond to your posts without making this situation worse. Though I do remember the start of a post you made here 2 days ago:
@alteredmoods said:
@5pinlink would you mind closing this thread? Unfortunately, I think it's gone a bit toxic
Yeah, close it. Nobody's hearing anyone, and the person you're asking to close it is who made it all toxic in the first place. Telling someone you'll "put them in their place" for "badmouthing" an app that they're experiencing a problem with is a good way to catch some hands in some places.
And you're right, I did say that; I kept getting sucked back in because I kept reading things that were just utter nonsense and thought I could dispel outright untruths.
You can delete my account, too. If I need any help with BM3, I'll just use Google. Worst forum experience ever.
I am in half a mind to let the thread stay open and watch this never ending self important uninformed drivel continue, but it has moved from me to @tk32 and now @tk32 is no longer playing, the dummy has been spit and it is back on me hahahahaha.
So yes i will close it.
@alteredmoods feel free to contact intua and complain.