Yes, that’s my observation too.
If I understand correctly, assignments are also saved in the project.
The interaction between the project and the current globalmappings file could also cause an error.
On closer inspection, the assignment option Global or Project also seems vulnerable to me.
To me, the concept doesn’t seem to be fully thought through yet.
I kept experimenting last night, going from C13 to C14 always with the same project and copying and saving the .jason file from C13 to a diff. location and then using that after the problem appeard when opening C14. But on my last tries the weird issue stopped happening. So I am very baffled. Maybe something happens the first time C14 is updated, or used on a new project? Will keep experimenting today, but I am somewhat relieved that so far the same issue has not happened at all in C13 and maybe saving the file that C13 time stamps after closing can help when it appears again on C14. Every time either Cubase version quits it wrties the .jason file with a new time stamp. I haven’t checked if it also does that writes a new .jason when a project is just closed but Cubase is still running.
It happened to me recently when I was creating a new project. I only added one midi track and the MIDI Remote was broken. This reset the json globalmapping file to 1KB. Logically, all other projects then had no more assignments when I opened them afterwards.
The error is difficult for me to understand because it manifests itself in different ways.
It became really problematic for me with version 14.0.40. Strangely enough, this is the version that was supposed to fix the error.
With 14.0.30, I only had the problem with the greyed-out duplicates.
Perhaps the programmers should start there and see what has been changed.
So this AM. I opened a project on C14, X-Touch OK. I closed it and open another one ( did not quit C14), X-Touch NOT OK (all black, not updating faders go to OFF. I deleted the .jason file created with today’s time stamp and copied a previous saved one that was working OK. I opened again the project and X-Touch NOT OK. Quit C14 and then open it with the same project, X-Touch OK. Narrowing it down. But it would be a pain to have to delete and copy files every time. Hope someone at Steinberg is paying attention???
Another test: I Updated C14.0.20 to the latest C14.0.41 again. Opened same project, X-Touch NOT OK. Did not change the “globalmapping.jason” file. Uninstalled C14 and reinstalled C14.0.20. Open again the same project and now X-Touch OK. So I am staying on C14.0.20 for now until further notice as at least I can get the X-Touch to work reliably with shenanigans.
I have contacted Support. Here is a direct quote of their instructions to me. This action solved the problem of lost mapping at this time. I loaded several projects with and without the midi controller on and so far everything is working. I am going to have a remote session this week to hopefully pinpoint the exact file in my Preferences folder that has apparently caused the issue. Keep in mind their instruction reboots Cubase to default settings and you are advised to migrate preset files back into the new default folder. I only loaded three files and had to redo some configuration as I am not sure what file originally caused the problem and am hesitant.
Here is their instruction FYI: Here is a quote of their response:
"PC:
Close Cubase
You can manually reset your application data by opening your File Explorer: C:\Users\Username\AppData\Roaming\Steinberg then move the folders that say Cubase 15 or ANY earlier version of Cubase you see to the desktop.
*If you don’t see the AppData folder, you must select View > Options > Change folder and search options. Select the View tab and, in Advanced settings, select Show hidden files, folders, and drives and OK.
Restart the computer and then launch Cubase again. Be advised the load time will take longer as it will be rescanning everything just as it did the first time you opened the program.
You can then move back specific preferences such as key commands but if the issue returns, you know that may have been the corrupt file and you may have to rebuild it in Cubase.
Mac:
Close Cubase
From your desktop*, select Go>Library (Hold option to reveal hidden library folder)>Preferences>Cubase 15. Drag this folder and ANY previous Cubase folders to the desktop. This will reset your preferences to their default settings next time you open Cubase. If this works, you can then grab things like key commands and templates from the old preferences folder and put them in the newly created one."
*when they say “desktop” they mean “Finder”
Hopefully I will have more information after my remote session this week.
Thanks chasleslieb, for the moment I have it working OK on C14.0.20. Will see what happens once I update to C14.0.41. I believe that removing older, unused and disconnected X-Touch surfaces that appear in the lower section of the project in MIDI Remote as advised by “aram” ( X-Touch (+Extender) MIDI Remote Script (MCU mode) - #428 by aram ) on another post helped the issue as I believe these duplicates where confusing for Cubase. Three of them showed s\as connected when starting the project yet after clicking scan again only actually 1 is connected. Now that’s no longer happening since i removed the unused ones. Only two surfaces show up and 1 is connected and the other disconnected but it cannot be remove as it results in an error.
I’m going to have a remote session with Steinberg support this afternoon to try and identify the errant file. I will keep everyone posted on the progress.
Cubase pro 15.0.6 and the Same Happened to me, In the midi remote folder there is a user settings folder with the global mappings for each midi remote controller you have. I noticed the file size had changed after I lost all settings. I have made a new map and I am going to back up this file in case it happens again. Might be worth a try. Good luck….and best wishes and seasons greeting to you
There are two ways that work more or less.
The first way would be: Make a backup of your working globalmappings file.
The file is located in the User Settings folder, which can be found in the Documents folder.
Cubase usually resets the file, which can be recognised by the fact that it is only 1KB in size.
If this happens, replace the file with the backup.
The second way: The Midi Remote and the assignments must be there. Export the Midi Remote script. You will then have a file with the extension midiremote.
If there are any problems, delete the relevant MIDI remote from Cubase. Delete the globalmappings file in the User Settings folder. Open Cubase and import the midiremote file script. Everything should be there. If the assignments are missing, something happened during the export of the midiremote script. It is therefore important that the MIDI remote is working properly during the export.
The second way worked for me, using a previously made working backup. I had tried loading the backup before, but without deleting the globalmappings file first, so it hadn’t worked. This time it worked great
NOTE TO SELF: Always backup your working midi remote scripts to a safe location outside Cubase’s fragile settings folder!
The results of my “Remote Session” with the Cubase Support Tech in the U.S.:
As as short recap. I posted their instructions on the process of rebooting Cubase to default settings in an earlier post. This worked and I am now able to map the controls and the mapping no longer disappears.
However, part of this process requires migrating some of the old files, such as presets, custom key commands, templates, etc., back into the new default version. My question to the technician was “what specific files do I NEED to migrate? and Was there a corrupt file that disabled the feature? And what file was it? I did not want to reload the bad file back into the program.
I sent him a screenshot of my folder and he could only theorize that it might have been the Midi Devices.bin file. But it is only a theory. He also suggested migrating files in batches and seeing if any of them repeat the problem, thus isolating the supposed corrupt file. Since my Cubase is a recent purchase and was pretty “clean” I am choosing to start over. I don’t want to break something that appears to be working.
I pointed out to him the numerous posts on this thread and he checked it out and saved it for future reference. He acknowledged that it could be a more complex problem than just a corrupt file. He said he would reach out to the Cubase developer team about this problem and he acknowledged that they are aware that there is a significant issue.
He also confirmed if you don’t migrate any files, you will have to do some reconfiguring, but that Cubase will rebuild the folder. He acknowledged that it still doesn’t identify the cause. It is possible there is a similar cause amongst all of us (we all have the same corrupt file) or there is something in the Cubase programming that needs to be altered to improve stability.
So even though there was nothing definitive as a solution, at least it has been brought to their direct attention and hopefully there will be more information or a fix or both at a later time. My support ticket remains open at this time… so we shall see.
I had set up a MIDI REMOTE tracking map for my Novation LKM3 several months ago and today I wanted to record some scratch vocals — after a few months of doing other kinds of work — and now the mapping is gone. No fault of mine. The only thing I did was upgrade to Nuendo 14 from version 13. That was the cause.
I don’t think it’s a bug. I think it’s just sloppy attention to detail. I worked for a long time for that mapping and now I have to see if I can dig it out of time machine.
This kind of thing should be tested before a release, not at the end cycle of a version.
In addition, as a musician, I don’t want to switch to a nuclear physicist’s mindset just to understand how to get my mapping back in working order. But as soon as it’s gone - there’s no choice but to go down that rabbit hole… I also see many have had this same problem, going back to 2022. Wow. 3 years ago.
In response to Realist and midiremote file backups.
I exported my script from a functioning mapped MIDI Remote surface. I then saved a copy of that midiremote file to my storage drive such that I had two copies: one in the Cubase default location as you mentioned and one safely tucked away on my remote drive.
When the mapping feature failed, I tried importing the default-located midiremote file as well as the remote drive version. When using the remote version I copied it into the path that Cubase normally uses to access the file. The result was the mapping feature still failed. Thus I had no real, functioning backup. It has to be something else.
It appears that “something else” may be located within the Cubase file located in the hidden library (on a mac). Since my MIDI remote appears to be working correctly after the Cubase reboot, I am going to save the entire folder as a backup as it is conceivable there is something going on somewhere within the folder that is still unknown.
That is my best guess at this time for a potentially reliable backup. But this mystery should be solved and resolved so we can move forward and use our time recording and playing music instead of computer programming.
I have searched my Mac and there is no MIDI remote folder that Cubase creates. As I mentioned in my previous post, I did save .midiremote files in separate locations so that I knew one of them was safe from being overwritten, but the mapping was still gone.
I am curious.
Are you creating your own MIDI Remote folder? What files are you storing in the folder?