Hi,
When I delete a module from a patch and then load the same patch again it doesn’t load all the modules (the deleted module is not present).
Here a video showing the behavior =
https://drive.google.com/file/d/1KSAgusiMMjXPtH7btAfmPe5UasR8zg-m/view?usp=sharing
I’m on FW 2.1.17
Thank you for your help.
FYI same behavior with other patches (as of the “non official” integration of the Vult modules in the plugin downloads)
So, doing “Reload” from the file menu does not bring back the deleted module?
The video isn’t working, it says “File is in owner’s Trash”
Hi Dann
please find the video here : https://drive.google.com/file/d/1D96hbw80IjvcNayOQMrHnva3-HpDLUMv/view?usp=drivesdk
OK, I see. Yes, the module is deleted and so it stays deleted when you open the patch. Clicking on the patch name just opens it, like clicking on a window or browser tab: it does not reload from disk or undo any changes you made.
If you want to undo the deleted module, and get the module to come back, then go to the File Menu (disk icon at the top of the patch in the button bar) and click “Revert”. This will revert the patch back to the last saved change.
Thanks for the explanation.
Would it be possible to have the choice also for a « total recall » by loading it?
Because I find the revert move to be quite confusing. And it means (in a way) that every changes that happen in patches are « saved » as is until a reboot of the Meta.
It’s like if I change a value or delete a module (by intention or mistake), load other patches, then load the first patch I can get lost.
Recalling the original patch by loading it would be simple, fast and corresponds to the « norm» of any programmable file (from Excel spreadsheet to synth presets).
Moreover with the newly possibility to address patches with midi program change it would be usefull in order to perform snapshots.
My 2 cents.. 
Hi again @danngreen
I tried to load another patch and come back to the previous one and it doesn’t recall the last saved state of the patch.
So as of now last saved version of patches are recalled only at boot up (or by going to revert which takes more clicks to get there and less intuitive) which feels like a limitation for such a cool device.
I have experienced the same confusion that @guitooo describes — it does seem reasonable for the user to expect that loading a patch will … load the patch, i.e. read the patch file and implement it. On the other hand obviously you have to be careful about overwriting current state.
One way to square the circle would be: If the user goes through the load process and selects the currently loaded patch, the MM displays a dialogue saying “Revert to the last saved version of [patch name]?”
Hi Gabriel,
That could work but you’ll loose immediacy.
I really want to be able to do snapshots in reloading my original patch as fast as pressing the patch in the loading section. Plus if you use midi pc program to change your patch it won’t work.
the overwriting risk is zero if you backup your SD card 
I think “immediately reloading” is what the Revert command is for 
Sure but if I do some modifications on a patch (intentional or mistake) and say I load another patch and then go back to the first patch, I have to do another step by reverting the first patch.
Fast snapshots won’t be possible and recalling via MIDI Program Change won’t work.
Am I missing something?
That’s true. This was discussed on this thread.
Dan mentioned this idea, which I think would solve your problem:
I also considered a “Simple File Mode” that automatically closes patches when you load a new one, and prompts you to save or discard if there are changes. Less powerful but maybe more intuitive or expected (e.g. Rack only lets you open one file at a time).
Recalling via MIDI PC works even if you have unsaved changes. The latest state of the patch is loaded, whether that’s saved to disk or not. Whatever the patch was doing the last time you played it, that’s what it will do when you load it (whether via MIDI PC or by clicking its name).
I can see you’re wanting a different workflow, where each patch represents a “saved state” that you can jump to, play around with (changing things, presumably) and then revert back to that “saved state” quickly. That makes sense, but it’s not directly supported in firmware. The current model is more like a computer with a bunch of files being open: you can bring different windows to the foreground without losing your changes in the background windows.
In the “saved state” kind of workflow (i.e. if we made it load from disk each time): 1) it would add some latency when loading patches (not much for simple patches, but substantial for patches with large sample files or modules that fill big memory blocks with data), and 2) there’s an element of danger lurking: if you were working on a patch, and accidentally press “Back” or sent a PC from your MIDI controller – BAM all that work is gone – no popups or warnings.
For people that only create patches in VCV and use the MetaModule strictly as a patch player, this probably isn’t an issue. But for those who use the MetaModule as a patch creator it’s going to make for a lot of anxiety because one false move could wipe everything out.
This could be a user preference, like the “Simple File Mode”. If patch loading times was too long, then that’d just be the price of that workflow (you’d want to only use patches that can load quickly, which most of them can). We would need to make sure the differences between the current mode and this other mode are well explained because it leads to some real non-undo-able surprises and frustrations.
Another line of thought, is to actually implement “snapshots”. Instead of thinking of a patch as a “snapshot”, you could create multiple snapshots for each patch. This would save all knob positions, internal module states (and perhaps cables?) for a patch. You could jump between states quickly from a list or with external gear (could be a variety of ways-- MIDI PC? CC? Notes? Button Expander buttons?), and probably even tie it to MIDI PC patch loading to jump between patches and states quickly. There’s some loose ends with this (like, we still have the notion of an unsaved “state”) but it might be more what you’re after if you find yourself jumping between different knob/switch positions of similar modules patched together.
Thanks a lot Dann for this clarification and suggestions
I really didn’t know how the Meta patches were in the background as computer apps
If it favours low latency that’s key for sure
I’ll try some workflow for snapshots as you mentioned
As you wrote, if there were an option to choose the « Simple file mode » that be best of both worlds 
Thanks again Dann
