I own a Tonverk and I build small Mac apps for musicians on the side (It’s mono, yo! and It’s 404, yo!, both for sample prep). After a few months with the Tonverk my SD card is already getting away from me, and reading the SD card folders and filetypes thread here, it seems I’m not the only one.
A few things I keep bumping into. Files that aren’t 48 kHz load fine but play back with degraded quality, and nothing warns you. Presets store absolute paths, so reorganizing folders can quietly break them. Deleting or moving a sample breaks every project that referenced it, with no warning, which makes cleaning up feel like defusing a bomb. And backup is a manual Finder copy in USB disk mode, with no way to know the copy is complete and intact.
So I’m considering building a native Mac companion app for exactly this. It would scan the card and give you a browsable library of everything on it, with waveforms and the technical details that matter (sample rate, bit depth, mono or stereo, length). It would run a health check that flags the problems above in plain language. It would find duplicates, but never delete anything on the card itself, instead moving files to a quarantine folder on the Mac so it’s always reversible. And it would make verified, versioned backups instead of hope-for-the-best folder copies.
It would deliberately not touch projects, patterns or parameter locks. The project format is Elektron’s own and changes with OS updates, so this would be a companion, not an editor.
Before I build it I want to know whether this is a real problem or just my own tidiness anxiety. What do you actually do today to keep your card under control and backed up? And is there something about managing the card that annoys you more than the things I listed? Curious what you think.
good idea!
a pattern manager would be dope (chatGPT told me it’s possible to reorder them by creating a software, but i’m to afraid of bricking my TV by trying this…)
I can see checking drum and multi files is achievable but if I make patterns : projects and don’t save presets / instruments then it’s still impossible to audit loaded samples to check if they can be deleted .
Plus , if I used an lfo to play a range of samples then you can’t extract that data ( I think similar edge cases are dealt with in elkherd for digitakt )
So … start making a tool you’ll find useful and it’s likely others may too , but I suspect it’ll only be able to check easily read formats that are documented …
But tidying those up … moving samples and updating paths / file names could be handy .
Historically these tools have been made by the community , elektron focus on overbridge ( audio streaming , patch editing and management ) … nothing to do with pattern / sequence / step editing / project etc . Elkherd is the main one I’m familiar with ( others exist )
I think he’s had some support from elektron so perhaps if your tool develops you could approach them in some way .
Thanks! A pattern manager is the one thing I’ve deliberately ruled out. The pattern and project format is Elektron’s own, it changes with OS updates, and writing to it from the outside is exactly how you end up in the bricking scenario you describe. So the app stays read-only on everything Elektron-formatted. It looks after samples, folders and backups, and never writes a byte of project data. Safe pattern reordering really needs to come from Elektron themselves.
There’s a similar tool for OP-XY. Even though it was just released recently, I can’t live without it anymore. It’s awesome.
Similar to Tonverk, the OP-XY also suffers from absolute paths to folders and samples and doesn’t tell you which samples are missing or broken.
The OP-XY tool doesn’t just fix broken assignments automatically—it also bundles all the elements of a project into a handy zip file and provides some interesting statistics, such as the memory requirements of projects, which presets are used in which projects, which samples used the most and much more.
Check it out. I think it could be a great blue print for your own project.
You’re describing exactly the line I’ve drawn, and honestly better than I did. Reliably auditing which samples are in use isn’t possible from the outside (unsaved presets, LFO-swept sample ranges, all of it), so the app doesn’t pretend to. That’s why the duplicate handling never deletes from the card: files move to a quarantine folder on the Mac, checksum-verified, so if a project turns out to miss something, putting it back is trivial.
The move-samples-and-update-paths idea is a good one. It would mean rewriting paths inside preset files, which is the one place I’d tread very carefully since that format isn’t mine. If it ever happens it would be strictly opt-in and behind a verified backup.
Thanks for the Elkherd pointer, I didn’t know about the Elektron support angle. And yes, that’s the plan: I already have a working prototype of the scanner, health check and verified backup running against my own card, so I’m building the tool I need first and we’ll see who else finds it useful.
That one is already on the list, and you’re right that it doesn’t need to write anything. Presets store their sample references as plain absolute paths, so the health check can read those and flag references that point at nothing. The honest caveat: it can only check what’s actually saved to the card, so it will report the breakages it can prove and stay quiet about what it can’t see, rather than pretending to be a complete audit.
Thanks, I didn’t know opxy.app, and the parallels are striking. Same disease, different sampler: absolute paths and samples going missing in silence. The read-only indexing approach is very close to what I’m building, and it helps that the OP-XY community has open format documentation to lean on. Where I’ll stay more careful is anything that fixes files automatically, since that means writing into preset formats that aren’t mine. If that ever comes it will be opt-in and behind a verified backup. Studying it properly, good pointer.