Create a song the usual way, using +, saving with a name, lets say TEST.
Play and loop with TEST the usual ways.
Next time I power up, TEST comes up, as the last song being used. But I want to play around with some new ideas … so I Hold the Play button and Delete all Tracks.
I create some little ideas, but nothing I want to save.
When I leave loop mode, I’m told I have unsaved changes, but I opt NOT to save.
Later, when I go to my song library, TEST is still in the list, but when I load it … there’s nothing there but silence.
That seems wrong. I never wanted to delete the SAVED version of TEST … I just wanted to clear it out of the looper one day.
Can you check that out and let me know if and why that would be good behavior for the unit?
Seems like we have gone round in a circle back to the beginning. Why save over it? Aeros is behaving in an unusual way if it treats your memory card as internal memory. That’s very dangerous, and destructive.
Some people want to be able to save an empty song because they will start that song over again when they play it, they don’t want to create a new song every time they play a similar performance. We do plan on making it easier to manage and identify empty songs in the future.
Deletion, from our view, should be treated as a final event, that will delete the files. If you wish to remove a Track and possibly bring it back, you should use the undo and redo commands within this song, deleting parts or a whole song is a final event.
I sorry but I have never heard of a programmer deliberately saving an empty track over a song without the song creator asking it to. That is really bad programming protocol. That would be called a bug, even if the programmer designed it that way. It would be called a bug because of its destructive nature to make you lose tracks you might have spent a week on… a deliberate bug… strange.
That’s not entirely the case, you can think of it as “saving” the empty song, but really it is just a song (think like a Pro Tools or Garageband session) that exists as a separate entity of the material recorded to it. Meaning you can have the same Song and have it change wav files as you like. “Deleting the song”, or clearing all tracks is a way to clear out the RAM and start over. If we do not clear the recorded data out, then someone who intended to delete the file may run out of space inexplicably. It’s not really a bug, it is a choice of structure, which is the typical logic for any DAW: a session (Song) with material recorded to it.
The thing we lack most is Save As to make the structure have a failsafe, the best I can say for now is do not delete a whole song/part unless you plan on deleting it forever.
You can trash a whole song session file from the Songs List screen, this will trash the session (Song).
You are confusing RAM with saving a file, they are not the same thing. You do not use someone’s memory card as RAM.
I’m told I have unsaved changes, but I opt NOT to save.
He chose not to save, but you saved anyway… using his card as RAM. Plus it doesn’t happen in any DAW in existence.
If you are saying that the Aeros has hardly any internal memory to work with then you would make a temporary file that doesn’t overwrite the song file.
The currently open song is never on the SD card directly it is always opened on the internal memory, so it is RAM.
Deletion is a final action, this clears the files that were saved onto the SD because otherwise there could be issues when saving the song you re-record. That would cause an unprompted deletion of files, I think it makes sense to delete with a prompt when you have no intention of bringing those files back.
There is an extraneous save prompt when leaving a song to the Main Menu that we need to fix, it is a polish, that is a bug. It is not something we have fixed just yet because we want to make sure anything we do is not going to introduce more issues. It has not been a priority.
That being said, we are wildly off-topic now, if you’d like to dedicate a topic to this specific issue, it may be more useful as more people will see it/ get involved .
What you are saying still makes no sense to me. In fact it puts me off using it. I don’t want to lose my songs.
Deletion is a final action, this clears the files that were saved onto the SD because otherwise there could be issues when saving the song you re-record. That would cause an unprompted deletion of files, I think it makes sense to delete with a prompt when you have no intention of bringing those files back.
Deletion should mean clear memory, not delete the file. You are very confusing.
Hold the Play button and Delete all Tracks.
To me that means clear memory… not lose a song you wrote previously, and saved to memory card. This is a very serious issue, and should not be ignored.
I might send my Aeros back if it is as bugged as that.
If you are confused I am sorry for that is on me, but this is more reason for a Save As mechanism, that would put this whole topic to bed. You could simply save a version and then do anything you want to that version and keep the files separate and safe when clearing.
The Aeros links the Wav files on the SD to the Aeros internal song session which is on RAM, if you have already recorded tracks to a song those files are linked on the SD and the currently open song on RAM. Currently, the Aeros deletes the linked files once clearing the song, this is part of how it operates. I could ask Dev about the specifics of why tracks need to delete the SD card file as well as the RAM version, but I imagine it is part of how it was designed. As far as if this is the best way to handle this, that is up to debate but that is only useful in a dedicated topic.
I’m not disagreeing with you, I am telling you how the Aeros behaves.
As to OP, @Quad are you still seeing this issue on your front?
The challenge for SS is that editing a songs settings is treated as a save (and that’s what the button says in the setting page) … which creates an entry in the song list … which leads to lots of scratch songs needing to be cleaned out later (and the hack of clearing the sog instead of creating a new one).
When you create a song for the first time, you don’t expect it to be saved in the song list … before you (record and then) explicitly save the song with the audio.
Yes, and that’s very wrong, they shouldn’t do it. Just because it’s a choice doesn’t make it not wrong. I could make a program that wipes a hard drive by choice… it’s still wrong.
Let me try to streamline the discussion of the points I raised earlier.
I think it’s reasonable for a user to be able to:
1, Create a new song and save it
2. Delete a song
3. Save an ‘Empty’ song (no recorded tracks, but tempo and other song properties)
4. Clear the tracks in the Looper, to start a new song.
It’s number 4 that seems to be the crux my problem with the status quo.
The analogy would be a program like Word. I could open a text doc, delete all the text, create new text, and Save As a new name. That wouldn’t harm the file I had initially opened.
The Aeros default seems to be to load the last song that was in the looper (at the next power up).
If I don’t want that song, but want to start a new one … I’d just like to be able to clear the tracks, mess around, and then (if I came up with anything good) Save As with a new name.
Presently, without asking me, the Aeros decides that my clearing the looper workspace = a desire to delete the song contents from the file in the library (without asking or verifying)
That is what I’m flagging as an annoying behavior that could easily be fixed.
The answer ‘All deletions are final’ isn’t what i’m looking for.
The issue there is that is not how the looper starts a new song. That is a deletion method. To create a new song, you must press the + sign on the Loop Studio screen, on the Songs List Screen, or you can send a New 6x6 Song or New 2x2 Song MIDI command.
Clearing the song is not intended to be a way to create a new song. It is for users who have no intention of saving what they just cleared.
We are working on methods to allow for handsfree non MIDI options like detailed in the Hands-Free mode
We also hope to soon add a Save As feature to simplify all of this and keep songs secure when wanting to make different versions of the same song.
That’s how you start a new project in all other programs as mentioned about Word. You are basically ignoring programming etiquette. Save As will not fix the problem either. A forced Save is your problem… no programs have a forced Save feature apart from into Temporary Folders.
I don’t mind creating a new song using +. We agree on that.
When I turn on the Aeros, it loads the last thing I was working on into the looper.
Here’s where I want Aeros to behave more like all other software.
I want to clear that auto-loaded track out of the looper (using the press-hold- Delete All).
I DONT want to destroy the saved track (that I didn’t ask to be reloaded)
I DONT want to necessarily be starting and saving a new song.
I JUST want to play around in the looper to see what I come up with.
If I like what I have, THEN I want to save it, with a new name, as a new song.
Presently, the unit erases the CONTENTS of a song I didn’t want to delete from storage, but it leaves the NAME in the directory (tricking me into thinking it’s still there). Only when I load it later and hear silence do I realize what happened.
It’s hard not to agree with @DHallowell, aeros is really weird in it’s save/load paradigm.
It pretty obvious that, at present, it functions as project-in-storage is different from project-in-ram. So like any editor application on a PC it should have new/open/save/save as/delete functions. Editing the currently open project meta or wav data should therefore not alter the project-in-storage. It should be possible to open the current project again and revert to the saved version.
This is unlike many other loopers which operate on a project-is-current paradigm. That’s where there are only new/select/delete functions. Changes you make in this paradigm always alter the stored project, there is no “RAM” instance.
The problem with aeros is it’s partially both of these paradigms. Pick one and stick to it.
Personally I think the second is the more fitting pattern because you shouldn’t be loading samples into ram anyway (that’s how you end up with 2.5 minute loop size limitations), your should be playing directly from secondary storage. But that’s just my opinion, I don’t think it’s impossible to implement an open-to-temporary system, it’s just considerably more complex (and your devs seem to have enough complexity to wrestle with already).