Custom key signatures do not show

• Aug 18, 2014 - 11:08
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Steps:
1- Create a new score;
2- Open Master Palette;
3- Create a custom key signature and add it to the palette;
4- Drag-and-drop the cusotm key signature on the score, e.g. to the first measure.

Expected result:
The custom key signature is added to the score and is shown.

Actual result:
The custom key sigmature does not appear.
However, it is present in the score: if you save the file you can see that the custom key signature information is saved in the file.

Windows 8.1, commit c42a12d

Probably related:
http://musescore.org/en/node/29066#comment-117661


Comments

I was looking at this last night, and it seemed it is not a case of the layout failing - the drop itself is not dropping correctly. It looks like things are going to be fine here:

https://github.com/musescore/MuseScore/blob/de6aaa2d421410ccc24bc9bf71f…

and this much seems to work to look up the custom key signature in the table of existing custom signatures. However, when you go to actually make the change, that happens here:

https://github.com/musescore/MuseScore/blob/de6aaa2d421410ccc24bc9bf71f…

and we use only the "key" portion of the structure - the part that says "key of C". So that's all that ever happens.

I guess we would either change undoAddElement to accept the full structure and deal with it accordingly, or else have code here in measure.cpp after the call to undoAddElement to find the new segment & key signature within it and copy the custom info. The former makes more sense to me since there could potentially be other ways of adding key signatures besides drag and drop.

Status (old) fixed active

Well, actually I still see the old behavior, i.e. the custom key signature is shown as a C major key.
Windows 8.1, commit fc3ea8e

Same here. I created a custom key sig in the master palette and dragged it to the score, but it got added as C major. Shows in "Object Debugger" that way too. It appears the fix made here might work for custom key signatures that were already successfully created (imported from a 1.3 score perhaps), but I think the Measure::drop() event still needs to be processed differently or it won't be possible to add a new custom key signature to your score.

It seems there is a LOT to change to make custom key signatures work, even after Werner's great work.
I started working on it, but got stuck. I managed to amend the insertion of custom keysig and the import from 1.3 files, see branch:
https://github.com/AntonioBL/MuseScore/commit/0ad5e31a6
and (for backward compatibility)
https://github.com/AntonioBL/MuseScore/commit/f53867f055
but then in order to have the custom key signature displayed on the following staves a deeper change should take place inside libmscore\layout.cpp. I think that the staff shold keep a list of keySigEvents instead of a simple list of Keys (keyList) so that the property of custom keySig can be accessed during layout. But this change would touch areas of code I am definitely not familiar with. that's why I stopped. If someone is eager to continue the work I have started in the above two commits (or thinks of a better way to do it) I gladly pass the baton to her/him.

Actually, a proper implementation of microtonal accidentals as actual accidentals (with pitch transposing information) and custom key signatures as actual keys with transposition information would be the best solution, but it would be a too-big-change which would further delay the release of MuseScore 2.0. So at the moment I think it would be better to have a "patch" solution which at least works for people who want those advanced feature, and think of a better implementation for the next release :-)

Thanks for the work thus far! I wonder if the failure of custom key sigs to show on subsequent systems could be related to the fact that for C major, there generally are not explicity keysig elements? Except when there are; it's pretty inconsistent right now (see PR #1261 ). I've forgotten most of what I had learned when investigating both of these issues a few months ago.

Status (old) fixed active

I can get the custom key signature to show now - thanks for that. But they only show right where they are added - not on subsequent systems (same result as ABL's code, I guess). Is that intended?

Also, if use these in conjunction with transposing instruments, they are destroyed when you hit the Concert Pitch button - I guess treated as if they were ordinary C major signatures. So if you add one to a Bb instrument while with concert pitch turned off, then turn concert pitch on, it displays as Bb. And then when you turn concert pitch back on, it displays as C again, not your custom key signature.

Transposition is potentially to be a sticky issue for custom key signatures - ideally, one should probably be able to define a custom transpositions for them. For that matter, one might also want to be able to define alternate appearances for different clefs, etc. Not sure how people who actually use custom key signature will expect things to work.

I would like to put in a plug for my own use case though: I want to be able to define a key signature that looks ike C major but doesn't transpose. This is essential for atonal music. I was hoping the custom key signature mechanism would work for this. But I realzie that's not necessarily the expected use case.

1756549dd8

  1. My first score
  2. Replace C major key sig by G major. The key signature is displayed at the beginning of each system
  3. Go to master palette, create a custom key signature, drop it to first measure
  4. The key signature is displayed in the first measure but not at the beginning of other systems.

Confirmed, initial tests show things working as expected.

Debating whether this facility should be considered relibale enough to consider adding a new "atonal key signature" icon to the key signatures palette - a predefined custom signnature with no content (which we could hack to appear special in the palette somehow so people don't confuse it with ordinary C major). The custom key signature *does* seem to work exactly as would be required for atonal music, as per #9351: non-transposing key signatures. The question is, would using a "custom" key signature be the best solution for this long term, or would we better off eventually adding some more direct support for this? I could see it being implemented as a staff property (force no key signature, which is different from simply not displaying them) or a score style, or as a simple flag on a regular signature that says "do not transpose". I don't think any of these are *better* than using the now-working custom facility, but I'm just looking for feedback.