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.