[yoshimi] Re: Saving before close

  • From: Will Godfrey <willgodfrey@xxxxxxxxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Fri, 24 Jun 2022 21:40:40 +0100

On Thu, 16 Jun 2022 09:02:00 +0200
Lorenzo Sutton <lorenzofsutton@xxxxxxxxx> wrote:

On 15/06/22 17:33, Will Godfrey wrote:
On Tue, 7 Jun 2022 13:04:24 -0300
lucas <lucasfilipe@xxxxxxxxxx> wrote:
  
Hello everyone,

I'm trying Yoshimi with the last improvements and it's getting very
good. I have one suggestion for next: a confirmation warning when we
close the main window, like "would you like to save before quit?". And
an automatic saving also would be good when the program crashes.

Best regards,

Lucas  
Coming back to this...
It would be rather unsafe saving on a crash as you could end up saving a
corrupted file on top of a good one (and not always possible anyway). 
However,
a timed auto-save is what a lot of programs do, and we should be able to 
manage
that without too much difficulty.

Things to decide though:
What exactly should be saved? Patchset or State?  

I vote for State (as usual :-) )

What to do if no file has yet been saved at all?  

wouldn't an auto-save file be saved anyway if this is enabled and stored 
in some known location?

Could some information be simply coded in the auto-save filename? Or is 
that too naive and the software should keep track of this somewhere?

I've been mulling over this off-and-on for a while now, and think this really
is two separate issues that should remain separate.

Disaster recovery is in some respects the 'easy' one, so this is how I think it
should work.

If autosave is set, then at the wanted time cadence a state file should be
saved to a fixed location. If at that time no user save actions had taken place
it would just be named autosave. If a save action had taken place, then
alongside there would be a small text file containing the complete file path
of what had been saved. Even if only (say) one instrument had been changed it
would still regard this as a state change.

On a normal exit, these files would be deleted.
Any load, save or reset would also clear these files.

On any later start these files would be looked for, and if present you'd be
notified of their existance and offered the chance to load. The caveat is that
if you decide against this, then stopping again would delete them. The startup
message should warn of this, so if you've any sense you'd immediately save!



Notifying an unsaved change is more complex. This is because state, patchset,
instrument all overlap. State also overlaps vectors, MIDI-learn and scales.
(We already have the basic config file covered)

At the moment I've no idea how we should deal with this.

I don't think any of the above is relevant to lV2. It should be handled by the
host (as a state save).

That's the best I can come up with at the moment.

-- 
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Yoshimi source code is available from either: 
https://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: