Ok, what did I do wrong?
I have lost the ability to move note events around in one particular midi part. I can still move them by keyboard commands (as displayed in the .gif) and I can still move note events by mouse in the other midi parts (you have to take my word on this one).
Apparently neither part nor track are locked.
I restarted Cubase already.
I was able to work with the mouse some minutes earlier also on these note events.
What did I do wrong?
I started to check out every single file in the Cubase 12_64 folder.
If I exchange the Defaults.xml with the factory one the problem is not present anymore.
I tried all my older Defaults.xml files from my backups. With all of them the problem is present.
For moving on I can simply copy all midi events from inside the part, delete the part, create a new blank one and paste the events inside.
If someone from Steinberg is reading this: I can offer the project file and the Defaults.xml for inspection.
As I mentioned: It is exactly just one specific midi part that disallows any mouse button functionality other than selecting.
Please let me know in due time whether you are interested as the project file will get deleted at some point in the future. Kindly remember: You are not fixing a bug for me but because there’s something wrong in the code.
What I will do with that kind of issue is compare the original xml file with anyone of your corrupt xml.
Nowadays this is not so hard to check.
I suggest you to check with an AI like chat gpt or any one who can check for similitudes and differences.
Also you can open both files in excel and do the the same kind of work.
Just think that the xml file is a simple data base file who contain info that can make a better interaction with the daw in this case.
Hope that can help you or out you in the way for the solution.
welcome to the forum.
I think your idea is very good. It is easy for me to say this as the same idea also crossed my mind.
Here’s the thing: The factory file is 345 kByte in size, while my Defaults.xml is around 2200kByte. A file compare will therefore yield a high degree of differences. While I am sure the culprit is to be found somewhere it is well hidden by a lot of of other changes/additions to that file.
Thus I think that only somebody with deep knowledge of the entire structure, not only of the entries in the .xml file but also their connections in the program code can analyze it in a meaningful way.