Patch : autosaves?

Bug Reports and Fixes
1

I had a patch that overloaded the cpu.
it was pretty limited, so I was a bit surprised.

so I wanted to see which module(s) was causing the issue,
by removing one module at a time…

then the idea was, Id reload the patch, and try to remove different module.

however, when I reloaded the patch …
the module Id deleted was gone
the MM had overwritten patch file ‘automatically’

Id not hit save.

I don’t know if this is intentional, but I don’t think it’s a good idea.
as there many reasons you might wish to experiment with a patch before committing to the change for good

and you’d expect if you didn’t save, then you’d be fine.

2

Maybe this could be dealt with in either a global, or patch-specific, setting for whether you want autosaves or not. The latter would probably be better because it would accessible on the same screen as your module edits.

I’m glad I don’t have to save stuff. My Zadar drives me up the wall because, after three years, I still frequently forget to save before powering down the system.

3

sure, in some cases autosave is nice…
but, personally, I prefer to have control over such things.

anyway… all that said, Im slightly confused about what is really going on :slight_smile:

I just noticed there is a ‘revert’ to which indeed, reloads the original patch from disk.

what it actually looks like, is the modified version is kept in memory even if you switch to a new patch…

and loading for disk, will bring back the original version…
so its not autosaving?!

so, it probably was not saved to disk last time… but I thought it was, as when I reloaded the patch the changes were still there.

note: there is a red dot in the recent list next to patch name, which I presumes is suppose to show … there is an in memory change that has not been saved.
correct?

anyway… I think I get it now… but I also think I wont be the last to be confused by this :rofl:

1 Like
4

We’re both confused then. I shouldn’t have replied without checking the module, which is not with me at the moment.

5

I had a (deeper) think about this whilst walking the dogs…

first its not a bug , so this could be closed.
rather the way it works, a feature… albeit I found confusing initially.

here is my understanding.

  • when you open an patch in MM it is read into RAM.
  • it stays in RAM even when you open another patch (or create a new one)
  • these in memory patches are what appear in ‘recent’ list of load patch
  • they have a red dot alongside them if they are modified (and not saved?)

actually this is very flexible way to work, as it means switching between recently loaded patches is fast… as it does not have to do to disk.
also I suspect it means you can remove sd-card whilst module is powered on.

you are also able to ‘revert’ and any time to the disk version.

so once you know whats going on, its actually very powerful .

BUT, if you don’t know I think it can be confusing.
why?

  • open new → close old
    we are used to computers ‘closing’ documents when we open new ones.
    yes… we have different tabs, but thats different as they are run in ‘parallel’
    i.e we know we have to save to avoid loosing work.

  • dangerous?
    its be very easy to modify a patch, switch to a new one , and forget to save.
    power off module, and you lose change
    in conventional approach, you open new doc/exit app , you are prompted to save!

again… once you know whats going on, its a non-issue,
and I actually like the way it works.
(and for the future it offers some interesting possibilities esp. for live use, e.g. auto pre-loading of ‘sets’)

so I think its a perception issue?

Suggestion

I think the key to the misunderstanding for me was Recent
I just assumed this loaded from disk, thats has recent docs work everywhere else.

perhaps this should be renamed to something like
‘in memory’, ‘ram’ , ‘loaded’

something that shows you its an in memory copy.

at a deeper level, I think what MM is going for is to have these patches a bit like ‘auto load’ plugins… combined you could get very fast switching for live sets.
but that association is not clear to users currently (at least wasn’t to me ;))

@danngreen mentioned in a different topic about the module using a kind of virtual (ram) disk, which I assume is all related to this.

anyway, I think making this more explicit, whilst a bit ‘technical’ (than ‘recent’) I think will help going forward.

ofc, others may disagree… or I might have misunderstood something here.

6

Yes, exactly! Basically, it’s like having multiple tabs/windows open. There’s some limit, I think 20? And after that it will start closing the older patches if they have no changes (no red dot). Or tell you to save your work if you have >20 open + modified patches.

Of course only one of them can be playing at a time (playing one stops any others).

Maybe just calling these open files “Open Patches:” is enough? You’re right “Recent” implies they are closed files.

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).

2 Likes
7

There is another thing I should document. If you open a patch, and don’t modify it, and then remove the SD Card or USB drive that it was on, and then re-insert that drive, then load the same patch from “Recent”, it will re-load from disk even though it’s in memory. The reason is that it doesn’t know if you changed the patch file on disk or not, so it reloads. This won’t overwrite changes in case you made some on the MM, so it’s safe – it’s just there in case you are only changing things from VCV.
We could store a hash or check modification time to make this more efficient, but I don’t think it’s a big deal because if you’re ejecting and re-inserting disks then it’s already doing disk access to scan if there are new files, so loading one patch isn’t much more.

2 Likes
8

currently if i have a patch loaded/running on mm, then jump over to vcv and make a quick tweak to it, then reinsert the usb drive in the mm w this new version, then navigate to reload the same patch off the usb, it doesn’t seem to load the recently changed one. so to load the updated one, i then have to load a separate patch (i keep a blank dummy patch for this purpose), then after that, load the one i just tweaked- and then it will finally show the changes. seems slow/clunky w extra steps to have to do all that. or perhaps im not doing this right/there’s a better way? if so i’d love to know the how.

since we have to iterate potentially hundreds of times to get a patch just right on the mm, would be really awesome if the mm could just automatically reload/update a patch if it detects the patch has been changed in vcv ( @danngreen is that what you meant by using a ‘hash’ mod time check?).

and i get that maybe not all would want that kind of forced auto patch update behavior so perhaps a setting in the sys prefs could turn on auto patch updating? or a popup when the usb is inserted saying ‘patch changed do you want to reload?’ or a config file on the root could have a flag to enable such a feature at startup. i dont know…

9

Hmm… I see, yes there’s a bug there. You shouldn’t have to click on a dummy patch. It’s supposed to be so that when you eject a disk and change the patch on VCV, then re-insert the disk, the patch will refresh when you click its name in the Patch Selector. I just fixed this in my branch, and will put it in the next firmware version.

As for automatically refreshing a patch, it would have to read the patch from disk automatically when you re-insert the disk, and then check if there’s been changed (a hash, or a timestamp might work). It’s possible to do… maybe the pop-up dialog you mention could work.

10

ah nice, super glad that something that can be fixed!

amazing yeah that would really help out versus having to go back into the file manager and scroll down to the patch every time. which can get tedius for patches with names that start with x-z… or scrolling past a bunch of patches in the recently opened section (that always appears above the usb drives)

11

What do you think about hitting Back to exit the patch to the Main Menu, and then hitting Back again to return to the patch? There would be no scrolling or searching for the patch name, just a quick Back-Back action when you want to refresh it from disk after re-inserting the disk. It would be easy to implement, and adds no new extra UI events (no pop-ups or new settings).

3 Likes
12

oh yeah definitely; that would be quite quick/useful!

1 Like