to ease the workflow of developing patches on the desktop and transferring to the MM.
it would be useful if the MM could present patch storage over a simple usb cable. i.e. MM present itself as a usb mass storage device.
ofc, I recognise as wifi module is going to be made available, but with a rack limited in space, thats extra HP.
another FR mentioned having the MM presenting as a usb audio interface.
and you mentioned whist difficult, it was technically possible.
so that implies (to me) , that whilst the MM is capable of being a usb host (e.g. hosts midi devices), its also capable of being a usb device (required to be a usb audio interface)
ā¦ or did I miss something?
2 Likes
would definitely love to have direct patch transfer over usb cable feature. this would make the testing of patches go much faster when iterating a whole bunch to get the more involved, cpu hungry patches well oiled to work just right on mm
1 Like
I made an attempt at this, using the MetaModule as a USB MSC device in earlier firmware. But it wasnāt workable how I had it and I havenāt figured out a way to make it work without having a few inconvenient non-intuitive speed-bumps in the userās workflow. So, there needs to be a mechanism to hand off control of the drive between the host computer and the MetaModule (both canāt mount a drive at the same time). Probably the host can eject the drive to give control to the MM, and the MM has a button somewhere to unmount and pass control back. Slightly inconvenient, maybe not a big deal?
Also, there is no non-volatile storage to back the volume. I donāt think having the drive be backed by the SD Card is a good idea because the MetaModule would not have access when the host has it mounted (and the USB jack is plugged, so thereād be no way to save a patch except to Internal). I had it running as a RAM Disk, but thereās itās very frustrating if you forget to manually save your patch onto the SD Card because itās lost completely when you power down (unless you remembered to make a backup on the computer). Maybe it could be set up to automatically backup the RAM Disk to the SD card when the MM gains control, but thereās another layer of complications in that, tooā¦
Iām willing to try it again, but what I found was that the workflow was not an convenient and streamlined as I initially thought it would be.
An alternative would be to use a serial protocol to do what the Wifi Expander does: it runs in the web browser and has buttons to transfer files from the host to the SD Card, USB drive, or Internal drive. Thereās no risk of write contention. Itās not as convenient as a FAT filesystem because you canāt save directly from VCV Rack to the drive, but you could transfer files back and forth without plugging/unplugging anything or forgetting to eject or click a button on some screen. The Wifi Expanderās protocol is open enough that this could use much of the existing code.
But, the Wifi Expander modules are being produced right now, and using one of those is much more convenient than any of these ideas.
3 Likes
I dont see it as too bad, as you still have the patch in vcv (desktop), you are not losing everything.
also, could you not force the save on āejectā of the usb diskā¦ you know the client has disconnected, and you have it in the āRAM diskā?
but if mass storage is not possible, then indeed perhaps a serial protocol would be goodā¦
basically have the meta module desktop module, have a serial protocol which communicates with module - e.g. āsave to moduleā
this would also be useful for allow other information to be sent back (e.g. cpu load) to desktop from module.
i.e. I see this as opening up a workflow that goes beyond simple files.
(one day, long term 
, you might even be able to do something like live patching)
as I said, I understand you have the wifi module, but you might not have space in your case.
I also, frankly, prefer wired connections for this kind of thing, often its a bit less hassleā¦ that said, obviously not tried your wifi module yet, so it might be great 
1 Like
sadly no more space in my skiff for any new modules, but now im thinking, maybe i could just leave one mm unscrewed on the side and have the expanderās power cable weave out from the crack there, w expander floating outside the skiff, only plugged in when needed, depending on how long the power cable is. not pretty solution but might just be able to make it work after all
Thatās true, you could still re-generate the patch file from the original VCV rack patch (unless you also saved the .vcv file on the RAM Disk, which is not unreasonable thing for someone to try ā though some/most OSās will complain if you have open files on a disk youāre ejecting).
Yeah, it could save a backup to the SD Card when it detects the host computer ejects the disk. Assuming an SD Card is present. Also could backup when you click āunmountā on the MM before you give the host access.
Itās all possible, just not as streamlined as I initially thought/hoped.
Youāre right the serial protocol opens up more than just file transfer: (this is all very far off, butā¦) you could preview a patch, maybe even edit it.
2 Likes
Yeah, this is ākind ofā how axoloti works.
Created a pretty nice workflow.
As you already have the MetaModule desktop module, it does make a lot of sense.
Btw: one nice feature axoloti allowed , whilst you could not ālive patchā , any parameter changes you made in the editor would be reflected āliveā in the hardware ā¦ made fine tuning parameters very easy.
Anyways, I do think this is probably the best mid/long term route (imho)
Note: the axoloti workflow was heavily influenced by the nord modular and its editor. So thats a good source of inspiration too.