There is a paradigm in software design, The user is the element that decides what should be the design. We have been trained for years (decades) that “save” (ctrl+S) makes a working, persistent project, or document copy that can be used to restore the work you’ve done. I used it again, and was betrayed by the working mechanism used by the plugin version of Mocha Pro. I read, “sorry you lost the work due to a crash, you should have exported the project”. Useless.
Please design it so that save works as has been the mechanism for decades (whether you just trick us, and make it export) or actually make it worth something.
Persistent defective design is inexcusable.
This should be fixed, what version are you using? We save backups now.
Version 7.0.4 build 9.g7a500571e508
I was using the ctrl+s save regularly. closed mocha and went to PPro, instant crash, restart and nothing, mocha project gone.
Hmm, that’s very odd, because you should have an option to open a temporary file the next time you start Mocha after a crash. We will have to test this on our end and see if we can duplicate it, as we agree this is not expected behavior.
Do you crash every time you use Mocha Pro or was it just this shot, if so, can you give me some more details so we can try to repeat the error on our end?
No, it is not a consistent crash.
I had successfully finished track & stabilized with auto fill.
Thankfully I had exported a video render.
As soon as I closed the Mocha interface, PPro did a big old "sorry,
there has been a serious…"
restarted, checked the mocha plugin, started up with nothing :(
The autosave file is still there, just navigate to the following location depending on your system:
macOS: ~/Library/Application Support/Imagineer Systems Ltd/Autosave
Windows: C:\Users[username]\AppData\Roaming\Imagineer Systems Ltd\Autosave
Linux: ~/.config/Imagineer Systems Ltd/Autosave
Every time you hit save it creates a backup save file. Iterative backups are also saved in the “autosave_history” folder.
If the crash in the host is severe the autosave load prompt may not turn up next time you load the plugin, so you need to open it manually by going to File > Open… then changing the file filter to “All Files” so mocha can read the .autosave extension.
The crash itself is the concerning part. Which version of Premiere is this? Can you send us a project file?
As a side note, since you brought it up, let’s talk about why saving in a plugin environment is a tricky user design challenge.
Plugins work inside a host architecture. Saving a plugin project saves to that host project data.
As such, when the host fails (in this case, Premiere crashing) the saved data that is lost in the host from lack of saving is also lost in the plugin, because the data persists in the host, not externally.
You may think Premiere auto-saving would help this, but modal plugin dialog architecture does not allow host operations while a plugin modal window is open, so it has to rely on the user or host saving when closing the dialog.
The clear workaround is to always have a persistent backup autosave file in the case of failure, which is how Mocha currently operates.
However, consider a user with multiple projects or multiple hosts: How will a plugin determine which autosave file should be tied to which Mocha plugin project? Multiple projects could have multiple saved backup files from different hosts.
We could use a unique id, but there is no guarantee that a new effect applied to a clip will match the file id of a save file. So, in the case of timestamped effects and their related hosts, we can at the very least provide an autosave load prompt when it appears the last file used was linked to the project you’re currently opening. When that fails, a manual load is required.
All autosave filenames are written as such to provide easier discovery:
This translate to a file being called something like mpp-7_aftereffects-16.mocha.2020-01-29_11-39-13.autosave
You can read more about this in the Autosave section of the User Documentation: