What is exepcted behavior of saving a score without intitial clef, but with clef before first note

• Apr 11, 2016 - 19:50

If start with my first score:

then add bass clef before first rest:

then select initial treble clef:

then delete initial treble clef:

Then now I have a score without an initial treble clef, but with a clef before first rest. First question: Is this a valid score? Second question: Is this the exepcted behavior that should happen when try to delete that first initial clef?

Now the funny thing happens when I save this score: My_First_Score_no-initial-when-saved.mscz

Upon reopen, I see that bass clef migrate to become the initial clef:

Is that migration considered desired expected behavior. It seems the opening code is doing some fixes. Are those fixes deliberate and desired? I'm thinking that the score as saved should be the same that I open.

Comments

Recorder485

• Apr 11, 2016 - 23:50

As you know, I am not a code person, but I seem to remember Marc Sabatella mentioning something about there being no way to 'save' elements which are generated 'on the fly' by MuseScore in response to changes in layout as the score is worked on. For instance, single instances of those elements which appear at the beginning of each system, such as clefs, key sigs, and Instrument Names, can be made invisible individually, but that instruction isn't saved when the file is closed so they will reappear the next time it is opened.

Could that mechanism have something to do with this behaviour?

ericfontainejazz

• Apr 12, 2016 - 00:03

Well indeed that very first clef at beinging of My_First_Score.mscz is a "generated" treble clef. When I add that bass clef, that bass clef is a real clef (i.e. it is not a "generated" clef).

So it seems that musescore is not saving that initial generated clef. That is something I understand.

But it seems on file load, what is happening is that that real clef which was to the right of the time signature before saving then gets moved to before the time signature on load.

I believe what is going on in the load code is that it searches for a segment of type clef at tick 0. But it is not taking into account the ordering of the TimeSig and Clef segments. I'm thinking the save/load code should respect this ordering.

Not really a big deal...but any sorts of inconsistencies I like to know why they happen, and even better I'd like such inconsistencies to not happen.

Recorder485

• Apr 12, 2016 - 00:24

Yes, but I've got a feeling that that 'real' bass cleff you inserted can't be treated any other way than the 'real' treble clef placed at the very head of a staff, or the whole 'generate on the fly' thing won't work. In essence, any clef change one inserts in a piece tells the program that 'from this point forward, and until further notice, this staff shall be notated in X-clef', so that X-clef replaces the initial clef and is treated by the program in the same manner.

IOW, if you're writing a horn part in treble clef, and have, say, eight measures of low pedal tones to notate in bass cleff, you'd insert the bass cleff at the start of that section, and re-insert the treble when the tessitura rises back into G-clef range. But if that section spans more than one system (likely, for eight measures), the program will generate a full-sized bass clef at the start of the next full system after the change, and then after you go back to treble it will do the same thing at the start of the next system after that change.

I don't see any other way this could work, unless MuseScore had a user-control to "Hide Clefs at Beginnings of Systems", which would be completely contrary to modern practise (but useful for people attempting to reproduce historic MSS or first editions wherein clef-less system/stave starts was the norm).

For now, if you really want to start a staff with no clef, I think you're going to have to make the individual clefs invisible manually, and export to PDF to 'lock' the image before saving the mscz and re-opening it. That's what I have to do with editions which require an incipit showing the historic clefs before the modern clefs, because I can't 'lose' the long-instrument name permanently, nor the 'dummy' notes and lyrics required to make the spacing work out properly.

ericfontainejazz

• Apr 12, 2016 - 00:31

The real reason I'm investigating this is because I was debugging someone else's album join, which had one score which looked like:
https://musescore.org/en/node/105616#comment-475641
and that caused a crash because the firsts clef segment didn't have a clef on that second staff.

So not so much that I personally want to make a score that looks like that. But rather I just want consistent and stable behavior when loading scores. I still can't quite figure out how that person got the score with those clefs in that position, because whenever I try to save and reload, the clef before the first rest seems to migrate and be promoted to initial clef.

Isaac Weiss

• Apr 12, 2016 - 00:44

Just noting that MuseScore does have an option to hide clefs at the beginnings of systems—or rather, it has an option to show clefs, turned on by default. It's in Staff Properties.

ericfontainejazz

• Apr 12, 2016 - 00:59

right. But that option simply hides the initial clef.

Anyway, I've finally figured out the steps I needed to perform to reproduce the odd state I experienced in the other thread such that the clef remains not at initial position on reload.

1. Start with 1treble staff & one grand staff:

2. Add bass clef before first rest of staff 2:

3. Add inital alto clef to staff 1, which will replace the generated treble clef with a real alto clef:

4. Remove the generated treble clef at start of staff 2:

Now save the score. When reopen, will remain in same state:
step4.mscz

So I'm thinking that since it is possible to produce this sort of behavior here which is consistent on save and reload, that I think musescore should always respect the ordering of these clef segments on save & reload.

ericfontainejazz

• Apr 12, 2016 - 01:56

well in my case with out intial clef: this is the ordering in the .mscx (and similarly in the MusicXML):
{syntaxhighlighter SPEC}

4
4
1

F
F

{/syntaxhighlighter}

So the Clef occurs after the time signature in the save file. So I believe the inconsistency is in the loading code...

ericfontainejazz

• Apr 12, 2016 - 02:20

Well I believe this code is responsible for migrating that clef to the left and promoting it into being an initial clef:

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

Now if I comment out that line then I get an assert failure somewhere else...so I'm guessing there is a deliberate reason for that. So I'm reluctant to do anything now and just tolerate this promotion on read, unless someone who know this code better has a suggestion.