[trunk] Issue w/ naturals in key sig. changes (regression)
Setup: Rev. 3536 under Windows XP w/ SP3, Qt SDK 2010.04 (Qt Creator 2.0.0, Qt lib 4.7.0)
Three different issues are listed here; I collected them together as they refer to the same entity and are probably related code-wise.
The example supplied may look rather contrived, but summarizes a scenario I am actually dealing with in a score I am working on.
Steps:
1) Load the first score attached.
2) At the beginning of the second line, set a change to no-accidental key (Cmaj/Amin).
3) Save under a new name, close and re-load. The second attached score shows the final result.
Results:
A) The key set in step 2) is gone
B) The end bar line at the end of the first staff is also gone
C) After step 2), a courtesy key change is (correctly) added at the end of the first line, but no key change is added at the beginning of the second line. Among other things, this leaves nothing to click on to set key properties (for instance to turn off the courtesy key).
Expected results:
A) The key set in step 2) is kept
B) The end bar line is kept
C) After step 2), a single-natural key change is shown at the beginning of the second line.
Note that the first change from FMaj to Cmaj in the first line has no problems. So, the break at the end of the first line is probably involved in these issues.
Thanks,
M.
Attachment | Size |
---|---|
TestKeys_trunk3536.mscx | 12.18 KB |
TestKeys_trunk3536_2.mscx | 12.11 KB |
Comments
In current trunk revision (3646), most of the issues described above are fixed. Great!
However, a new point popped up!
Steps: Load the attached sample score: it contains a change from a key sig. with accidentals (1 flat) to a no-accident key signature.
Result: a key sig. made of a single natural is carried on for all the rest of the score. This is no longer dependent on intervening frames (as the above issues were) and it shows up before and after a frame break.
Expected result: the 1-natural key change is shown only on the first system and disappears on following systems.
However, I am very happy, as this point is very near to be solved!
Thanks,
M.
The issue is more general than I initially noticed.
Steps: Load the attached sample score. It contains some key sig. changes, each involving some naturals to cancel the previous signature.
Result: Naturals are drawn in ALL the systems following the key change.
Expected result: Naturals are drawn only when the key actually changes and dropped after that.
I have also attached a screen shot showing the issue.
Incidentally, the courtesy change key sig.s stick out from the staff, if made by more than two symbols
Priority raised, as this issue breaks a basic notation convention.
M.
Applied fix from Miwarre in r3704.
Automatically closed -- issue fixed for 2 weeks with no activity.