Working in instrument parts corrupts the mscz file and crashes Musescore
When I attempt to work in parts (as opposed to the main score), Musescore becomes unstable.
The pattern is not entirely consistent, but the application does some combination of the following.
- Sometimes locks up.
- Sometimes crashes.
- Sometimes just linked staffs end up with blank notes in them.
- Sometimes Musescore reports the the file has become corrupted.
- Updates to the parts are not reflected in the main score page, and vice-versa.
When the parts get out of sync I can recreate them successfully; however further work creates the same issue.
Is anybody else having this difficulty? This bug is making the application almost unusable.
Attached is a sample project.
| Attachment | Size |
|---|---|
| Bridge_Over_Trouble_Water.mscz | 37.6 KB |
Comments
In order to investigate, we would need you to give precise steps to reproduce the problem. I recall someone once having a problem vaguely similar to this some years ago, and a bug being found and fixed as a result, but I'm not aware of any known remaining issues that would cause this to still happen.
In reply to In order to investigate, we… by Marc Sabatella
I see a corruption problem in the case of linked staves, themselves with created part and with involved slurs. Copy-paste frets numbers/notes + slurs (from TAB staff) fails and creates a corruption in the score. See, first in the original attached file, then from a test file created from scratch.
Crashes inevitably follow quickly after that.
In any case, @mrbbolt: avoid creating parts in a score that already has linked staves (like guitar, standard + TAB), or, better: wait the end of the input of your score before creating parts.
Test file from scratch: test2.mscz
In reply to In order to investigate, we… by Marc Sabatella
Hi Marc,
The problems I'm having are so pervasive that I can't really produce a single path to failure.
My scenario:
I 'm working on a small ensemble arrangement.
I create a lead-sheet part consisting of melody and chords.
Then I create arrangements for the other instruments. E.g., guitar, violin, bass.
Each instrumental part consists of two linked staves: notation and tablature.
I would prefer to work in the parts themselves because they are less cluttered. Editing the parts themselves makes the application unstable. The parts become out of sync with the master score. Edits to the master score also may not be reflected in the existing parts. (Note: I've been doing this for few years without any issue, but over the summer I started experiencing these crashes.)
The basic steps to reproduce are as follows:
Create a score with instruments for a melody part consisting only of notation, and an instrument consisting of staffs for both notation and tablature.
The melody part just contains a single voice with chords above it.
Now generate parts for the melody, and the instrument.
The Melody part only contains the melody instrument.
The instrumental part should consist of both the melody and the instrument.
Now start editing the instrument arrangement.
E.g., for guitar maybe copy the melody line into the notation staff, and then fill in chord notes. Any updates to the notation staff should be reflected in the tablature staff.
While working on the guitar instrument part, at some point the app will lock up, crash, or become corrupted.
My guess is that this is a resource issue. On a large score Musescore becomes very slow responding. My guess is that Musescore uses some sort of in-memory database to keep the parts in sync. If it can't get a write lock then the parts would become corrupted, etc.
Thanks,
Brian
In reply to Hi Marc, The problems I'm… by mrbbolt
See the reply from cadiz1 just above - it seems like he has identified the source of the problem and found a way to avoid it, no?
As for things becoming slow, that certainly shouldn't happen in a score this small - unless it has become corrupt, in which case, pretty much anything can go wrong.
For non-corrupt scoreEven in larger scores, most operations should be independent of the size of the score, because we only lay out the systems actually changed by any given edit. But some operations do force a relayout of the entire score. Links are followed and updated on each and every update - no lock involved. Actually, before this partial relayout was implemented, I did once do a trial implementation of an optimization to not update parts on each edit, but managing that synchronization was difficult and I gave up. That shouldn't be much of an issue now, so what you're seeing might be something different.
Again, if you're seeing some sort of slowdown that is not directly the result of corruption, we'd need a sample score and precise steps to reproduce the problem.
In reply to See the reply from cadiz1… by Marc Sabatella
I can't say for sure, but my guess ("for things becoming slow"), on certain scores, is this problem is due of slurs being duplicated X times in linked staves and parts. In addition to the induced corruptions.
In the tests, I have even seen strange things after undos, slurs completely lost, misplaced, in the other staff, even in another system, and even with the anchor at the beginning of a system! With easy crashes by just moving them a little with the mouse
In reply to I can't say for sure, but my… by cadiz1
E.g:
In reply to See the reply from cadiz1… by Marc Sabatella
Hi Marc,
Cadiz's suggestions do not apply to my scenario. As I noted, there are lots paths to failure when working in parts.
To keep it simple, I provided a very minimal score. (This small score does not have any performance issues.)
There are no slurs.
Just re-arranging any notes in the part can trigger a crash or file corruption.
Let's take a step back at this point.
First of all. Thanks so much for taking a look at the issue. As always, I'm impressed by the prompt response to queries on this forum.
Second. I initially just wanted to know if this was known defect.
It appears that the answer to that is "no".
Since y'all are interested in addressing this issue, I will provide you with a very specific case to address. This may take a little time. As Cadiz's example illustrates, there are lots of ways to trigger problem. I have this occur whenever I work in parts, so I will try to create a basic scenario where I can repeatedly trigger the same failure.
This should provide you something reproduceable to work on.
In reply to Hi Marc, Cadiz's suggestions… by mrbbolt
"To keep it simple, I provided a very minimal score. (This small score does not have any performance issues.)
There are no slurs."
Of course there are slurs - image below
I've also noticed sometimes that just changing the pitch note can crash the score. But as said, once a score is corrupted, things can go wrong in different ways.
As far I know, it was never intended in the program (as far as I remember, and I think I recall a statement by Maurizio Gavioli to that effect) to make linked staves (like a standard guitar + linked TAB) + Part to work "correctly".
It's like a double link. This could work sometimes, with risks, and I think (well, hypothesis), I had noted it too, that bugs fixes many months ago (much more serious, resulting in empty measures when the order of instruments was changed afterwards) resulted in additional fragility in some other cases, like this one possibly.
So, currently, the best advice for you is to modify your workflow. Either by avoiding linked staves, or by creating the parts at the very end of the score entry.
But if you find an even stronger, or other scenario(s), with specific steps, you're welcome :)
In reply to "To keep it simple, I… by cadiz1
Ok. That slur was in the part. I didn't have the original example handy.
But the point is that I don't think that this is the root cause. I'll verify that though.
Thanks for the response.
In reply to Hi Marc, Cadiz's suggestions… by mrbbolt
You wrote; "Cadiz's suggestions do not apply to my scenario" - but are you sure? It seems he hit the nail on the head here. There does seem to be a known problem with generating linked parts for an instrument that themselves contain linked staves, and that seems to be exactly what you have done here. So the approach he suggested for avoiding the problem should apply.
Since you specifically mention preferring to work in the part instead of the score, consider adding just the notation or the tab (whichever you prefer), creating the part, editing there, then deleting the part, adding the linked staff, and then recreating the part. Or variations on that theme to suit your personal workflow. Another option is to simply hide the piano staff (in Edit / Instruments) in the score rather than generating a part that contains everything but piano.
In reply to You wrote; "Cadiz's… by Marc Sabatella
Hi Marc and Cadiz,
I've simplified things a bit with this example.
This file simply creates a score with two parts: Oboe, Guitar with notation and tab.
Again, all the edits occur in the parts tab which contains both the Oboe (this is my common melody line), and the guitar notation and tab.
See where the tab does not reflect the notation.
Switch back to the main score, and there the tab is correct.
Also notice that the text frame between the main score and the parts tab is not in sync either. Edits I made in the parts tab to the text frame were not propagated to main score page, and now that they are out of sync, Edits in the main score page do not propagate to the part either.
Cadiz, you mentioned known issues with copy/past operations. But the way I read it, they were restricted to slurs corrupting the file. In this case I was careful to not tie over or otherwise slur any notes.
Hope this helps.
Thanks,
Brian
In reply to Hi Marc and Cadiz, I've… by mrbbolt
Ok, I understand what you mean, indeed, it's another scenario. It happens when you combine several instruments (at least two, one of which has linked staves) in a same part.
In this case, copy-paste notes of the "single" instrument into a linked staff of the other instrument (either the standard staff or the TAB) corrupts the other linked staff - you can clearly see the rests disappear.
Whereas in the main score, it works.
As far as I remember, your use case is not common, for all that, I'm not making a value judgment, it is respectable. Nevertheless, I would say 1) that you were really lucky that it worked up to a certain point! :)
Because 2) again, the program was not intended and optimized to work with parts, which one instrument already has linked staves.
The usual advice is that it is recommended (for example for an orchestral score) to create the parts at the end of the work, so imagine when you multiply the potential problems with an instrument with linked staves, and for you, the combination of two instruments, eg, one of which has linked staves, in the same part :)
And that 3), you have been given several ways to continue working to avoid staves clutter, as you said.
Nevertheless, of course, feel free to submit this issue in the Issue Tracker.
In reply to ; by cadiz1
Hi Cadiz et all,
I just wanted to document my use case more thoroughly here in this thread, since ya’ll kinda think it’s strange. To me – of course – it seems like a natural progression from working on paper vs. electronic content creation.
Essentially I’m just creating simple charts of songs. Like Real Book charts. In it’s simplest form this initial part contains a melody and chord symbols.
So that’s step 1.
Then I want to work out parts for other instruments, or other variations, etc.
I find it useful to reference the canonical melody line and chord symbols.
So each part contains a staff for the canonical melodic line, and it also contains an instrument specific part with notation and – if applicable – tab.
This all seems pretty natural to me. If I’m playing along with a chart, I’d like to see the melody and chords, and I’d also like to see the more detailed arrangement with voicings, etc.
From an application development or content management perspective the way I work also makes a lot of sense.
While I could copy the melody and chords into each part, that would create a lot of unwanted duplication. Any change would require manually copying it to every part. This is both inefficient and prone to errors. In fact this why a lot of content authoring went to XML, so that common text blocks could be referenced all in one place.
Since all of my parts share the same chord progression I put that into one part, and then share that with all the other parts.
If I decide to change the chords or melody, I only have to make the changes once. All the parts update with the modification.
Reference the attached arrangement of Cry Me a River.
Also, I don’t think that it makes sense to wait and create the parts after the score is complete. I mean – when is a score actually complete. I continually fidget with my arrangements.
It also doesn’t make sense that users shouldn’t edit the individual parts. After the parts are in fact generated I would assume that the author should be able to proof the part for any typos. Doesn’t it make sense to correct any mistakes right in the part itself?
The application does seem to recognize this since nothing prevents users from editing the individual parts. (As an application developer I am aware that if an app allows users to do something, then they will. A corollary of that is if a user can cause an app to crash, then that is a bug.)
Hope this explanation better illustrates my use case.
If y’all have a better way to accomplish this goal of reducing duplication, please add your suggestions.
Thanks,
Brian
@mrbbolt...
Earlier you wrote:
(Note: I've been doing this for few years without any issue, but over the summer I started experiencing these crashes.)
Can you remember if this issue surfaced only when you started using (and editing) linked TAB in generated parts?
Also:
I would prefer to work in the parts themselves because they are less cluttered.
So, would creating a score with no linked TAB staves at all, then generating parts (without TAB of course) allow you to "work in the parts themselves" -- free from these crashes?
Then when finished, you could add linked TAB wherever needed.
In reply to @mrbbolt... Earlier you… by Jm6stringer
I was previously editing linked TAB without these issues.
In 2019 I raised a case to report issues with the fret diagrams.
https://musescore.org/en/comment/968663#comment-968663
After that was resolved I continued arranging scores the same way without issue until earlier this year.
As to your suggestion about decoupling the tab from the notation, that would sorta defeat my use case. If I were just printing finished arrangements, that wouldn't be a problem. But I found the linked tab feature really powerful for porting arrangements between instruments and experimenting with the voicings and possible fingerings, etc.
So -- no -- it isn't a must-have feature, but it had been working. (And if it isn't a best practice, knowing that it doesn't work will keep me from laboring the point.)
In reply to I was previously editing… by mrbbolt
If you read the suggestions carefully, you'll see there are still some perfectly good methods listed there that do allow for the tab and notation to remain linked - either waiting until the end to generate the part, or temporarily hiding staves you don't want to look at while editing, rather than using parts for this purpose. Hint: the timeline makes hiding instruments really simple, just click to the left to toggle visibility for each instrument.
If you know which version actually worked for the use case you describe and when it stopped working, that would help in figuring out how to fix it. As it is, I would recommend filing the issue (submit to the issue tracker, severity "Critical") so it can be investigated further.
In reply to If you read the suggestions… by Marc Sabatella
Hi Marc,
I do really appreciate the work-around suggestions. While -- of course -- work arounds aren't ideal, they will keep me from becoming too frustrated. In fact I have discovered most of these workarounds already. However, I had not though of hiding staffs in the main score page. I think that would work fine. Editing there seems to work fine, that way I can defer generating parts until ready for distribution.
Now that y'all have provided some really helpful feedback, I gather a bit more documentation and submit the issue. I'll also try reverting back to some earlier versions to see at what point the issue presented.
Thanks,
Brian
In reply to Hi Marc, I do really… by mrbbolt
I'm really glad to see this discussion because I've also had issues with linked staves in Parts.
I haven't noticed file corruption per se, but I encountered a few instances of unexpectedly duplicated slurs with MuseScore 3.6.2, MacOS.
I don't recall perfectly—and I'll search for an affected score to submit—but I think the additional slur appeared only in the Part, and when I deleted either of the Part's slurs both Part slurs disappeared ... as did the slur in the main score. In other words, I never found a way to delete the extraneous slur.
Marc wrote > > I recall someone once having a problem vaguely similar to this some years ago, and a bug being found and fixed as a result, but I'm not aware of any known remaining issues that would cause this to still happen.
mrbbolt wrote > y’all have provided some really helpful feedback, I gather a bit more documentation and submit the issue.
Does anyone one know if there are any existing Issue Tracker posts on this?
scorster
In reply to I'm really glad to see this… by scorster
@scorster... You wrote:
I'm really glad to see this discussion because I've also had issues with linked staves in Parts.
Ah...
I was waiting for you to make an appearance here ;-)
The waters are murky indeed when it comes to linkages: be it a part linked to the main score, a TAB staff linked to a standard staff, and now alas, we have a part - containing a linked TAB - which, in turn, is linked to the main score. My head hurts just reading about this. ;-)
Fortunately for me, my primary interest in all this linkage stuff was back when we were coming to grips with unsynched velocities between TAB and notation staves.
In reply to @scorster... You wrote: I'm… by Jm6stringer
jm6Stringer wrote > Ah ... I was waiting for you to make an appearance here ;-)
jm!!
Glad I didn't disappoint!
jm6Stringer wrote > The waters are murky indeed when it comes to linkages: be it a part linked to the main score, a TAB staff linked to a standard staff, and now alas, we have a part - containing a linked TAB - which, in turn, is linked to the main score.
... 'bout sums it up.
jm6Stringer wrote >Fortunately for me, my primary interest in all this linkage stuff was back when we were coming to grips with unsynched velocities between TAB and notation staves.
Indeed. That was very important topic to me, and it seems if fizzled with (IMHO) the "sub"stantial conclusion that MuseScore is right to not sync velocities:
a) between the Part and main score: because velocities are not notational aspects, and therefore are "layout, sort of" and layout matters are independent between the main score and parts. Dead stop.
b) between a linked staff and the "parent staff": because MuseScore doesn't sound the linked staff anyway. Ultimately, for the time being, the use case I led with was disqualified, minimized or ignored. And that's where it stands—although I think I posted a request in the Issue Tracker.
BTW, the afore mentioned discussion branched to this thread.
scorster
In reply to I'm really glad to see this… by scorster
I don't know if underlying file corruption exists in the attached score, nevertheless it appears something's awry with its main/part linkage.
Duplicate objects in Parts - Menuett.mscz
Somehow the attached score got to a state where a single Staff Text object in the main score is linked to doubly-displayed Staff text objects in the Parts. Deleting the Staff Text object in the main score clears all. Deleting either of the twins in the Part deletes the other twin and the related Staff Text object in the main score. (When the problem occurs the doubly-displayed objects overlap precisely due to identical layout properties (such as x/y properties) in the Part, preventing the issue from being immediately apparent. To make the "double display" obvious I offset them in the score.)
This score also has a issue with a Dynamic mark that essentially matches the description above.
If development needs steps to replicate I'll see if I can outline that. Presently I can only say I believe I added the Staff Text and Dynamic mark objects to the main score (I think) after generating the Parts.
scorster
In reply to I don't know if there's… by scorster
Presently I can only say I believe I added the Staff Text and Dynamic mark objects to the main score (I think) after generating the Parts.
That does usually just work. It does not in this score though. Reason might be the linked staves?
I can't reproduce it though, so yes, steps to reproduce this would be needed
In reply to _ Presently I can only say I… by Jojo-Schmitz
Jojo wrote** *That does usually just work. It does not in this score though. Reason might be the linked staves?
Jojo, are you saying you're able to replicate the behavior in this score? If so we're in the same boat. For instance, when I add a note in the main score, and attach a dynamic, the Part get double vision of the added dynamic. (However, in contrast, adding a dynamic to a newly added note in either Part does not result in double display.)
On the other hand you may mean that you're unable create this behavior in a newly generated score. Maybe I'll attempt that today or tomorrow, but generally I don't see such issues with linked Parts. Nor I have I tried to deconstruct this score to a point where the problem disappears.
Presently the only workaround is toggling visibility of one of the twin displays in the Parts. And yikes, I don't want to go there.
scorster
In reply to Jojo wrote** *That does… by scorster
Yes, I can reproduce the issue with your score, but not with a score created from scratch
Another workaround is to delete and regenerate the parts.
That does fix the existing duplicates and also don't create new ones
In reply to I don't know if there's… by scorster
@scorster : Just a question so that I can better understand your approach: while you have only entered two measures, what is the interest, what concrete and specific advantage(s) do you find - since you already have linked staves in the main score - in creating parts at this stage of the score ?
In reply to . by cadiz1
cadiz1 wrote >while you have only entered two measures ... what concrete and specific advantage(s) do you find - since you already have linked staves in the main score - in creating parts at this stage of the score?
Actually, I had completed note entry throughout the score before generating parts. I submitted a stripped down version of the example score (with notation only in measures 1 and 2) to focus attention and eliminate distraction, and to see if the deletion of extant objects in the score might mitigate the problems, thereby pointing out a possible trigger.
That said, I would hope that MuseScore's part linkage would be robust enough that—at any stage of score completion—scorists could confidently enter notational objects in the main score or Part without issue. The developer of Overture used to frequently state: "Always complete your score before performing x!" Apparently this was due to fragile underpinings and rogue behaviors that he was neither able to fully comprehend nor remedy. That advice always struck me as merely defensive, and equivalent to telling those using a specific text editor, "Always complete your novel before adding capitalization, punctuation or paragraphs."
I believe MuseScore's score/Part linkage is intended to provide a reliable connection. If so, there are just some problems to solve.
scorster
In reply to @mrbbolt... Earlier you… by Jm6stringer
I believe that this issue started when I re-imaged my computer over the summer. At that point I made sure I had the latest versions of all my software including Musescore.
I have now tested previous versions of Musescore.
MuseScore-3.5.2.311459983-x86_64.msi contains the bug.
3.4.2.9779 64 bit does NOT.
I'm reverting a couple scores back to this version for more testing.