Changing staff space causes numerous courtesy clefs to appear that I cannot get rid of (automatically)
If I go into Format -> Page Settings and change the Scaling -> staff space (to make the part fill an entire page so it looks nice), numerous "courtesy clefs" appear all over the place. I can hide them one by one but it's ridiculous that I would have to do this. I have tried unselecting "Show courtesy clefs" but that doesn't help. I'm at a loss to figure this out.
I've searched a bunch of similar reports but nothing that is exactly the same as these steps for reproducing the "bug".
I'm at the latest version 3.6.2.54...
| Attachment | Size |
|---|---|
| snippet 1.PNG | 28.29 KB |
Comments
Please share the score
In reply to Please share the score by Jojo-Schmitz
Attached. Yes, it's a single part for the score... I was digitizing a hand-written part.
In reply to Attached. Yes, it's a… by normmacneil
Score stems from a MusicXML import. Maybe we'd need to check that XML file
Just select those extra clefs and delete them (right-click one, select all similar, Del
In reply to Score stems from a MusicXML… by Jojo-Schmitz
Original XML is from Komp on iPad (see attached). A few clarifications:
a) right-click -> Hide courtesy doesn't do anything
b) these extra clefs only showed up when I resized the spacing
c) right-click -> select all similar highlights the clefs at the beginning of the staff as well (which I don't want to delete) but interestingly enough, when you hit Del, it only removes the courtesy ones (that's a weird situation).
So, your suggestion worked. Thanks very much. It would be interesting to figure out why it was occurring in the first place.
Cheers,
Norm.
In reply to Original XML is from Komp on… by normmacneil
Well, these just ain't courtesy clefs, that's why that setting dosn't have any effect on this score.
I don't know though why it is in there though, the xml has only one clef:
Maybe Leon Vinken knows?
In reply to Original XML is from Komp on… by normmacneil
It is not just the clef, but the key signature too. But then again that's in the xml only once:
In reply to Original XML is from Komp on… by normmacneil
Also all barlines are doubled!
In reply to Also all barlines are… by Jojo-Schmitz
Except at the places with that addition clef and key signature. The latter of which can't get (easily) deleted either.
Something very strange is going on with that MusicXML file
In reply to Except at the places with… by Jojo-Schmitz
I'm using a free iPad app "Komp"... perhaps that's the source of the issue. I guess you get what you pay for :-) Maybe I'll look at Symphony Pro or Notion. Thanks again for looking at this.
In reply to I'm using a free iPad app … by normmacneil
Still feel free to file this in the issue tracker as a Major MusicXML import issue
In reply to I'm using a free iPad app … by normmacneil
Thanks for #331336: Importing MusicXML causes numerous 'courtesy clefs', etc. for some reason
In reply to Original XML is from Komp on… by normmacneil
Isn't a Clarinet usually a Bb Clarinet and as such transposing a major second? Not in that XML
In reply to Isn't a Clarinet usually a… by Jojo-Schmitz
Since I was only writing the Clarinet part, I didn't bother writing it in concert key and then having the program transpose the part.
The MusicXML file indeed contains many superfluous regular barlines left and right. No superfluous clefs are present in the file, nor are they generated by the MusicMXL import. I do not know what causes the issue and it seems to depend on the exact staff space selected. The issue does not seem to reproduce when either the superfluous barlines are removed from the MusicXML file, or the importer is changed to prevent them from being added to the score.
It does seem adding superfluous regular barlines causes the layout engine to get confused about where the systems start, leading to extra clefs and key signatures being added.
In reply to The MusicXML file indeed… by Leon Vinken
That is my guess as well. MuseScore doesn't normally use left barlines for anything except the first measure of each system, and start repeats. I know there is code that is used to determine if a measure should contain a header or not, and managing that as the layout changes can be tricky. Also for things like, allowing you to set the properties of that system barline independently of the end barline of the previous measure, or properties on the generated clef - what should happen to those if the layout changes and the measure is no longer the first of a system? There have been plenty of bugs in the past having to do with management of all that, this seems like more or the same.
Probably this case is mostly fixable by simply ignoring the spurious barline tags on import. Problems would presumably remain when legitimate left barline tags are used, like to specify a double barline at the start of a system. I suspect the deeper fix has to do with setting the "generated" flag on the barline or something like that.
In reply to That is my guess as well. … by Marc Sabatella
Thanks. I've also responded in the bug tracker incident. It is likely that the original iPad app, "Komp", would be the culprit of creating the spurious XML tags. I'll forward the information to that development group. Thanks.