MuseScore corrupting its own scores

• May 25, 2024 - 03:55

MuseScore 4.3.0.241360504 Nightly
Mac OS 13.3 (22E252)
Mac Mini M1 2020

I'd welcome a solution to this issue, the second time that MuseScore has corrupted a lute tablature file with multiple parts.

Now that it's happened twice, I might have noticed a pattern of what's a prelude to the file having become corrupt. When reviewing my work via playback, I hear passages from elsewhere in the file simultaneously with the music that I'm supposed to be hearing. I closed MuseScore in attempt to clear what I presumed was an audio caching glitch. But when I try to reopen the file, MuseScore crashes immediately.

Both instances are of lute tablature files that I'm trying to get into shape for publication, which means I've put in many hours of formatting work only to have the files become unopenable. There was an earlier instance of tablature files causing the app to crash when I tried to open parts, and somebody here told me to use the daily build, in which the issue was already addressed, so I was able to resume work temporarily, until the present issue became a thing.

I recovered earlier versions of the file from incremental backups made a couple hours prior to the most recent crash, but even these earlier versions won't open, meaning the corruption must have happened very early into the process. The attached file is from 21:17; an older save from 19:07, two hours earlier in the work process, also won't open. I began work around 11:00 (that version won't open either, though the source file I was working from (I'm collaborating with a colleague) still opens fine.

I'm all ears if anyone has a thought as to what will open and allow me to resume work on these files. Thanks!

Attachment Size
Duet in A, SC 60 (RS).mscz 345.55 KB

Comments

• May 25, 2024 - 04:45

I don't know why you're talking about corruption. It's still the same issue (https://github.com/musescore/MuseScore/issues/22759), fixed for 4.3.1 which will be released very soon now.
If the clef is displayed, your file opens as expected, and playback is fine (I've listened to half the file), see now: 1Duet in A, SC 60 (RS).mscz
Is there anything else I've missed? In particular, I don't understand "when reviewing my work via playback, I hear passages from elsewhere in the file simultaneously with the music that I'm supposed to be hearing." ??

Reply

• May 25, 2024 - 06:06

Thanks for responding. The fact that you’re able to open it gives me hope. How is it you’re able to open it but I can’t?

The playback issue is this: when I play the score or part by a certain point in the file, I hear not only the music that’s notated in front of me, but also melodies notated elsewhere in the score. It’s weird, I know. And very wrong.

I thought that the no-clef tablature issue was already addressed in the nightly build I downloaded and began using after you recommended that solution. I confess I’m confused: that nightly build allowed me to open a tablature project without clefs. It was only after working on it for several hours in that nightly version that the bad playback began, followed by the MS software’s inability to reopen once I restarted the app.

Reply

• May 25, 2024 - 17:17

Hi Cádiz. For some reason I'm seeing your full reply on my phone but not in the forum. Quand même…

I downloaded the penultimate nightly as you described (see screenshot), but the result is the same. When I tell it to open my file in that version of MuseScore, the app crashes immediately.

OS: macOS 13.3, Arch.: x86_64, MuseScore Studio version (64-bit): 4.3.1-241460504, 2544ca1

I downloaded this from https://ftp.osuosl.org/pub/musescore-nightlies/macos/4x/nightly/?C=M;O=D

I have not uninstalled any previous version of MuseScore. Could this contribute to my issue? If yes, is there a way I can retain my preferences (custom palettes for building style-specific lute tablatures, for instance) in order to continue my work-flow with minimal interruption.

In case it's useful, here's the top of the crash report. Thanks in advance for your patient help.

Translated Report (Full Report Below)

Process: mscore [1129]
Path: /Applications/MuseScore 4.3.1.241460504 Nightly.app/Contents/MacOS/mscore
Identifier: org.musescore.MuseScore
Version: 4.3.1 (241460504)
Code Type: X86-64 (Translated)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2024-05-25 12:06:53.4852 -0400
OS Version: macOS 13.3 (22E252)
Report Version: 12
Anonymous UUID: 358585A6-E551-895C-0BF6-A9855C0C80D2

Time Awake Since Boot: 120 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xb56ec59d875bac9b -> 0x0000459d875bac9b (possible pointer authentication failure)
Exception Codes: 0x0000000000000001, 0xb56ec59d875bac9b

Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [1129]

VM Region Info: 0x459d875bac9b is not in any region. Bytes after previous region: 76061846776988 Bytes before following region: 29010233152357
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
commpage (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated)
---> GAP OF 0x5f9000000000 BYTES
MALLOC_NANO 600000000000-600008000000 [128.0M] rw-/rwx SM=PRV

Kernel Triage:
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mscore 0x102c23673 mu::engraving::LinkedObjects::mainElement() + 35
1 mscore 0x102ed7b06

Attachment Size
Nightly screenshot.png 149.07 KB

Reply

• May 25, 2024 - 17:32

Indeed, I've edited my comment because:
After opening your file with 3.7 Evolution without any problem, I did indeed notice a crash on opening with the latest portable version 3.4.1 or latest nightly build.
I must say that this is surprising, to say the least, because it seems, from my initial investigations, that simply deleting a measure or frames, or displaying the clef and then no longer displaying it, fixes the file. Weird...

What's more, I'm unable to reproduce the crash from scratch with a new score of two lutes, and the same configuration as yours (and with clefs or not) . So the fix for the clefs works. There must be something else in this file. Probably nothing prohibitive? That's about it for now, but I'd like to know what's going on.

Is this the only file that behaves this way, or others too?
For the time being, so that you can continue to work with this file, you can download this 3.7 Evolution. One of its advantages is that it allows you to open a file saved with V4. See: https://sites.google.com/view/musescore-3-evolution/
And https://github.com/Jojo-Schmitz/MuseScore/wiki/

Reply

• May 25, 2024 - 17:47

Hi Cádiz. I see you're using translating software to write to me. You're welcome to write to me in French. I will understand you there too. If I write back to you in French, that's likely to be more interesting…

I would like to know what the issue is beyond the one that's already been identified as having to do with the presence/absence of the "TAB" clef, particularly as a publication hinges on my being able to make a nicely formatted tab, which MuseScore does better than any of the usual lute tablature systems, all of which are Windows-only. What this and the other that I've attached have in common is that they both came from my collaborator's Mac. He's using the stable release of 4.3.0.

I have done a lot of formatting, including placing individual tablature letters into separate voices so as to be able to move them slightly to the right in order to use a large font-size and avoid collisions when there are chords. I have dragged a lot of slurs, and done everything I can otherwise also to have complete movements or sections on facing pages. The work has been elaborate, and I don't mind the investment of time because the result is so attractive. So long as I can keep on working in my file.

I will try Evolution at some future point. For now, it's important that I progress quickly rather than learn to use different software. Also, I don't remember the "Didactic" lute tablature font as being available in MS 3, but it is in 4. The "Didactic" font is what made me change my mind about using MuseScore for this project.

Attachment Size
1025 tab RS.mscz 697.62 KB

Reply

• May 25, 2024 - 18:13

" If I write back to you in French, that's likely to be more interesting…"

I think it's best to continue in English. Using a translator is easy, I'm used to it, and it's the rule here to respect the language of the forum on which you're expressing yourself.

"I would like to know what the issue is beyond the one that's already been identified as having to do with the presence/absence of the "TAB" clef"

I'd like to know it too! For the moment, I can't. If you want, you can file a bug report on Github (all you need to do is register), here: https://github.com/musescore/MuseScore/issues (click on New Issue, and go to the process)

"I will try Evolution at some future point. For now, it's important that I progress quickly rather than learn to use different software."

3.7 Evolution is not a new program/software. It's a fork of Musescore version 3.6.2.

"Also, I don't remember the "Didactic" lute tablature font as being available in MS 3, but it is in 4. The "Didactic" font is what made me change my mind about using MuseScore for this project."

Features for historical tablatures are strictly the same between V3 and V4.
And so the "Lute didactic" style was already available in V3.

I'm in a good position to know this, as I was the one who proposed this style 10 years ago to programmer Maurizio Gavioli / @Miwarre (who hasn't been with MuseScore for a long time now). Here's the thread: https://musescore.org/en/node/76561

I had noticed the font style of Miguel Serdoura's baroque lute method, and was interested in it (since I was working on the baroque lute at the time, well, a bit... and theorbo too). I no longer have them, and am focusing on the Renaissance lute 6 and 7 courses now :)

EDIT: "I have not uninstalled any previous version of MuseScore. Could this contribute to my issue? "

I can't say for sure without understanding what's going on, but I don't think it's related.

Reply

• May 25, 2024 - 18:58

Thanks for your reply! I forgot that these international forums often have an official lingua franca that all are expected to use so it's useful to all and not just those who speak this or that language! I will try Evolution, in that case. It will be interesting to see what of my formatting remains when I open one of these files in it. Likely I'll do that starting with BWV 1025/WeissSW 47.

I understand that MuseScore only allows the tablature fonts that it provides. Whom would I contact to suggest an improved font for lute notation? "Didactic" can be made to be more reader-friendly with a few small modifications.

I'm not surprised that you play lute. Some of your earlier comments suggested that you know about these instruments' notation. You can contact me directly on email if you ever want to chat about lute matters. I am looking forward to when I eventually withdraw from concertizing. It's at that point when I will play 6 and 8 course lutes in earnest. Right now my focus is 17th and 18th century music because of my orchestra.

Reply

• May 25, 2024 - 19:07

"Whom would I contact to suggest an improved font for lute notation? "Didactic" can be made to be more reader-friendly with a few small modifications."

Unfortunately, there are no longer any programmers who specialize in early music, as @miwarre once did.
You can file a feature request on Github, but I doubt current developers are really interested in modifying a baroque lute font (I think it takes time...), although I hope I'm wrong about current developers' interest.

Reply

• May 26, 2024 - 19:06

Hi Cadiz. Yes, something else is certainly going on, and it surely has to with something more than the bug about clefs/no-clefs in tablature, because the same behavior continues with the tablature clef in place. I was working in MuseScore 4.3.1.241460504 Nightly.

Abnormal playback alerted me to the possibility of a problem once again. This time, parts stopped playing unless I toggled the "Play" property off then back on, even though "Play" was not unchecked at the time of toggling. Another playback anomaly was that sometimes just the selected first note of a passage wouldn't sound before the rest of the passage played normally.

I restarted my computer, in case that would solve things. But when I try to reopen my work in this version of MuseScore, it crashes the application.

Another abnormality is that the Home→Scores screen doesn't display a thumbnail for the file I'd been working on—and saving regularly—since last night, nor is it listed for the app's recent files at the top menu bar. It does show up as a recent file in the Mac OS menu bar. This is all happening with the "TAB" clef always there.

I think I need to submit a bug report. It's not just the clefs. I just don't know how I'd describe it to the tech team. Any ideas?

By the way, I couldn't use Evolution because it doesn't let me specify how many bars I can have in a system, and since I'm working on fine details of layout, it's not useful except for viewing a file. Musescore 4's feature of being able to group bars into a system is an important factor in my choice to use this software for my project.

Sorry if this is becoming tedious for you.

Attachment Size
Duet in A, SC 60 RS (clef).mscz 361.81 KB

Reply

• May 26, 2024 - 19:51

Hi Richard,
It doesn't get tedious, don't worry about that. I understand your dismay. I wish I could be more helpful, but I still don't understand what's going on, alas.

For the bug report (here: https://github.com/musescore/MuseScore/issues, and click on "New issue" tab), just say "This score crashes on opening" in the title. What else can we say, since you and I don't understand the cause of this crash (and I can't reproduce it from scratch, which is really the most annoying thing)

Then, in the description, point out, as you just did, that it seemed at first that TAB clefs visibility/invisibility might be the culprit, but that with 4.3.1 (nightly build), there must be something else too that's causing the crash.

The developers have debugging tools, so this will probably lead them in a first direction.
Then, don't forget to provide the link to your thread on this forum (for discussion elements), as well as the crash report, which you gave on this particular comment: https://musescore.org/en/node/364505#comment-1243701
This will be another element of understanding for the developers.

One last important point: for the .mscz file (the last one you've attached, for example, Duet in A, SC 60RS) to be accepted on Github, you need to zip it.
And why not, you can add another one (there was, from memory, a Bach's score). It's probably the same problem, but it will confirm the first one.

NB: the "Keep measures on the same system" V4 feature is not at all essential for a good layout. There are plenty of parameters that can be used without it for getting the same result.

Reply

Do you still have an unanswered question? Please log in first to post your question.