Tracker: Sointu does not load the actual latest song

[bsh-hub]

I have a Sointu song in git-repo. I then pull a new version of the repo from remote, which contains a new version of the song.

When I start Sointu tracker it does not load the actual latest version of the song. The title bar says that the file is the correct one, but Sointu tracker has loaded somewhere an older version of the same song (not the one which was pulled from repo). The older version of the song was loaded to tracker when it was closed last time.

Sointu tracker was not running when pulling a new version was done.

This was done in different machines. I updated the song on my desktop machine and then loaded it in laptop after pulling the repository.

[vsariola]

This is working as intended, but we can discuss if there is really need for a better solution.

Periodically and upon closure, Sointu stores its state into a recovery file. This is so that if it crashes (or DAW crashes etc.), it restores its current state from the recovery file. On purpose, it does not restore its state from the actual song file that was worked on, cause the user might have unsaved changes.

In principle, it could track the touched date of the song file, and if it detects changes in the file, ask if the user wants to reload it. But it should not do this automatically, as a lot of things might touch the "modified" timestamp of a file, resulting in accidental loss of work if the user made a song, closed Sointu assuming it will continue where it was, and Sointu would automatically reload the new file.

The best solution to this would be to ask the filesystem to watch the song file & notify Sointu if any changes have occurred while Sointu is already running. Then Sointu could ask the user "file on disk is newer; do you want to reload the file?" The API to watch files is unfortunately platform dependent, but there are libraries like https://github.com/sgtdi/fswatcher. However, that particular library for example has the problem that it can only watch directories, not individual files, which was the reason I never went forward with it.

While your case might be solved by checking for the file change once during program start, it is not a complete solution to the problem as the user might have Sointu already running, then do Git pull, and the same issue happens that the user continues to work on a version while a newer version is on the disk. So, the issue would only be completely solved by a file system watching mechanism.

Is this particularly priority for you, now that you know how Sointu works?

[bsh-hub]

Yeah. I thought something like that is going on.

I think just checking the state of the actual file when starting Sointu would be sufficient (for me at least). Just load the file what is mentioned in title bar and compare it and the one loaded from fail safe. If those are different, the user should at least get a notification about it. So that it would be obvious that version loaded from fail safe is not the same version that is currently in stored in the file mentioned in the title bar. User could probably have a choice which one to load. But I am not sure if the user knows always at that point which file is better. So maybe always load the fail safe and just notify that it is different from the actual file in disk.

[vsariola]

I don’t think comparing the fail-safe to the file on disk makes sense, because it will always differ if any changes have been made. That’s not how editors like Notepad++ or Visual Studio Code work. Instead, when a file is loaded or saved, they record the file’s timestamp. If they later detect that the timestamp has been changed externally (for example by Git), they then issue a warning such as: “The file on disk is newer. Do you want to reload it?”

One easy improvement would be to indicate whether there are any unsaved changes; for example, by showing an asterisk (“*”) next to the title, as in Notepad++, or another symbol (Visual Studio Code changes the X next to the filename to ●). This would be straightforward to implement, since we already track this internally in order to know whether to prompt the user about unsaved changes; we just don’t currently show this flag to the user.

[vsariola]

The easy part was done. The timestamp tracking not yet.