tape counter is reset on RESET, overwriting audio

[catfact]

since PR #1015, performing a dirty boot (via SYSTEM>RESET or after a crash) deletes system.state which will reset the tape file counter.

this seems not great to me since it will unexpectedly overwrite audio files.

two options off the top of my head:

• on a dirty boot move audio/tape to audio-tape-backup or whatever. (backup could be programmatically incremented.)
• instead of storing the counter in system.state, scan the audio/tape directory when starting a new tape, find the file with the highest index, and increment that.

[catfact]

another suggestion from @AndrewShike : store tape counter in a separate file which is not managed by system.state. the intention being to avoid duplicating filenames at all, for an arbitrarily long time.

[catfact]

reminder (to myself as much as anything): the reason we don't just use date+time stamps is that norns doesn't actually have an internal hardware clock, and is dependent on network time, so the datestamps were simply not predictable.

[GoneCaving]

Could you iterate over the existing recordings, take the max number and increment by one? It doesn't solve the confusion in the way that a timestamp would if there were predictable, but at least there's no overwrite.

Sorry, I see you've already suggested that. One other though tis that it might be nice to have the ability to set a global project name, and append the counter to that. It might help with the comments about confusion about which recording is which.

[tehn]

given that people likely want to move files off the norns i'm not sure iterating through the file list solves all the issues.

here's what i'm going to do:

• file dust/audio/tape/index.txt stores the persistent ascending index.
• on file arm, open a text edit window with the filename so you can append/edit the save file if desired. the default filename will be the index number.

[synthetiv]

This seems like a nearly ideal solution, but... would it be too much to ask to also display a warning in the textentry dialog if the filename that's been entered is already in use?

[simonvanderveldt]

given that people likely want to move files off the norns i'm not sure iterating through the file list solves all the issues.

here's what i'm going to do:

• file dust/audio/tape/index.txt stores the persistent ascending index.
• on file arm, open a text edit window with the filename so you can append/edit the save file if desired. the default filename will be the index number.

I'd caution against doing this. This is solving the problem the same way as before (keeping our own state/reflection of reality) which will inevitably break again one way or another.
The simplest thing that could possibly work would be to check the existing files and increment from there, simple, no way to get a state that's out of sync and no surprises.

Also personally I'd expect the numbering to start from the start when I remove all the existing files. Anything else would break the principle of least surprise to me and I'd consider a bug.

For the few people that keep all the tape files with the original name in a single folder (why anyone would want to do that that is beyond me though, seems totally unworkable) they can just make a directory before copying.

[tehn]

it's probably good to reflect on the accepted UI for saving untitled files on computers--- manual entry of a filename, and then the system prompts to confirm overwriting if the file already exists.

part of what i was trying to avoid was user text entry with knobs, but it seems good way to offer people some way to identify a moment vs. just a counter.

the counter persisting seems reasonable for convenience. the index file being deleted seems unlikely. and in case one is concerned, it'd be reasonable then to append the filename with a novel string. and if one wanted to have the tape counter reset after transferring, deleting a single index.txt file is a very straightfoward approach.

so in the end, i'm not confident that we're going to find a default behaviour that everyone is going to want--- and i suspect that this PR represents a good compromise: low risk of data loss and high opportunity for customization.