'Add Interval' doesn't respect accidentals

• Feb 28, 2010 - 10:41
Type
Functional
Severity
S4 - Minor
Status
by design
Project
MuseScore

If a note has an accidental, 'Add Interval' (Alt+N or Shift+N) adds an interval as if there were no accidental.

STR:
1. select a note with an accidental
2. press Shift+8 or Alt+8

Actual results: the added note is a perfect octave to the original note without accidental, but diminished or augmented octave to the original note with accidental.

Expected results: the added note is a perfect octave.

Other intervals behave the same, but the effect is especially clear when adding octaves. A minimal test score is attached.

Attachment Size
add_interval_with_accidentals.mscz 1.78 KB

Comments

• Mar 1, 2010 - 04:29
Status (old) by design ⇒ fixed

But maybe octaves should be a special case. I looks like it adds perfect octaves for accidental notes in r. 2803 nightly.

Reply

• Mar 1, 2010 - 09:39
Status (old) fixed ⇒ active

I disagree that the checkin for r2796 fixed this bug in full, because:

  1. the pitch of added octave is still wrong
  2. the userAccidental for the octave gets set despite the same note already present in the measure

The musical logic should be IMHO:

  1. get the pitch of the original note, add 12 (in case of Alt+8)
  2. add a note of the resulting pitch, which spells the same as the original
  3. check whether an accidental is required and add if necessary

STR:

  1. open the attached file "add_interval_with_accidentals_v2.mscz"
  2. select the last chord (G natural) in the 3rd measure of the left-hand staff
  3. press Alt+8 and Esc
  4. play the score

Actual results: the added G has superfluously a natural as accidental but is played as G flat.

Attachment Size
add_interval_with_accidentals_v2.mscz 1.81 KB

Reply

• Apr 2, 2010 - 09:02

we are back to the very broken behavior mentioned in STR in comment #4

I take this back, my apologies. While the testcase attached to the comment #4 shows this behavior, the same testcase, recreated from scratch with r2928 is not affected.

The other point remains valid.

Reply