Make SD card accessible as mass storage device

[n1LS]

To up-/download projects, themes, ... it would be very helpful to use the pT in msd-mode.

• An extra button "Mass Storage Device" under "Update Firmware" could boot into an msd-mode.
• in msd-mode the display could show an info "MSD mode, press any key to reboot"
• any key press reboots into normal mode
• unplugging the device could probably also trigger a reboot

[maks]

This is a good idea, but some questions:

1. why force a reboot? I don't see any reason MSD couldnt be a runtime option and then while its active the normal UI is locked out via a "MSD IN USE" fullscreen dialog, this is common mode of operation across many consumer electronics devices that support MSD like camera, audio recorders etc.
2. What will the UX be like given the limitation of USB 1.1 speeds. We have already discussed offline the slow startup time due to the host reading the entire FAT but also transfer speeds will be very slow. Transferring a even medium sized sample library is going to take tens of minutes

[n1LS]

1. Multiple reasons:
   a) Messing with the contents of the card while the device is running can cause unrecoverable integrity issues.
   b) Enumeration of a mutated USB device isn't stable without a reconnect on neither Windows 10 nor macOS. Rebooting solves that issue.
   c) With some more modifications a reboot would allow access to way more RAM, which could potentially still speed things up.
2. It heavily depends on your SD card size, file system (FAT vs exFAT) and host OS. Generally everything is limited by the USB 1.1 speed which ends up allowing ~800kB/s. Uploading sample libraries is not a great idea, while backing up and installing themes, projects (esp. sample-free projects ;-)) works very well.
   The first time connect to a (specifically) macOS device takes up to 60 seconds if macOS has not seen that card before:

• reading the FAT table is slow (happens on each connect)
• macOS adds .Spotlight and loads of other files to the SD which takes a while
  Using exFAT reduces this delay massively.

[maks]

Sorry @n1LS I don't agree at all.

1.a.) If the UI is locked out while running in MSD mode then there is no "messing with contents", in MSD the filesystem is simply unmounted by the firmware, simple as that.

b.) sorry no idea what "mutated USB" device even means in this context, can you please elaborate? I assume you dont mean that there is any issue remounting a USB MSD device after its been umounted by the host OS.

c.) How would more ram help? The bottle neck is the USB connection not the access speed of the sdcard, the need for more ram makes no sense at all.

2. I agree. Thats why what I have in mind instead of MSD access to provide limited access to some data like projects via a custom protocol by the remoteUI. If its under the control of an app instead of the OS's filesystem driver, that both allows for a much better controlled UX and performance improvements as well.

[n1LS]

a) I meant messing with contents on the computer side, not the pT side.
b) The issue is switching USB identity while the cable stays connected: the transition (CDC+MIDI personality -> MSC personality with different descriptors/PID) is not recognized consistently. Are there other ways of solving that? Possibly.
c) More RAM would obviously not help with the USB speed, but bigger chunks/more caching would help reduce the overhead with the access cost, lead to fewer stalls...

2. That's a neat high-level add-on for people who want to use a polished and limited way of doing this. It's not nearly as useful for people like me who something along the lines of rsync across a few devices.

[maks]

Ok well I think this has been useful: we've identified then that MSD for something like rsync is both a niche use case and will be a poor UX compared to: a dedicated ui in the remoteUI webapp along with existing sdcard removal for file transfer.

I've created #1432 to track that instead of the more general MSD proposal outlined here.