SD card lifetime

[dazarz]

I'm wondering whether the algorithm of such frequent writes to the SD card won't lead to rapid wear and tear of the card. SD cards don't have a long lifespan in terms of write cycles. Perhaps it's better to add a FRAM memory module, collect MIDI events there, and then save them in one go on the SD card. What's your opinion?

[Pomax]

SD cards have a huge lifespan in terms of write cycles. Modern SD cards will last 10 years or more, and that's if you actually write enough data to cover the entire space (i.e. in a digital camera or a gopro etc). This device writes, at most, kilobytes at a time. Your SD card will easily last a century =D

[dazarz]

Thank you. I hope you are right. I have built the project lately as a start point for my recorder. As a long term Atari Notator user I love the feature of „always midi in record” (even if the record is not enabled) so it will be great to use it not only in Atari world. In my project I will add possibility to stop recording and play the recorded files as well as few more ones if the Arduino’s RAM allows. Thank you for inspiration.

[Pomax]

Remember that the recorder only writes to file if there's input, and even then it only writes data every 400ms. Otherwise it just sits there doing nothing until there's input to record again except for the resetting to a new file every 2 minutes, which is about as low file-writes you can get =)

That said: remember that the midi files aren't "done" when they get closed because their internal checksum will not be set yet (so anything that plays MIDI should flag them as invalid/corrupt). That's what the little .py script is for, but you could (if you wanted to invest that time) keep track of the checksum and then update it as part of the file close operation.

[dazarz]

Checksum... hmm... since the sdcard lifetime is not a problem, so what do you think about such approach:

1. Start recording MIDI events to a temporary file (.tmp) on the SD card during the recording.
2. Close the temporary file because the recording is complete.
3. After recording is finished, calculate the length of the temporary track (number of bytes) and other parameters such as time resolution.
4. Open the final MIDI SMF file and write MIDI headers (e.g., format information, number of tracks, time resolution, etc.) in the correct format according to the MIDI SMF file format.
5. Reopen the temporary file.
6. Read the content of the temporary file and write it to the final file, which already has the correct headers.
7. Finally, remove the temporary file (.tmp) because it's no longer needed.

[Pomax]

This is literally what already happens (the active file is the temporary file in your description), but with steps 5, 6, and 7 done using a Python script that will do this "for all files on the SD card in a single run". We could (almost trivially even) turn the python code into C++ so that when we close a file, we reopen it, compute and write the checksum, before closing it "for real". It would just make the swap from old file to new file take a few ms (at most) longer.