Default snapshot missing and not loading

after software update -
the default snapshot entry is missing from snapshots - save
and after reboot does not load any snapshot.
is this great feature been removed?

please advice

any update - info on this issue?

It’s been transformed in “restore last status” feature, that you can enable from the webconf tool.
Anyway, i’m thinking about it because i’m not completely happy with it …

Regards,

Hi @BalamSoto!

I’ve restored the original “Default Snapshot” functionality. “Restore Last State” feature now uses a specific snapshot instead of “Default”.

Regards,

2 Likes

Where is the “Restore Last State” function in the web-conf? If I delete the default snapshot then teh zynth starts in the “Load Snapshot” page. I want to be able to go back to the last state before power off / restart but haven’t seen the feature for a few weeks.

[Edit] Doh! Found it (by grepping the source code) cunningly hidden at the top of the User Interface page. I looked there several times but managed to skip past it each time!!!

Webconf->Interface->UI options

The feature is there. In fact, i’ve fixed a little problem that was provoking saving/restoring of “empty snapshots” when no layers defined on power off. Please, update and test again …

Regards,

Ahhh! Don’t confuse “last state” snapshot with "default " snapshot :wink:

http://wiki.zynthian.org/index.php/Zynthian_UI_Users_Guide#Snapshots

Regards,

Cheers! I understand and now that I have found the config it works as design but… it only restores snapshots. It may be advantageous to restore the state of the Zynth rather than just restore the last loaded snapshot. (That is what I expected this function to provide.) If so, it would also need to allow override, e.g. boot whilst holding a button to restore a known good / default / empty state. Expect an issue in github soon…

It’s this what is implemented: “last state” snapshot is saved when powering off, rebooting or restarting the UI from the Admin Menu. When zynthian is started again, “last state” is retored.

Sorry for using an old thread, but I think my question is not worth its own thread:

For me it was not clear what happens when my zynthian started: Sometimes it recovered the last state and sometimes some previous state.

“last state” snapshot is saved when powering off, rebooting or restarting the UI from the Admin Menu.

But now I get it: I have to explicitely call the “power off command” in order to save the last state!

This makes it feel “unpredictable” for me (at least), because the zynthian is located with other devices in a rack (wifi mixer, guitar fx pedal, …). They are all powered off by “pulling the plug”.

And this is how the devices behave:

Wifi mixer
exactly restores all settings, fader postions, etc.
guitar fx
unsaved changes are lost
zynthian
well, it depends… it will restore some state from the past when you rebooted or restarted the UI…

I prefer one of the “clear” options:

  • “unsaved changes are lost” - can be achieved by disabling “restore last state” and use the default snapshot instead
  • “restore everything” - could only be achieved, if the “last state snapshot” is updated on any change to any parameter (or periodically compared to the current state…)

I will choose the “default snapshot” option, because that makes me more confident about what to expect after starting up zynthian.

But when someone wants the “restore everything” functionality (and also just “pulls the plug”), he might initially think, that he found a bug.

Is this worth to suggest an improvement?

… while thinking about it, I found a third option that is between “restore all” and “unsaved changes are lost”:
Restore the last (sub)snapshot and forget unsaved changes

This is exactly how the guitar fx pedal behaves: When you turn it on, it starts from the last patch you selected. When some parameters are changed and not explicitely stored, the changes are lost.

In order to have such behaviour in zynthian, you need to store the last selected (sub-)snapshot, whenever it is changed. When zynthian starts, it can then reload this (sub-)snapshot. Unsaved changes will be lost.

I think this approach has some advantages:

  • lightweight (store snapshotname/id when it is loaded. Restored when starting)
  • clean snapshot list:
    • no “magic” snapshot “Default” that the user has to know about and name it exactly like that
    • no “last state” snapshot which does not work when “pulling the plug”
  • clean and simple, what new users would instinctively expect

If it was up to me, I would select this approach and remove “Default” and “last state” snapshots.

I hope I’m not too confusing… :slight_smile: