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.