Remove automatic addition of accidentals during note entry
Steps to demonstrate:
New score: Piano template, C Major, 4/4
Enter quarter note (crochet) B 3rd line top staff first measure
Add flat to same note
Enter a subsequent B quarter note, same line same measure
Current behavior:
Program automatically adds natural to second note
Desired behavior:
Program does not add any accidental to second note
Discussed in http://musescore.org/en/node/7284
Reasons:
More consistent with how most musicians are trained
Consistent with behavior of Sibelius, Finale and Noteworthy
Comments
Comment removed because it doesn't represent the consensus view.
Me too I find the current behaviour counter-intuitive in many cases.
However, it is at least predictable and, in several occasions, I found it more easy to understand and manage than a possible automatic -- and silent! -- management of altered notes; the main reason being already cited in Bill-G post: "it's not possible to accurately predict what the user intends".
The matter does not seems to me "add or change accidentals", but rather "adding or change accidentals to the note pitches OR to the note written form" (and ultimately stems from the accidental conventions of modern Western music notation). I'll try to explain.
Case 1): In measure where there is already a B flat (not in key), adding a new B.
a) Currently the program keeps the new B "as it is" (no accidentals in the note pitch) and therefore adds a natural to the note written form.
b) If the program would convert this new B to B flat, it would not add a flat to the note written form but would add a flat to note intended pitch.
Case 2): In measure with 2 B flat, raising the first one to B natural.
a) Currently the program leaves the second as it is (B flat), adding to it a visible flat (form is changed to keep the 'substance' unchanged)
b) If the program would change also the second to B natural, it would keep the same written form, but at the expense of silently modifying the note pitch.
In case 2), I strongly prefer the current behaviour (a) over b.
In case 1), I see the point of this feature request, but I am not so sure I would like the behaviour inconsistency or the implicit deviation from the input note. I am also not so sure that, in this case, the second, new B is going to be a flat more often than not (in the case of my MuseScore usage, it probably would not).
In conclusion, I suggest prudence before changing the current program behaviour.
Thanks,
M.
Comment deleted -- will continue discussion the forum.
Needs more discussion, with input from more users: http://musescore.org/en/node/7284
Request applies to note entry only. Editing should remain unchanged.
Consensus in forum discussion is best represented by Input method change .
Since the last post here, the same discussion went on again and arrived at the same conclusion (see this thread: //musescore.org/en/node/8417 ):
change accidental mngmt while input - keep current way while editing.
This is an indication that the issue has some relevance and something should be done with it, at least in trunk (too late for 1.0, I believe).
So: BUMP!
M.
Another forum thread on mostly the same topic:
//musescore.org/en/node/10593
M.
And it is currently being discuused again - so bump :)
A first implementation of this feature request is available in the current nightlies ce351a2ed7
However, following the exact step in the main post, you end up with a Bb and A#. For both mouse and keyboard and it happens for all flated notes.
On a related note, the implementation of this feature request broke the mouse entry in tab staff. Click on any string will crash MuseScore while it is trying to find the current accidental.
The crash and the enharmonic regression are fixed! Thanks Werner, Miwarre and all people involved.
I put this feature request on fixed. Please test the feature and report any bug!
Yes, both seem fixed to me too!
M.
Adding a note to an existing chord doesn't work:
b DOWN g SHIFT-b (I get a new note here, thought this would build a chord...)
LEFT SHIFT-b
also adding a b to the g with the mouse gets an a sharp.
heuchi, what version are you using?
the latest nightly build: MuseScoreNightly-2012-08-08-024263f.7z
This is a known and unrelated issue. See #16954: shift-<note> does not add note to chord just entered
Yes, sorry I shouldn't bring up unrelated things...
however, the main problem still exists in the latest nightly :
enter the following: b DOWN g LEFT RIGHT SHIFT-b
this gets an a sharp instead of b flat.
(same when using the mouse)
Automatically closed -- issue fixed for 2 weeks with no activity.