Fix key sig bug

[mike-spa]

Resolves: #15314

[sammik]

@mike-spa I dont know, why it was imortant, not to create C (empty) key signature, but I guess, there was some reason.
Are we sure, it is not relevant enymore?
If so, I saw many places in code, where similar code ("not create emptykey sig") is present. Isnt it related with this PR?

MuseScore/src/engraving/libmscore/measure.cpp

Lines 3868 to 3873 in 3f9b94d

	} else if (e && e->generated() && key == keyIdx.key() && keyIdx.key() == Key::C) {
	// If a key sig segment is disabled, it may be re-enabled if there is
	// a transposing instrument using a different key sig.
	// To prevent this from making the wrong key sig display, remove any key
	// sigs on staves where the key in this measure is C.
	kSegment->remove(e);

MuseScore/src/engraving/libmscore/edit.cpp

Lines 4652 to 4653 in 3f9b94d

	// do not create empty keysig unless custom or atonal
	if (tick.isNotZero() || nkey.key() != Key::C || nkey.custom() || nkey.isAtonal()) {

MuseScore/src/engraving/libmscore/transpose.cpp

Lines 620 to 630 in 3f9b94d

	// remove initial C major key signatures
	if (nKey == Key::C && s->tick().isZero() && !ks->isCustom()) {
	undo(new RemoveElement(ks));
	if (s->empty()) {
	undo(new RemoveElement(s));
	}
	} else {
	ke.setKey(nKey);
	undo(new ChangeKeySig(ks, ke, ks->showCourtesy()));
	}
	}

MuseScore/src/engraving/rw/measurerw.cpp

Lines 408 to 413 in 3f9b94d

	if (!ks->isCustom() && !ks->isAtonal() && ks->key() == Key::C && curTick.isZero()) {
	// ignore empty key signature
	LOGD("remove keysig c at tick 0");
	} else {
	// if key sig not at beginning of measure => courtesy key sig
	bool courtesySig = (curTick == measure->endTick());

And possibly many others.

[MarcSabatella]

I can provide a little historical background that might be relevant. There was a conscious design decision many years ago to represent C major by the absence of a key signature based on a general feeling that it was bad to have elements in the score that showed no visible trace of their existence. I personally never shared that feeling, but did what I could to make things work despite any number of complications that design caused. So some of those comments are likely mine, as is some of the code, but I'd be very happy to see it simplified.

There is nothing wrong in my book with C major being represented by an explicit element. I don't even think the code actively requires C major to be handle with no key signature, as there are still ways you can end up with a C major key signatures element in the score. But they do tend to get cleaned up on save/reload, so you'd want to make sure that isn't still happening.

[sammik]

Same fix is part of PR #12560 which fixes issue #12506

[mike-spa]

Thanks both for providing context! To me, eliminating the keySig event from a staff just because it isn't graphically shown is a profound mistake. The fact that the key isn't shown is purely incidental, and managing the showing/not showing just requires some very simple logic. Eliminating it altogether, on the contrary, effectively deletes a fundamental piece of information from our score representation that can't be reconstructed, and it keeps causing bugs and problems everywhere.
The clearest example is the problems I fixed in #14849. There is a fundamental difference between global key signatures (i.e. the ones that apply to all staves) and local key signatures (i.e. the ones that apply only to individual staves). The first need to be repeated in all extracted parts, regardless of transposition, the latter doesn't. Problem is: if your score has instruments with different transposition and some of them happen to be in C, you have staves with- and staves without key, and now you've lost the information to know whether the key was global or not, so you can't decide where to clone it or not in the parts.
So, in essence, I believe this "delete/do not create keySig if it is C" logic should be gradually phased out.