I played a live show with Norns for the first time in a long time. I recorded it to the device and in the morning, realized I never tried to do a simple copy operation on device without connecting to another computer via SSH.
Is this even possible? if not might be a cool feature to have a simple copy operation to whatever the first USB storage device is mounted on the filesystem.
usb system backup (still requires another computer tho) is buried in the docs, will make more obvious and add audio path and norns-only helpers (ty @andrew!), thank you for the q! help | monome/docs
mmm, just to be clear: this recommendation from the docs involves shelling into norns via the serial port and executing bash commands there. it still requires another host computer, though it has the advantage of working without wifi.
i think that saving your go-to bash sequences in scripts for offline execution is a fine idea.
ah, right, yep tired brain. just seeing the initial request was for norns-only. ignore the recommendation all! i’ll add these norns-only solutions to the docs, tho.
At the risk of getting too ambitious, which I’m aware is a trait of mine, this seems like a small enough thing that would be useful to many. I haven’t done any system dev on norns but it seems like it’s within reach for a weekend project. Am I being too ambitious?
When norns first shipped there was a menu item which would try to bidirectionally sync the entirety of the audio, code, and data folders to an attached USB storage device. The implementation didn’t work well for a few reasons so if was removed in favor of the SMB (and SFTP / Cyberduck) methods.
The biggest east shortcoming of the old sync method was the inability to control what got synced so it was quite slow.
I’m thinking of something simple like the sample loading menu but when a file is selected it copies it to / on the first attached USB device, which I think is /dev/usb0? This depends on that device automounting to the same location every time.
@zebra is this where I should be looking to add this function? I got a dev environment set up on the main computer but if I don’t need anything that requires a C compiler to change menus I could do it on-device. But then it might be weird for diffs/pull requests.
@tehn owns the menu UX design. I think first step is not coding, but a proposal for the new UX feature. (I guess if it were me I would probably add it to SYSTEM or something, I dunno.)
But yes, in general, a new function/feature for a menu page would go in norns/lua/core/menu/some_page_source.lua
so the previous implementation (which wasn’t perfectly stable) just sync’d dust to a usb disk which was more appropriate for backup and transfer. transfer is generally easier via wifi.
given many people have upgraded to 32GB modules, and the shield can have any size SD card, this external storage feature was perhaps deprioritized. USB disk transfer is inherently going to be slower, though probably not to the degree that it’d impact performance in most cases (@zebra correct me if i’m wrong?)
so more the point perhaps: how and where would you like to see usb disk support? the UI is going to be pretty tricky given the screen size and that we’d need to make a sensible navigation. FYI this all needs to happen within fileselect.
but there’s also an issue that a lot of the audio file paths are expected to live within dust/audio/ by design. so this might be a really messy feature to attempt to add.
i think the idea is something smaller in scope. for example, “copy the most recent TAPE recording to the first available external media, then delete it from the emmc to save space.”
i guess i would just make a script that does this, as @andrew suggests, and just make it bulletproof:
issue the copy command
checksum the copy with the original
if ok, delete the original
draw status and errors on screen as approrpiate
maybe loop over all the TAPE files and do this.
if it’s really solid, it could be added to a system function on the TAPE page. somehow. i don’t know how. adding UX to the TAPE page sounds a little tricky.
I’m forcing USB detection by pulling the status from os.execute("mount | grep sda1") – that seems to line up with “the first USB storage device mounted on the filesystem”, yeah?
seems to be working – returns error if USB drive is pulled during transfer or if drive becomes full, which felt like they’d cover the range of issues
deletion is not automated, requires confirmation, feels like the right move
I might just have a very slow USB drive, but looping over all the TAPE files (most of mine are 15+ mins) was not realistic so I opted for this one-at-a-time model. if someone with a more standard drive can confirm that large files are buttery, then i can adjust!
as a file transfers, norns will seem unresponsive until the transfer finishes and the script returns to latent state – this seems normal and unavoidable, but would love any tips to avoid!