Any editor (text/graphic/music/movie) offers closing without saving but GB auto-saves everytime we go to select another song or create a new song. Any mess up in the current is automatically saved!!
Any regular way to quit the current project will autosave it on an iPad or iPhone, iPod (switching to the project view, switching to anouther app).
A brute force way to exit the current project without saving is to reset your IOS device (hold down the Home button and press the Power button at the same time, until the phone restarts). This will quit GarageBand without auto saving the current project and you can open a different one after restarting your iPad.
I got into the habit of duplicating a project, before starting to edit it. This way I always have a backup copy to revert to, if I do not like the current version.
Even the song editor is half-baked. It is very delicate. While pasting, it trims other sections, overwrites other sections. How about inserting and pushing other sections to the right instead of triming them?? That's how an editor should work.
GarageBand on the iPad is a very different application from GarageBand on the Mac. The mac is more version is better designed for creating and editing song arrangements, and the iPad version focusses on playing the iPad as musical instrument.
How about sound effects?
There are some basic loops, and you can import any audio file you have in the Music.app to add effects.
I'm a programmer and know it takes no more than one line of code to offer the user options to save/abandon changes before (auto) saving the file and save only if the user answers Yes to save. Just one line - that's all there is to it. What does it matter to abandon changes if the user does not want to save them? What were Apple engineers thinking? Do they even use GB?? If they do, they would have noticed how stupid this shortcoming is. LOL
Tablets are meant for content consumption - reading, listening, watching, playing, etc. But tablets are the becoming the FUTURE of content creation when it comes to music (eg: NanoStudio), movies and art (eg: ProCreate, Drawing Pad). NanoStudio offers the desktop versions for free but charges for the iOS version because we can work more easily with the iOS version than the desktop version. And Nano's song/track editors do not suck (full functionality even on iPhone/iPod versions!!) like GB's do - but GB on iPhone is barely anything. It doesn't hurt Apple to take a leaf from other apps. Apple could do better than Nano.
How can we have a guitar, strings, etc instruments?
If music creation is such a small part, Apple would not have cared to create GarageBand for iOS and that to, with so many exhaustive features. You would be ****** off if Pages/Numbers/Keynote did the same autosave without giving an option to save. Maybe, thousands of users don't know there is a feedback process or Apple forums? If there is one dumbest flaw in iOS, it is this - not giving a dialog to save/abandon GB file which takes just one line of code. So wvent your opinions and submit feedback:
If there is one dumbest flaw in iOS, it is this - not giving a dialog to save/abandon GB file which takes just one line of code. So wvent your opinions and submit feedback:
There are two differences that you may want to consider:
- A GarageBand project is a is a project with databases and audio files, and not a document, like iWorks documents. In all Apple Software versioning (to be able to revert to a previous version) is used for documents, but not for databases and projects - for this kind of applications (iMovie, iPhoto, Filemaker, Final Cut) all changes are applied immediately and the old version is not saved.Only document based applications preserve a version history.
- There is a big difference between designing applications for small handheld devices with limited amaount of storage and computers. You have to be really frugal with storage requirements on a handheld device. Keeping a copy of a GarageBand project to be able to revert to it, will require a lot of storage, if you have many audio recordings. That would be no problem on a mac, but a big challenge on an IOS device.
So I think, that Apple's decision not to include a "Revert" option can be justified, even if you do not like it. IOS devices have other requirements for the software than full Mac versions.
Dealing with data-based apps should not be hard maintaining two sets of rows (original and temp). On opening a file, the app should duplicate all the original records in the table into a temp set with a different ID, work on this temp set of records in edit mode. When the user wants to close, flash dialog to save/abandon/cancel. Save will overwrite all original set of rows with temp set of rows and delete temp set of rows OR delete all original set of rows and rename temp set of rows to original. Abandon will just discard/delete temp set of rows retaining the original set of rows. Cancel/Dismiss will keep the user where he is and do nothing.
Here is another way:
How do we edit a GB file on an iPad now wiithout affecting a masterpiece in case we want to backoff any edits? Make a copy and work on the copy or if we forget to take that action, the only way to backoff is to RESET the device. This is ridiculous as all of this can be done by the app itself behind the scenes - make a copy, work on it and if the user wants to save the work - overwrite the original. In either case (Save/Abandon) delete the copy. Storage should not be an issue as we are already doing that manually already (make a copy, work on the copy).
When we edit a file, we read its contents into memory and edit the string in memory. Save action will overwrite the source file with the string in memory. Simulating this behavior in databased apps should not be be as hard as it seems.