It´s as simple as that, when you “save to new” you are not only saving the project with a new name, but also overwriting/saving the current project. Why would anyone would like that?
I´ve known this for years, but just asked myself (again) this question. Any ideas?
Saving a project and reloading it is the only way to return to a specific project state, otherwise all changes are autosaved…
SAVE TO NEW saves a copy of the autosaved active project state under a new name, it has no saved state unless you create one with a SAVE command.
When you change project it loads the autosaved active state, if you wish to return to a saved state you must reload project directly after, assuming you’ve performed a SAVE command on that project.
Thanks Mike.
I´m aware of the way it works. My actual question is “why would anyone would like it?”.
Many machines autosaves the current state, but that´s performed on a different temp project, not the current one.
The way OT works makes the “save to new” act like a “save + save as”.
My “workaround?” is to regularly “save to new” (very limited way of working in my opinion). So I´m still wondering if there is any benefit that I´m missing about this workflow.
Thanks again
It’s confusing they way they’ve termed it, but personally I find it very useful.
“Save to new”’ does not operate like “save + save as”, it just saves the active version under a new name. After saving to new you must also save project, only then can you reload that project to the state it was in when you saved to new.
I think of “save” as a restore point, you save it in a state that you would like to get back to. After that you can make many changes during live improv sessions and tweak away. Next say you like what you’ve tweaked but not enough to make it permanent, and want to change to a different project and do stuff there, then you decide to switch back to the first and would like to continue your tweaking session. When you switch to the first its just as you left it, you continue tweaking away everything, at last you’ve tweaked too far and you reload that project to get to your preferred saved version without the two mad tweaking sessions…
Elektron has designed these boxes to save a “base state” from where you can go absolutely nuts changing parameters, live recording, all sorts of mayhem, and have the choice to continue where you left off after changing projects, or return to “base state”…
Do you ever “reload project”?
Yeah, makes sense in your workflow of switching between projects. At least, you dont have to Save befor switching.
In my case, I only use one project. So when I make something new that I like, I can´t save, I always have to “save to new”.
I never “reload project”, so in my case I must never use “save project” (the only purpose of it is to reload it) and always use “save to new”.
So in case I want to save the current changes to a new project and after that get back to the previous saved version, I have to go 2 versions back (not just 1 because its exactly the same as the last one).
I hope I made sense here. English is not my main language so I cant really be as clear as I would like to be.
I understand only half of this, I believe it’s logical but I don’t get it yet. Could you please reformulate using “project one” and “project two” sort of references? Because “that project” , “save project” etc is a bit unclear to me. I just don’t get which is which here. Thanks!
If you understand how it works you could probably spell it out more clearly, I had a gig last night and only slept for an hour and a half, I’m surprised I even tried to answer this one at the moment… 
If not I’ll give it another shot… 
Say you start on Project 1, let’s say you have performed a “Save” command at some point on this Project 1 and since then you have made changes.
Now you perform a “Save as new”. Project 1’s active autosaved state is now “synced to card” which is the manuals way of saying its autosaved active state is now fully saved to the CF card.
Renaming as Project 2 with the “save to new” command you now have an identical copy of Project 1’s active state now in the form of Project 2’s active state and Project 2 is now active. Project 2 does not have a saved state at this moment, only an active state. If you start making changes on Project 2 there is no way within the project itself to revert back to the exact state it was in when you saved as new.
If instead you were to perform “save” project on Project 2 immediately after you performed the “save as new”, you then create a saved state for Project 2 that allows you to then modify the project thus changing the active state and then by performing a “reload project” it will load the saved state of Project 2 that you created and it will be exactly as it was when you saved to new.
If you then change project back to Project 1 it will load the “synced to card” active state it was left in, the same state that was “saved to new”. Since there was a “save” command performed on Project 1 at some point you have the option to revert to that by performing a “reload project” command. If you now “reload” project Project 1’s active state is now identical to the saved state until you make you first change which then modifies the active state version…
Phew… This makes perfect sense to me but it’s still confusing as all get out…
Yeah, I guess that does make sense and is a bit awkward for your workflow…
You could however immediately “save project” after “save as new”, and when you make a bunch of changes and like to keep them you “save as new” again and once again immediately “save” project after that. This way to get back to the previous version you only go back one interation and perform a “reload” project once you switch to it. This has the added benefit of if you don’t like the changes you make you can start over by “reload” project and it elimates having to have that extra project iteration.
Oh, thanks! I appreciate this. The last paragraph was what I had been missing. It makes perfectly sense. Bookmarked! (until it becomes natural…so many things to apprehend…)
Ok, so it seems I was not completely aware of how this works then! So you mean that each project has 2 save states at the same time: 1 user saved state + 1 auto save state ?
So if I save project 1, and then make changes on it, I will have those 2 states available? even when I switch to project 2 and get back to project 1?
Thanks again man.
i guess I’ll point out as well that “sync to card” should be done before ejecting the CF card to ensure you don’t loose anything, it’s really the only time you have to perform that function…
Yep…
If you look at the contents of the CF card you can see the .work files (active state) and .strd (saved state) files. Before you “save” project there’s only .work files.
I guess .strd must stand for “stored”. When I think about it that’s the right denomination. Everything is auto-saved in the .work file, and that state can be stored in a safe place. It certainly makes sense for a live orientated device that’s basically designed to destroy just about everything during performance.
That sounds likely, I thought about what it might stand for as I was typing that yesterday and nothing came to mind… Banks and parts work the same, you don’t need to save them as they are autosaved, but you can and then you can reload them, parts being the best for live as they are instantaneously reloaded.
I do believe it’s all designed for extreme manipulation and then reload to get back home, I love it that way, it’s perfect for how I operate…
That’s how I interpreted too.
I’m confortable now with the save and restore workflow, just one thingy that needs confirmation: when we do “save part” (or “save all parts”) are they stored the the .strd file or saved in the .wrk file?
I think it is saved in the corresponding bank.work file. Do a reload for test.
Wouldn’t that be illogical? I mean, we already have autosave for everything in the .wrk files. If we reload a project, it’s reloaded frome the .strd file. Why would we need to save parts the .wrk files if it’s already done by autosave? (I’m sure this question has been answered in the forum, sorry for this, I’m not in a situation right now to start browsing the forums, I’m having a band rehearsal and the question came up concerning our work in progress)