Some pitches spelled incorrectly on transpose / concert pitch

• Dec 15, 2014 - 16:21
Type
Functional
Severity
S3 - Major
Status
closed
Project
MuseScore

Ubutnu 14.04, GIT commit: 654009a than Ab

1) new score for Bb clarinet, key of Db (concert)
2) verify concert pitch is off (score displays in Eb)
3) enter an Eb major scale in quarter notes (Eb F G Ab Bb C D Eb, no accidentals needed)
4) concert pitch

Result: C# Eb F F# G# Bb C C# - explicit accidentals present for the sharps
Expected result: Db Eb F Gb Ab Bb C Db - no accidentals needed)

Related issue:

1) My First Score or any empty C major score for non-transposing instruments
2) drag Eb key signature to first measure
3) enter Eb major scale
4) select all
5) notes / transpose
6) key signature - Db
7) OK

Result: Db Eb F F# Ab Bb C Db
Expect result: as above

So it appears both concert pitch and notes / transpose have note spelling issues, different in specifics but hopefully similar underlying cause

Comments

• Dec 15, 2014 - 17:56

Apparently the tpc's are created incorrectly on initial note entry. Same results whether typing notes or clicking in score. tp2 is correct, but tpc1 is already wrong after note entry. For MIDI input, tpc2 is actually wrong as well, but I assume that's just because how it is calculated, and that's this is really a result of the same basic cause.

I'm continuing to look into this although I am guessing the cause will turn out to be something having to do with the new keysign code I don't understand yet. I won't be offended if Werner wants to beat me to it :-)

Reply

• Dec 15, 2014 - 18:24

So far, not what I expect to see at all. The incorrect tpc values are the result of Note::setNval calculating them incorrectly, and that is because it is failing to correctly detect the current key signature. But this does not appear to be a result of any problem with the keylist - the problem is the chord for the note has not yet been assigned a parent segment, so "chord()->tick()" is returning -1. Making we wonder how this ever worked - and yet it clearly did until recently. Still investigating.

Reply

• Dec 15, 2014 - 19:41

I'm having trouble figuring out when/how this broke. Some time shortly after Beta 1, as far as I can tell, but I can no longer build from older sources as they don't seem to like Qt 5.4.

Here is another simpler set of steps to reproduce:

1) my first score
2) drag Db key signature to first measure
3) enter Db major scale
4) concert pitch

Expected result: no change, since score is non-transposing

Actual result: C# Eb F F# G# Bb C C#

Reply

• Dec 15, 2014 - 20:50

After testing on the example of comment#3, I can say that this issue occured on September 22.

The last Nigthly of September 20 (no Nigthly on September 21) is correct:
https://github.com/musescore/MuseScore/commit/d9bf96ba9a53d8552a8e89b54…

But not this Nigthly two days later: https://github.com/musescore/MuseScore/commit/d9331b60c8cf05edd7635951e…

The culprit is probably in the previous, here: https://github.com/musescore/MuseScore/commit/58763e6cc5762bb8ee588f674…

There is six other commits the same day, but seems no really related to this issue?

Reply

• Dec 15, 2014 - 21:33

I love that I could go out grocery shopping then come back and have the asnwer waiting for me :-). Thanks again, cadiz1!

Yes, this is the missing piece of the puzzle, should be able to solve it from here. Coincidentally, this change also relates to #41326: MIDI input while using tranposing instruments produces wrong displayed pitches, which I had just looked at for unrelated reasons. So the trick will be in fixing this without breaking either that or #33366: R key producing notes on wrong lines when used with transposing instrument (or anything else). But hopefully that won't be a problem.

Reply