- Santa Barbara CA
- Last Active
- No Roles
- Santa Barbara CA
Yes, the Downrush tool exists, but it requires the FlashAir card and software, which is kind of finicky to set up, and doesn't work terribly well in a lot of common environments, especially since the Deluge box is basically a Faraday cage, so WiFi connectivity can be pretty bad.
I think it'd be useful if the Deluge provided a small suite of SysEx commands to allow reading and writing files from the internal storage. You could implement the universal "Patch Dump" and "File Dump" commands, but that only solves about half the problem, and aren't really geared towards a complex filesystem layout like the Deluge uses (I don't think). Since everything on the SD card is either an XML file or a WAV file, stored in a directory hierarchy, it might make sense to implement something more general purpose. This could then be used by tools like DownRush (or a future Synthstrom editor/patch librarian) to manage the files on the Deluge in a more user-friendly way.
I was thinking something like an HTTP-style GET and PUT interface, using URLs like this:
(sysex header) GET file://SYNTHS/ (sysex end token)
would get the list of SYNT###.xml files, and
(sysex header) GET file://SYNTHS/SYNT033.XML (sysex end token)
would return the contents of the XML file in a SysEx message from the Deluge
(sysex header) PUT file://SYNTHS/SYNT033.XML ... (sysex end token)
would allow the PC to replace an existing preset (or make a new one)
You could also implement DELETE, and possibly HEAD (if you wanted to support querying metadata about the file).
Because samples are so much larger than presets, you might want to have a "file chunk" message, that could be sent repeatedly to build up the sample a chunk at a time without flooding the Deluge with a few megabytes of MIDI data in a single message.
I was originally going to suggest that the Deluge should "just" show up as a mass storage device when plugged into the computer, but the more I thought about it, the less I liked that idea. Since both the Deluge and the PC could both try to update the filesystem at the same time, you'd have to implement some kind of layer on top of the actual filesystem, making sure that the PC always sees a consistent view of the filesystem, and you'd need some way to refresh things after the deluge writes something. And you'd inevitably have issues with the CPU and flash bandwidth if someone tries to upload/download large samples while playing...
Implementing “HTTP over SysEx” would be a supremely-nerdy solution, to be sure. But it’d have the advantage that there are already a bunch of off-the-shelf libraries to handle the details, and it’s all text, so easier to understand and debug than a proprietary binary protocol.
Even if not going quite that nerdy, a path-based get/put API would still make a lot of sense for the way the Deluge’s storage is implemented.