Enharmonic change made using "J" on concert pitch instrument not saved

• Mar 22, 2015 - 18:18
Type
Functional
Severity
S3 - Major
Status
closed
Project

6e47f74, Ubuntu

1) score in C for piano or flute or other non-transposing instrument
2) note entry, C Up (to enter C#)
3) select the note
4) Press "J" to change to Db
5) save
6) close
7) reload

Result: note has reverted to C#

I beleive this is because of the code that prevents concert pitch instruments from writing both tpc1 & tpc2. The "J" command currently affects only the current "mode" - either concert pitch or transposed - so it always creates these out-of-sync situations.

I think what makes msot sense is for the "J" command to set both tpc1 and tpc2 for concert pitch instruments. For transposing instruments, I think is important that there exist a way to have different spellings for concert pitch and transposed modes - in fact that's a big part of why we have independent tpc1 and tpc2 in the first place rather than always calculating one from the other. Currently, as far as I know, "J" is the *only* way to make this happen - other methods of respelling a note like arrow up then down always affect both tpc's.

Another possibility: we could consider making "J" by itself always affect both tpc's (for transposing as well as concert pitch instruments), but have Shift+J or Ctrl+J or something affect only the current view.


Comments

Yes, that commit is indeed the cause.

Workarounds are to either not use "J" to change pitch for concert pitch instruments, or to do your work in "concert pitch" mode if using a concert pitch instrument. If using mixed concert pitch and transposing instruments and the final output is not intended to be a concert pitch score, then not using J for the concert pitch instruments is the only way, I think.

I agree that the potential for significant loss of work justifies raising priority.

Thanks for the workaround. Useful to know if the issue is not fixed before the 2.0? This will most probably the only opportunity for me (accurately, for the guitar with treble clef 8vb) to use the "Concert Pitch" to enter a score! Not sure that all users know this :(

I suspect more users will know about and use Concert Pitch than the "J" command, since Concert Pitch has been around a long time and exists in all scoring programs, and "J" is something that is new to 2.0 and most people won't know exists.

Is your reaosn for using "J" to change spelling of guitar ntoes originally entered via tablature? That would make sense; I hand't considered that usage, I had thought of that command as being more for people using MIDI input or people doing scoring for orchesteral music would tend to use that command.

Anyhow, it doesn't seem very likely that any new bugs will be fixed for 2.0 since the sources were shipped to the packagers yesterday.

Not sure to understand why you involve the tablature in that issue? I mainly uses the input via the standard staff (sometimes in Tab for historical works)
My concern was due to the memory of this thread on the English forum: http://musescore.org/en/node/43216
I spent a little time to understand and reproduce the attached image of this thread (I know the original score), with a necessary and important use of the "J" command. So much so that I wrote a reminder to be sure to be able to reproduce! :-)
And so, I imagined with difficulty to lose the fruit of a long work in reason of this issue!

EDIT: oups.. not seen your previous message before sending mine.
True also for the copy/past :(

I mentioned tab because I was imagining that would be your reason for caring about "J". It's not something most people would otherwise need except in the cases I mentioned - but yes, entering E# and Cb etc or other notes that are enharmonic with notes in the key would be a time when it could occasionally be useful. So are the toolbar accidentals, though, and in msot cases they will be the easier and more discoverable method. It's just that one special case where the same note appears multiple times with different accidentals that requires use of "J", I think. Not something most people will ever likely to runb into or discover, I think. Which isn't to say it isn't an important bug to fix, but not, to me, worth holding 2.0 up over, or even in itslef a reaosn to rush a 2.0.1 release out afterwards.

I have implemented my proposed fix where "J" affects the enharmonic spelling for both concert pitch & transposed modes, but Ctrl+J affects the current mode only. I like how this feels - very much like how Ctrl+drag lets you create a local key or time signature change. Although if someone felt strongly it should be the other way around, or that *both* commands should affect both mdoes for non-transposing instruments, that's would be OK too.

I might also propose we reconsider the change that led to this problem in the first place: instead of only writing tpc2 for transposing instruments, I think we should go back to writing it any time it differs from tpc1. I do understand that the change was made to "fix" scores that had previusly been "corrupted" by use of "J" or by bugs in older builds that allowed tpoc1 & tpc2 to get out of sync when this shouldn't normally happen for concert pitch instruments. However, I think in many of these cases, we are actually throwing away the wrong value - it's tpc2 that more likely reflects the user's intent. Well, maybe - it's really impossible to know. Which is why I think we should probably just go back to writing both any time they differ.

But the use case I am concerned about is the one in this issue, also see http://musescore.org/en/node/52756. User creates a score for non-transposing instrument like piano, it defaults to concert pitch off and user never changes that. User enters notes, uses "J" or "Ctrl+J" (currently these do the same thing except on tab staves) to change spelling, so this sets tpc2 to the desired value but leaves tpc1 wrong. When writing this score, then, it is tpc2 that is in tune with the user's desire.

Status (old) patch (code needs review) fixed

This is merged in both 2.1 trunk and 2.0.1 branch. It's possible the fix might be revisited in the trunk as there may be some more structural changes coming before 2.1.