You can turn it off, turn it on, and it’s all there when you get back.
But, when you open the project manager and open a new project, but then chose NOT to save while switching, because you’re stupid enough to believe it’s saved a thousand times already over the last week or so while you’re working the best piece of music you’ve ever made …
no luck, load back the previous project and it’s empty-
There’s something weird about the whole project manager. You can’t create a new project, for example, you must find a slot “init a new”, then " load from" and then perhaps “rename”…
Sorry for the rant - just discovered this - perhaps I’ll save soneome from doing the same mistake!
My interpretation is that it continuously saves to some temporary location, not to the formal, load-able slot. It then occasionally saves to the slot: when you power down with the switch; when you manually save; when you save-before-load.
There’s a few other temporary save slots, such as the one that lets you re-load a pattern.
I don’t find it that confusing, but I also don’t feel I have a firm grasp on it. Similar to the recent macOS “automatic save” workflows… if’s not how it was when I was younger, and I think it was simpler and easier to understand (even if more fragile) then.
But still weird that there is no simple “new project” - right? Must be because there is a set number of available slots, and slots may- or may not have projects in them. So, does not resemble a “file system” as such…
Based on my experience and experiments on the model:cycles, I think that’s right
Not sure that’s 100% right (again, based on model cycles). When you power down with the switch I don’t think it saves to the project slot, I’m fairly sure it saves it as a work-in-progress project, separate from the project slot, and restores from there on power up. I agree with the rest.
Of course, it might be subtly different on the digi boxes.
Yes, the Digis and Takts never auto-save to the project slot. You have to do that manually.
It is, in my opinion, the best way to implement that feature and I think it is actually very user friendly.
Think about it, if Syntakt always would auto-save to the project slot and at some point you mess up and want to go back, there would be no way to do that because your changes might already be permanently saved.
The whole auto-save feauture would become a massive PITA. In order to always being able to restore your project to a state you are happy with, you would have to make a copy of the whole project before making any changes.
The way they implemented it, you can create a project, mess around until you like what you’ve done and save to the project slot. Then you can go ahead with twiddling the knobs and mindlessly making changes. Don’t like the outcome? No Problem, just load from the Project slot! Or maybe you want to save it but still keep the old state that is saved in the project slot? No Problem either, just save to another slot.
Don’t go to “manage projects” to create a new project. Go to “Load project”, then go to the last spot in the list, there you will find “create new”, select it with YES.
If you have a long list of projects, press the Level/Data encoder while turning it to scroll faster through the list or press FUNC + the down arrow to do the same.
The new project is now open and you can edit it and make patterns. However, it is not yet saved to the project slot. As always, you have to do that manually.
100%. This is the business of loading up good to go projects to do a performance, mess around, destroy everything musical about the project, but then reload the project and you’re good to go for the next set.
Surely tho, if you haven’t explicitly saved the project at least once (i.e allocated a slot, given it a name etc), then where would you expect that project to be, and how would you expect to come back to it, if you start/open a different project? And why would you explicitly choose not to to save the project when you are given the option to before exiting it and starting a new one? I’m not having a dig, i’m genuinely curious when this sort of question is raised. Maybe because i am extremely crisis-averse when it comes to saving/losing unsaved projects that its always the first thing i did when starting new projects, and would periodically save every time id added a new adjustment that i knew i didnt want to lose. For me, the concept of turning off a machine without ensuring i’d explicitly told it to save gives me the heebie-jeebies
@sezare56 I come from Octatrack, it was my first piece of gear -so I’m kind of used to that workflow. I create a new project, I can turn on- and off my machine at any time, when it comes back up -everything is there.
Google Docs, and most editors nowdays saves the document all the time. But not the Syntakt Text edtitor.
Imagine the Syntakt is a text editor; called the Syntext.
I work on my document, I close the window, I come back- next day - write some more. Almost done with my document. Close my document. No worries
I decide to take a look at another document - open it, Syntext asks me, do you want to save the document before you open the new one? Ehh… Okey? It seems to be saving my document all the time - so why??
I say no, and when I open my document the next time; it’s BLANK, sine I never explicitly saved my document that seems to be automatically saved all the time.
I’m not saying the Syntakt model is not useful, I’m only saying it’s kind of unexpected and that it kind of breaks the User experience “norm” or generally applied UI design pattern in regards to both having explicit saves and automatic saves.
I know there is a prompt, there is even two of them - the second one is even of the type “all work will be lost …” - I’m not saying there isn’t enough warnings or idiot proofing. I’m just saying I question the usability / user friendliness of project management and how the explicit saving vs auto saving works.
I can see both sides. The way it’s done has benefits in performability. BUT there’s no denying that people new to these boxes get caught out, it happens over and over again on the M:C and M:S … usually associated with an unexpected power-off … maybe the digi boxes are subtly different in this respect, I don’t know.
