It seems that copying notes (in this case, notated chords in a piano staff) to another musescore project causes musescore to crash, and simply tells us that "musescore has stopped working" with no other information. This only happens when copying between projects, not just on the same project.
Comments
Which version of MuseScore, on what O/S.
And don't assign to yourself, unless you plan to provide a fix ;-)
Ah, my bad, I'll add that :P I'm running Windows 7 64-bit. You want system specs? I haz them.
And I'm pretty sure I set it as "unassigned"... If not, I don't see where it says it's assigned to me.....
Hi OmnipotentPilot
Could you give more precise steps? What is the other MuseScore project?
Was it 1.2, or a nightly build you used? It might not actually be possible at the moment (due to this: #19309: Microsoft Security Patch causes Musescore font error), but if it wasn't, could you try a nightly build (link ) sometime to see if the problem exists there? The focus of the Issue Tracker is now 2.0.
For future reports, could you read this guide ?
Thanks :)!
Yeah, I'll read the guide x) Sorry, my bad!
It's 1.2, Both projects are similar. One is a score (Piano, two saxophones) and the other is just the piano part. (What other info can I give you about the projects?) I'll take a look at the nightly and the security patch....
Is it two separate scores?
If you wanted to give me all the steps and scores (or enough to reproduce with), I could try for you (I am primarily on Mac, at the moment).
Okay. I have two open in different tabs. One includes the three instruments, the other just piano. I write out all the music in the score then transfer each part to a separate project (in a separate tab) so one does not have to print the entire score, just their instrument part. The saxophone parts copy just fine to the other projects, but the piano never does, because it contains chords with chord names (inserted using ctrl/command-K) above the staff. This is in the treble clef of piano.
Anything I'm missing?
First, are you aware you don't have to do all that copy and pasting at all - MuseScore is perfectly capable of generating the parts for you? See File->Parts, and the documentation in Part extraction . This works much better than copy paste, since it preserves all text markings and much more.
But second, what you are tryng *should* work, even though it is much more work than necessary. And in general, it does - the mere fact that a chord symbol is attached to a note doesn't prevent copy/paste from working. i just tried it and it worked fine. So it must be something else about you score causing the problem.
Anyhow, the bottom line is, you'd meed to post the actual score you are having trouble with and exact steps to reproduce.
I did experience crashes with copy/paste between different scores too, but was never able to reproduce it reilably.
I had this happening esp. frequently, when creating a "collection score" (several different pieces in one score for a church service) from individual scores (containing only one piece).
These score having chods sysmbols might wel have been a contributing factor, but if so it for sure it is not the only cause, as this usually works. Triplets are a likely cause too, another is irregular measures.
However, this was/is with 1.2, for me at least, and I'd have yet to try whether the nightly builds do any better.
(crash->critical)
I'll just try to use parts, thanks for telling me about that. I'm lowering priority because it could be a bunch of other things, like something specific to this score, or corrupt musescore files, or maybe even a bad windows install. Especially because it doesn't seem to be repeatable. I'll fiddle around with it, thanks for your help guys!!!!
Critical reports are generally crashes and corruption, but it would still help if you're able to post the file (or send privately to someone) so it can be determined what is wrong.
Fwiw, I too have sometimes seen crashes pasting from one score to another - and pretty much always jazz scores, so chord symbols are certainly involved, but it's clearly not as simple as that. Similarly, I thought it might be slash notation or drum notation that was triggering it, but it's never totally repeatable.
I saw charshes, but never used slash- or drum -notation. Chords could be it, but certainly not alone, as I've been able to paste with chords too.
I attached a sample of music. I manually created the piano (chord) part, but trying to copy from the score to the piano part doesn't work.
The posted files do indeed reproduce the problem reliably.
After a brief investigation, I can see that the problem is indeed related to chord symbols, and I can see why it doesn't always crash. The crash occurs in paste.cpp, line 291 in current master, in cases where the source score has more staves than the destination score, and where the index of the staff being copied is more than the number of staves in the destination. The code here is attempting to correct for differences in transposition between the source and destination staves, but it doesn't take into account that the source staff might well be in a totally different score. It uses the *destination* score to get transposition information about the *source* staff. So, if the staff number of the source is more than the number of staves in the destination, it crashes. Even in cases where it doesn't crash, though, this code isn't going to work correctly when copying between scores, unless the source and destination have the same arrangement of staves.
I could easily prevent the crash by skipping the whole transposition adjustment if the source staff number is greater than the number of staves in the destination. But it would be better to fix the code to actually work. There is one other place in this same function (Score::pasteStaff) where the code uses the source staff index - something about skipping staves in a blacklist. This code also seems unconcerned with the fact that the source staff might be in a different score. I think it would be better to notice that the source is in a different score and deal with that information appropriately. But I don't know how to determine that.
Awesome, that makes sense. Thanks for all your work identifying that. I'm new to this, though, so what do we do next? Can we commit changes to the code? What's the process like to do that?
Anyone can make changes, sure - that's the beauty of open source. But the process of getting the sources and a build environment installed and running is a bit of work. I've already done this, so it would be easy for me to fix this. Except that as I said, I am not sure how to best fix it for real. So, I think we hope someone who understands the code better than I takes the ball from here - maybe just by giving me advice on how to check if the source is from a different score...
I think it would be better to notice that the source is in a different score and deal with that information appropriately.
Not sure about it. I think the clipboard should get an info that is usable wherever it is pasted. So in this case, the transposition information should be skipped, or stored in the clipboard in a score independent way.
That's a good idea. I don't know what the blacklist is about, so I don't know what might need to be stored in the clipboard to account for that. But the "copy" code could certainly convert all Harmony objects to concert pitch before writing them to the clipboard. Then they'd be in a known state on the paste. And that seems reasonable to do regardless of what else turns out to be necessary to handle the blacklist.
I'm assuming this will turn out to be straightforward, so I'll give it a shot.
Proposed fix:
https://github.com/musescore/MuseScore/pull/384
or: ready to commit...
I was assuming "patch" was different from "pull request". They are different things in general. But maybe the distinction is not relevant here?
No it's not relevant, patch (code needs review) can mean "pull request submitted". But even better than changing the status, it's nice to put fix #XXXX in your commit message.
The pull request has been merged. Thank you!
Great! Sorry, if you don't mind clarifying one more thing: the Git Workflow page mentions incorporating the issue number into the branch name as well as the commit message. I had done the former but not the latter. It's just the commit message that triggers the automatic fixing of the issue?
Yes, it's only the commit message that triggers the change of status of the issue.
Automatically closed -- issue fixed for 2 weeks with no activity.