transposition info incorrect when switching between score and part
I have marked this critical since it may cause loss of data, and it renders the linked parts feature essentially useless with transposing instruments.
Steps to reproduce using Windows 7 (c92b058):
1) open attached score
2) with Concert Pitch on, verify you see all C's in both staves, key signature of F major
2) with Concert Pitch off, verify the alto staff shows high A's and a key signature of D major
3) with Concert Pitch still off, view linked alto part
Expected result: alto part should show a high A and a key signature of D major
Actual result: alto part shows a high A but a key signature of F major (and reports concert pitch is now *on*)
At this point, part is now incorrect but there is no data loss - you can return to the score and see all is at it should be. You can toggle Concert Pitch mode on and off and the alto staff on the score always displays correctly. And if you turn Concert Pitch *on* while viewing the score, then view the alto part, it correctly shows the alto part at concert pitch: C's, key of F. Turn concert pitch *off* while viewing the alto part, and it appears correct: high A's, key of D.
However, if you then return to the score at this point, you again see the high A's, key of F; Concert Pitch now reports that it is on. Hitting Play confirms that the score is now incorrect. Toggle concert pitch off at this point and the display shows high F#'s, key of D.
It appears the transposition info is now permanently mangled, but it is possibly to reverse the procedure and mangle it back to shape. With the score show concert pitch *on* (high A's, key of F), return to the alto part. It will now show the correct results for concert pitch *off* (high A's, key of D), and will report that concert pitch is indeed off. Toggle concert pitch on, and the alto part correctly displays the C's and key of F. Return to score and everything is back to normal.
It appears that MuseScore is trying to remember the state of the the Concert Pitch toggle for the score and parts independently, but then not applying that information correctly.
Comments
As usual, I forgot the attachment.
There seem to be two problems:
1. The Concert Pitch toggle is only changed for the currently viewed score (as you suggested)
2. The key signature changes are also only done for the currently viewed part.
Since the notes however are changed in all parts/scores, we get the problem you described.
I'm trying to fix this.
proposed fix https://github.com/musescore/MuseScore/pull/75
Thanks - this has been one of the biggest inhibitor to using the trunk for me. I'll be excited to try more now, assuming it works of course. I do have a build system going on my machine, but am still fuzzy on how Git works. Is there a way I can try out your patch?
This worked for me:
1. add a remote to my fork (let's call it heuchi)
git remote add heuchi git://github.com/heuchi/MuseScore.git
2. fetch it
git fetch heuchi
this will show you a list of all my online branches.
3. checkout the branch you want to test:
git checkout --track heuchi/18099_concertPitchChanged
this creates a new local branch, which you can work on
4. build, test and please tell me how it worked...
I built a version of MuseScore from your patch and it seems to work as expected with respect to transposition.
However - and I don't know if this is related or not - clef changes don't seem to work any more. I can replace any clef in any staff, concert pitch on or off, and the notes don't change their display to reflect the new clef. They still play correctly.
I should mention that my build ended up recompiling an awful lot of code from the last time I build a week or so ago, even though I thought I only checked out your patch. I am still really confused about what I am doing with Git.
BTW, this might be totally unrelated and I might just have never noticed this before in other builds, but does shift-left/right arrow now do something pretty darned cool when in note entry mode? Or is that maybe some experimental code of your I accidentally grabbed?
Checking the latest nightly, I see both the clef bug (already reported as #14954: Clef change doesn't relocate notes in new score and the interesting (nice!) shift-arrow behavior are present there too, so this does not appear to be anything related to your patch. As far as I can tell without clefs working properly, your patch works as it should for me.
Thanks for testing that one.
Well, I would have been very surprised if my code had done any changes to clefs and any input feature...
I just created a completely unrelated branch and made a couple of commits to it, pushed it and tried to issue a pull request, and found that somehow, your commits got added on top of mine as part of my brnach. Am hoping someone can help me straighten that out, but meanwhile, this serves as a bump on your pull request and as a heads up to be on the lookout for duplicate commits.
What's the expected behavior regarding parts and concert pitch?
If the score is displayed and you switch concert pitch on or off, should the parts be impacted? Or should the concert pitch state be attached to each part separately ?
As far as I can see the pull request will make the concert pitch switch work on the score at a whole including the parts. Is that the expected behavior?
No, I would definitely *prefer* to be able to have concert pitch score and transposed parts if I wanted to - the score and parts should ideally remember their own transposed states. It would be worth comparing against Finale and Sibelius to see how their linked parts work, but that's my expectation.
If I could trust that toggling concert pitch on and off were a completely safe operation that didn't affect score data at all, only how it is displayed - like changing zoom level, say - then I might be more comfortable with a scheme where it applied globally. Because I wouldn't have any qualms about flipping the score to concert pitch temporarily for some editing or to print it that way for my own use, then back to transposed. Maybe that's how Finale did it, and I forgot? I actually only had linked parts very briefly before switching to MuseScore and can't recall, and don't have it installed on my current machine.
Another possibility to consider: parts are virtually never printed concert pitch. It could be decided that parts are *always* transposed, and concert pitch affects only the score. If you really want concert pitch parts, then don't define a transposition for those instruments in the first place. Not sure how that would fly, but it is also a model worth considering.
I checked Sibelius earlier. The score is always by default in concert pitch while the parts are not. Changing the concert pitch state of the score doesn't affect the part and vice versa.
Seems the pull request had been withdrwan and closed. Has this problem been fixed in a different manner?
The proposed fix resulted in a different implementation. See posts #10 to #12.
The requested behaviour will require some more changes which I did not have the time to do. So I withdrew the pull request.
Just an update that this is still an active problem. You can still reproduce it with the original posted score following the original steps, and it's still very serious. However, I did *not* have this problem with another score I created a couple of days, so I have now investigated further.
It turns out that *if you are in concert pitch mode at the moment when you first generate the parts*, you see this bug. That is, if you then turn concert pitch off in the score, your parts for transposing instruments will be wrong. However, if *concert pitch is turned off at the moment when you first generate the parts*, then you will not see the bug, exactly (you can still trigger other bad effects; see below).
I don't know if the score posted if already "corrupt" in some sense or not. But here is another just like it except the parts are not yet generated. If you want to trigger the bug, open this score, verify Concert Pitch is on, do File / Parts / New All, then follow the steps in the original problem report. If you want to avoid the bug, open this score, turn Concert Pitch *off*, do File / Parts / New All, then turn concert pitch back *on* and follow the steps in the original report.
I'd like to say if you generate parts with concert pitch off you are safe, but unfortunately, that's not true.
Take the score in the state we just left it (load score, turn off concert pitch, generate parts, view the alto part with concert pitch still off). So far so good. Now turn concert pitch back on, Part looks good - key of F, notes are C's. But now go back to the score. You'll see C's as you should, but key is D (so the C's all have natural signs).
Bottom line: things are still pretty broken with respect to linked parts for transposing instruments.
But FWIW, aside from that - which I didn't notice until I decided to try to print an extra copy of my clarinet part in concert pitch for the benefit of a flautist - things are looking better with respect to linked parts than I might have guessed given how broken this is. Or, in a reference maybe only Americans will recognize - Mrs. Lincoln reports that other than "that", the play itself was actually pretty good :-)
With nightly build cfbf66f I found that the issue is still there (in the Bb clarinet part), but the attached score can be repaired (i.e. the incorrectly transposed part corrected) by doing the following BEFORE SAVING AND LEAVING MUSESCORE:
In the part, select 'Concert Pitch' and drag an F major key signature to the 'voice' stave.
OR
In the part, select 'Concert Pitch', then go back to the main score and select 'Concert Pitch' there.
The formerly incorrect Bb clarinet notes are transposed down by a tone during the second step (in the main score select 'Concert pitch') and the composition can be recovered, saved etc.
Still not a great situation, because re-loading the score means the error cannot be reversed and data is lost - hence it's still a critical bug. The issue is definitely associated with the generation of parts, as others have noted earlier. If I do all editing with just the main score loaded, everything is OK until the parts are created.
Key changes within a piece seem to send the transpose algorithm into a tailspin as well...
Enrico_94
There's also plenty of weirdness if you change key signatures after creating parts.
* Take Marc's score attached above, and create parts.
* Turn off "Concert pitch" in score and parts.
* In the score, drag 2-flats key onto flute part. Alto sax staff has 1 sharp. Correct.
* Now view the sax part. Oops, it has 4 sharps instead of the 1 sharp it has on the score.
* Drag 3-flats key onto sax part. It shows as 3 sharps instead. C Major would be excusable, because alto sax should be in C Major when concert pitch is Eb Major.
* Drag C-Major key onto sax part. It shows as 6 flats. By now I have no idea what to expect, I'm just having fun trying to guess what key signature will show up. Should it be C Major? Or 3 sharps? Surely not 6 sharps though.
Is #25184: concert pitch confuses parts a duplicate of this one?
03de8d7d4a tries to fix this problem. Transposition is part of the style and independent for every part. Current implementation changes the tpc for every note which may change the score if you switch concert pitch & back. In a next step i will implement two tpc values for concert pitch on/off like its implemented for clefs.
Thank you, I am *so* looking forward to this! This has been the single biggest sore spot for me with the development builds pretty much from day one. Now it really feels like it's just "minor" (in comparison) bugs left to fix...
BTW, if I am understanding your comment about tpc correctly, it sounds like this may come for free, but I'd like to be clear about what I think the most desirable behavior would be:
I would *love* it if it were possible for the enharmonic spelling of a note to differ according to concert pitch state. That is, for Bb instruments, if I spell a note as "E" in concert pitch, I of course expect the transposed version to read "F#". But if I change it to "Gb" in the transposed version using the "J" shortcut, it would be wonderful if it remained "E" rather than changing to "Fb" in the concert pitch version. On the other hand, it I make the change from "F#" to "Gb" by hitting up arrow then down (ie, actually altering the pitch twice), I'd probably expect the concert pitch spelling to change too. In fact, that's how I'd expect to have control over whether my change affected both concert and transposed representations or not: "J" affects just the current view, anything that actually alters the pitch would affect both.
I can't say for sure if this is what everyone would expect or want, but I thought I should mention it.
See 5a547d3, a first fix
So far, I can at least verify that indeed you can set transposition separately for score versus parts. so the framework does appear to be in place.
However, things don't work right yet. Turning off concert pitch actually changes the playback as well. That is, if I have a Bb clarinet score, turn on concert pitch, enter "C D E F", then turn off concert pitch, it displays "D E F# G" as it should, but it actually *plays* as "D E F# G" rather than as "C D E F". And entering notes with concert pitch turned off really messes things up - they play back another step higher still. That is, if I enter "C D E F" with concert pitch on, then turn concert pitch *off* - thus transposing to "D E F# G" - and then enter an "A" (concert G), that "A" will actually play back as a *B*. This is all before I even generate parts.
I understand this is still very much a work in progress, but it's actually considerably worse than before at the moment.
d995222b65
Still not quite right.
(Like Marc, I wasn't sure whether his files are somehow corrupted so I started from scratch.)
* Create a new score with flute & alto sax parts. Add F-Major key signature and concert C in both staves. This is a newly created score that's identical to Marc's "No parts".
* With Concert Pitch turned on, File | Parts | New all | Ok.
* Flute part is correct.
* Alto sax part correctly shows high-A, but key sig is F Major. Should be D Major.
* Turn on concert pitch for alto sax part. Correctly shows concert C, but key sig is 4 flats instead of 1 flat.
This version is probably better than the last version I tried, but still seriously broken for transposing instruments.
Confirmed. To be clear about step 1, you can select F major as the key while in the wizard. Once the score is created, turn concert pitch on and add the C's. Then generate parts with concert pitch still on. You get the (wrong) results described.
BTW, I had tested this when the fix was first made, and my impression is that this actually *was* fixed. However, this particular aspect of it broke as a result of the one-line change made for #4487: Part should be transposed pitch regardless of full score, and lasconic noted the exact same issue in his comment there.
If I comment out that one line, then things really *do* seem to work correctly regarding parts & transposition (aside from the fact that parts start off in the same state as the score rather than being forced to concert pitch off by default). I didn't test this very thoroughly yet, and of course, I *would* like to see parts forced to concert pitch off by default. But I guess the fix won't be quite as simple as what was originally tried. Actually, it very well might be; it will just be a *different* simple fix, like waiting until after the part is completely set up and then calling cmdConcertPitchChanged.
Of course, there are still other transposition-related bugs that were introduced along the way, not related to parts at all. But it feels like the worst of it is over.
Fixed in 76f9f663f6
This is better. The sequence of events described above now works correctly.
But if you change the Alto Sax part to a Tenor Sax, the resulting notes are wrong. You get a different outcome depending on whether Concert Pitch is on or off at the time you change instruments.
I don't know whether this counts as a new bug. From the user's point of view, it's just a symptom of transposition still being terribly broken. It's nice to see it moving in the right direction though.
Sounds rather like #21744: Actual notes are changed if transposition properties are changed with Concert Pitch off. That report says it's an issue only with concert pitch off. If you find otherwise, you might post there, or start a new issue.
Havuing one big issue "transposition is broken" isn't useful, though. It's better to have separate issues for separate bugs, so we can track which are fixed and which still need work. The actual bug here relates to parts specifically, and as far as I can tell, that much is fixed. What are left are a few general transposition bugs, many (most?) of which are filed individually already.
Automatically closed -- issue fixed for 2 weeks with no activity.