Inserted clefs wreaking havoc
I can't reproduce this in a simple empty project, but it happens all the time in my scores, happens in the latest version 3.6.2 and has happened ever since v2. When clef changes are placed within a measure in the piece, not a system clef change but an inserted clef:
- insert the clef, everything looks perfect.
- save the file and close it.
- open the file, to find all the inserted clefs are displayed as normal clefs (normal size, not smaller as they are supposed to be), and any inserted clef at the beginning of a system is now lost, instead being replaced by a change of clef on that system.
See attached images BEFORE (steps 1-2 above) and AFTER (step 3).
Once a score is finished and has been exported as .pdf, it's easy to forget about the problem, but any time I have to open a score having inserted clefs to fix something, I have to completely redo all the inserted clefs, which is very annoying, since removing a clef disrupts the layout and other positioning aspects get broken.
[ OS: macOS 10.15, Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548020600, revision: 3224f34 ]
| Attachment | Size |
|---|---|
| inserted_clefs-BEFORE.png | 61.88 KB |
| inserted_clefs-AFTER.png | 64.77 KB |
Comments
I think that MuseScore is reminding you that you are breaking the convention for clef changes.
Here is what Elaine Gould says in her notation manual "Behind Bars" on p.8:
"AT THE BEGINNING OF THE SYSTEM
Give warning of the clef change by placing the new clef at the end of the previous system before the barline.
AT THE BEGINNING OF A BAR
The clef always goes before the barline, whether or not rests precede the entry.
The only time that clefs appear directly after a barline are clefs for cues [...] and clef changes after repeat sections."
In MuseScore terms: if you want the clef change at the start of the bar (i.e. on the 1st beat), then you must select the entire bar before you insert the clef from the palette. And in that case, the clef change will correctly appear before the barline (and not after the barline as you are trying to place it).
I also checked that an inserted clef on the 2nd beat survives a save, close and re-open of the score. So it seems to me that this is not a bug in MuseScore: it's simply obeying standard notation rules.
In reply to I think that MuseScore is… by DanielR
You seem to have missed the point. These are definitely BUGS.
BUG #1: the inserted clefs are THE WRONG SIZE when the file is saved and re-opened.
BUG #2: the clef at the system start is no longer where I put it.
MS is not "correcting" my work. If I want to insert a new small clef at the start of a system, I can do that, regardless of what Elaine Gould says. MS allows me to insert a clef at the beginning of a system, and once I put it there, it should stay there. If MS were "correcting" my work (and it's obviously not), then it would do that "correction" immediately, not only after saving and reloading.
In reply to You seem to have missed the… by neo-barock
Sorry, regardless of what you think you can or can not do, your examples are incorrect. Just because MS doesn't correct you right away, doesn't mean you can do it to begin with. Clefs placed properly to begin with will stay.
As for the different size? When I placed a treble clef in the middle of a line, MS correctly put it in the preceding measure. It was a smaller size, and when I saved it and reopened it, the clef was the same small size.
In reply to Sorry, regardless of what… by bobjp
I already said I could not reproduce the problem in an empty project.
Opinions about whatever is "correct" are totally irrelevant here. if MS were going to "correct" what you are calling my wrongly placed clef, then it would do that "correctly", placing the clef at the end of the previous system, and it does not do that, so you think this is not a bug? Wrong. It's a bug.
I will be grateful for someone who writes code for the application to fix this. Thanks and have a nice weekend.
In reply to I already said I could not… by neo-barock
Impossible to fix as long as it isn't reproducible.
Actually I can reproduce, but only if assigning a clef to the first note of a measure (from small it turns to big, stays inside the measure), not if applying it to the measure itself (in that case it does stay small and before the measure) nor when appliiny it to any non-first note (stays small)
Might be covered by #46036: Clef on first note of system becomes header clef after save and reload
In reply to Impossible to fix as long as… by Jojo-Schmitz
Aha! You found it. Yes, this appears to be exactly that same issue. Im so glad there is a workaround: whenever I need the clef at the start of the bar I'll now assign to the measure instead of the note.
Thank you!
Depends on whether you apply that clef change to the measure or to the 1st note of that measure
In reply to Depends on whether you apply… by Jojo-Schmitz
Indeed. The problem happens if the clef is assigned to the first note in a measure. To avoid this problem, when inserting a clef at the beginning of a bar, never assign it to the first note, rather assign it to the measure. Then it works fine. Thank you for the help.
In reply to Depends on whether you apply… by Jojo-Schmitz
Final thought (feature request). I assume the measure reference can be got from the note reference once the user selects a note. If yes, then when a user assigns an inserted clef to a note, just check if that note is the first note in the bar, and if so, automatically assign the clef to the bar instead of the note. That would get rid of the problem and also avoid the incorrect placement of the clef.
In reply to Final thought (feature… by neo-barock
There may be reasons for wanting to apply a clef to a note vs. a measure. So both options exist and should continue to do so.
In reply to There may be reasons for… by Jojo-Schmitz
Well, sure. Where did I say get rid of the note option? The note assignment option is needed for notes in the middle of a bar. Of course, keep that.
When the note is the first one in the bar, it's always going to be wrong, and result in this bug. So I'm just saying, make MS correct it. Why not ?
The only reason not to do it would be if MS cannot get the measure reference from the selected note, or cannot check if the note is the first one in the bar. I assume it can do those things.
In reply to Well, sure. Where did I say… by neo-barock
No, it is not. There may be reasons why you want it attached to the first note and not to the measure. That is not a bug, the bug is that is turns big.
And sure, MuseScore could check whether it is the 1st note of a measure. Actually it even does, and that, being done wrongly, causes the bug at hand here
In reply to No, it is not. There may be… by Jojo-Schmitz
FWIW, I was trying to reproduce the "bug" without knowing the exact steps the OP was taking. He assumed everyone changed clefs the way he did. I wasn't sure what was going on, Hence the misunderstanding.
In reply to No, it is not. There may be… by Jojo-Schmitz
Sorry for resurrecting an old thread. I've been searching the forum using every way of wording this that I could think of, and I couldn't find this specific problem mentioned anywhere more recently than this.
For a cue that uses a different clef from the one the instrument on that staff is using, It is correct to show the normal clef at the start of the system, immediately followed by a cue-size clef change (Gould p. 573), so that's definitely a reason to add it to the first note and not the measure. But adding it to the first note in MU4 just adds the clef to the whole measure regardless, so it changes the clef at the start of the system, and also inserts a courtesy clef on the previous system, both of which shouldn't happen for a cue, if the the actual instrument isn't changing clef.
The version 3 handbook actually had instructions for how to get around this (https://musescore.org/en/handbook/3/clefs#mid-measure-clef), but in the version 4 handbook, those instructions are gone (https://musescore.org/en/handbook/4/clefs#add-change-mid-clef), and the method described in the MU3 handbook doesn't work in MU4.
Another method I tried:
1. Select the first note.
2. Press Ctrl+Shift+A to add an extra note to the start of the measure.
3. Add a clef to the second note (which should be the first note).
4. Select the note you added in step 2 and press Ctrl+Del to remove it.
The measure now looks exactly as it should, with a cue-size clef change immediately after the system clef, and the score will save without any error messages, but two things can go wrong:
* Corrupted score error message when reopening the score, because some of the other instruments still have the extra beat in that measure
* If the extra beat is removed from the other instruments, the cue-size clef now appears between the first two notes of the measure, but still affects the first note, even though it looks like it shouldn't. If the beat is removed from all instruments the first time around, it might just change the cue clef into a clef for the whole measure.
Any other ideas how to get around this? It might also be a regression, since it seems to have been working correctly in MU3, but it doesn't in MU4.