Enharmonic spellings appear changed after save/load cycles (MS 2.0.3)
I don't have a smoking gun for this issue, but it seems to me that enharmonic spellings I've chosen when entering notes are sometimes changed after one or more save/load cycles. For example, I might see an A-sharp where I'm sure I entered a B-flat originally.
Has anyone else noticed this? I gather MS has its own algorithm for choosing enharmonics when a page is rendered; does this mean that when a score is saved, only the absolute pitches are kept, and the enharmonics regenerated algorithmically on load? I know about ctrl-J for manual respelling, but if I make deliberate changes once, I'd like to have them stick across save/load cycles.
Also, given that MS is primarily intended for typesetting, undesired enharmonic respelling could be an issue in, for example, notating music using the equally-tempered 19-tone scale, where e.g. A-sharp and B-flat are different notes - never mind that there is no provision for synthesizing music in other than the 12-tone scale.
Thaniks in advance for any light shed on this issue.
Comments
How did you enter the notes, and how did you choose the enharmonic spellings? There was a bug in an earlier version of MuseScore (2.0, 2.0.1 maybe also) where the spelling could lost on notes that were originally entered using one spelling but were then flipped to another spelling via the "J" command. This is fixed for 2.0.3 (and I think 2.0.2, although I could be wrong). but scores that were originally edited using one of those older versiosn would still have the bug. It would go away if you edit with 2.0.3, though.
If you are seeing a problem with scores created and edits made in 2.0.3, could you attach the score you are having problems with and give precise steps to reproduce the problem?
BTW, not sure what you mean when you say MuseScore has its own algorithm for choosing spelling. normally, *you* choose the spelling, not MuseScore. Eg, enter an A and raise it, you get A#, but enter a B and lower it, you get Bb. The only case where MuseScore normally needs to decide for itself is input via MIDI or the Piano Keyboard window, and indeed, it does have to guess in these cases. It's algorithm is basically to choose the spelling most closely related to the current key. Eg, in the key of G with one sharp, C# is only one notch away on the circle of fifths, whereas Db is a long ways away. It's the other way around for, say, the key of Eb.
In reply to How did you enter the notes, by Marc Sabatella
If you use the arrow keys to adjust the pitch--I find it the fastest way in most situations--Musescore will choose the optimal spelling for you, based on the rules Marc described above. e - up arrow gives you f in C major, but e sharp in A Major; c - down arrow gives you b in C Major, c flat in in D flat Major etc.
The algorithm is almost always correct. But even in this case I have never seen a spelling flipped by Musescore without my input. Not even in 2.0.1.
In reply to How did you enter the notes, by Marc Sabatella
Marc: Thanks for mentioning the "J" command bug, which I had no knowledge of. When I started work on the current score I may have not updated to 2.0.3 yet, so it's possible the notes where I was seeing the odd behavior were entered using 2.0.2 (although I don't recall using "J" - or ctrl-j - on any notes).
As for what I said about MS having "its own algorithm for choosing spelling" I think this is because I may have come across a previous post on this topic that mentioned an algorithm, without understanding that this was referring to MIDI input.
Meanwhile, when using ctrl-j I discovered something odd: if I have two notes tied across a bar line, and I use ctrl-j to change the first enharmonically, the second does not follow - as would be the case if, for example, I used up-arrow followed by down-arrow to change an F-sharp first to G, then to G-flat; the second note will follow. In the attached file, I tried changing the F-sharp in the first bar to G-flat first using ctrl-j, then using up-arrow and down-arrow.
In reply to Marc: Thanks for mentioning by dhfx
What you described about using CTRL-J to change the spelling of a tied note happens if you put an accidental on the second tied note to assure the proper note is played by the musician. If you respell or put a non mandatory accidental on the second note it will untie the notes. If you tie them back together the second note will be respelled with no accidental. MS should recognize that the note has not changed and keep the notes tied with the human's spelling. This is especially useful (and should be automatic) after a page break or key change. Someone in another post mentioned that MS is primarily notation software and this is a common notation.
In reply to What you described about by mike320
What you describe is true, but it's not the issue I was posting about - although I agree that MS should allow a repeat accidental on the second of two notes tied across a bar line.
In reply to What you describe is true, by dhfx
I see what you mean. And when the second doesn't follow the first it doesn't change its sign either. That would be major confusion for the musician.
In reply to Marc: Thanks for mentioning by dhfx
First, note J and Ctrl+J are subtly different. J changes the spelling for both concert pitch and transposed pitches; Ctrl+J changes just the spelling for the current mode. Unless you are specifically wanting the latter effect (to have, for instance, one spelling for a concert pitch score but another for a transposed part), you should be using J rather than Ctrl+J.
The behavior of either command with respect to ties is kind of deliberate, although not ideal. It is intended that it should be possible to have a tie of a note to its enharmonic equivalent, and this is, I think, the way it was supposed to work. but as noted, it currently doesn't do so well, as the accidental does not appear on the second note, and attempting to add it breaks the tie.
For the next release, this behavior has been changed so that J on either note of a tie changes both. But it will also be possible to add the tie between notes of different spelling directly, by first entering the notes then the tie. In 2.0.3, this loses the accidental, but this is fixed in the development builds.
In reply to First, note J and Ctrl+J are by Marc Sabatella
Marc: Thanks for clarifying re J vs. ctrl-J; the difference is indeed subtle.
As an aside, it seems reasonable to repeat the accidental on successive tied notes at the beginning of a new line, or especially after a page break (so the performer won't need to flip a page back to see what the note was). I recall once being in a hyper-pedantic mode where I insisted on repeating the accidental in EVERY measure - clearly overkill. But it might be worth having an option to select automatic repetition of the tied accidental after line or page breaks.
I'm eagerly looking forward to the next release.
In reply to Marc: Thanks for clarifying by dhfx
As far as I am concerned, we could probably get away with just displaying the accidental automatically at the start of a system; if you want to hide it you could always mark it invisible. But a style option is not a bad idea either. I had thought there was already a feature request for this, but I cannot find one now, so maybe I imagined it. Could you file one, using the "Issue tracker" link in the menu at right?
In reply to As far as I am concerned, we by Marc Sabatella
Marc: I went to "issue tracker" but I wasn't sure I wanted to report this as a bug, so I created a new post on the "feature request" forum, referencing my comment immediately above yours. Hope this is adequate.
In reply to Marc: I went to "issue by dhfx
It really is better to use the issue tracker - the forum is more for initial discussion before making a formal request. Use the drop down menu to change from bug report to feature request.
In reply to It really is better to use by Marc Sabatella
Just created new feature-request issue #142491.
In reply to Just created new by dhfx
crosslinking by putting [ and ] around the issue number: #142491: Automatically add continuation accidentals on notes tied over multiple measures or line breaks
I am now using 2.1 and still seeing this issue - notes with accidentals being enharmonically changed between save and reload. I have seen it with notes tied across bar lines - e.g., a tied B-flat is changed to A-sharp in the first measure ONLY, while remaining B-flat in the following measures. If I hit J to change the A-sharp back to B-flat, the B-flat in the following measure(s) changes to A-sharp! The only way I can fix this is to select the note in the first tied measure and use up-arrow and down-arrow to move it a half-step up and then down; when I do this, it works correctly and the note reverts to B-flat in all tied measures.
Has anyone else run into this problem? Generally the program seems to favor sharps over flats - a note I originally entered as e.g. E-flat will be changed to D-sharp, but not the reverse.
In reply to I am now using 2.1 and still by dhfx
In order to help we would need you to attach your score and precise steps to reproduce the problem.