Save to new = save + save as (both at the same time) Why?

Elektron Gear Octatrack
#4

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”…

3 Likes
#5

Do you ever “reload project”?

#6

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.

#7

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!

#8

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… :slight_smile:

If not I’ll give it another shot… :smiley:

3 Likes
#9

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… :slight_smile:

7 Likes
Octatrack autosave
#10

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.

1 Like
#11

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…)

1 Like
#12

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.

1 Like
#13

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…

2 Likes
#14

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.

5 Likes
#15

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.

1 Like
#16

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…

1 Like
#17

That’s how I interpreted too.

1 Like
#18

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?

#19

I think it is saved in the corresponding bank.work file. Do a reload for test.

1 Like
#20

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)

#21

:coffee:
If you want to reload a specific state of a part, you have to save it.
The “saved state” of parts is not auto saved.
The actual state of parts is auto saved.

Edit : I checked. If you save a project, then save a part, then reload the project, the part is not saved. So I think parts are saved with bank.work files.

2 Likes
#22

Thanks!!

BTW, it would be so much clearer (to me, at least) if Elektron named these functions/states differently: “store” (and it’s counterpart “restore”) and “save”. Sometimes I feel like they made simple stuff difficult to apprehend to maintain that “deep” aura that surrounds their products. I mean… trigless trigs… WTF… on the other hand, we can buy meatless meat and cheeseless cheese too… oh well…

1 Like
#23

Well, trigless trigs are especially irritating, because in comparison to lock trigs trigless trigs may indeed trigger (envelopes).