[MusicXML Import] Barlines no longer spanning staves on imported MusicXML files

• Jun 12, 2019 - 22:07
Reported version
3.1
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

On importing an MusicXML file double, final, dotted and dashed barlines no longer span between staves.
To re-create
1. Export an MSCZ file with any barlines that span over more than one stave as MusicXML.
e.g. Barline_span_to_next_stave_on_MusicXML_import.mscz Screenshot_Barline_mscz_2019-06-12 21-37-22.png

  1. Open this exported MusicXML file.
    Screenshot_Barline_MusicXML_2019-06-12 21-36-26.png

Repeat barlines are not affected.

I first noticed this in various MusicXML files exported from Sibelius where all I noticed at first was the final bar not being joined in the piano scores I was dealing with. But as demonstrated above happens when MuseScore imports it's own exported MusicXML files.

Attachment Size
Barline_span_to_next_stave_on_MusicXML_import.musicxml 5.46 KB

Comments

• May 20, 2021 - 22:18

Definitely just a problem with import - the default behaviour for a barline that is on a multi-staff part is that it should span the staves (in fact I'm not quite sure how in MusicXML you'd specify otherwise).
Happy to offer to fix if I can figure out how to get MuseScore building.

Reply

• May 20, 2021 - 22:33

It seems there's a related problem with export - that when a barline on a multi-staff part doesn't have "span to next staff" checked, it exports just the same as when it does.
I've tried experimenting with modifying the musicxml file in text editor and importing in other tools to figure out what the correct output should be in the case the barline isn't intended to span but no luck so far (I thought you could just specify which staff number the barline applied to, but no go).

(BTW was it a conscious decision to use the word 'stave' everywhere in the MuseScore UI, despite it being called a "staff" programmatically? At least, mostly, it is referred to as "stave" a few places in the code too)

Reply

• May 21, 2021 - 13:08

Where does this idea of different US and British usages for staff/stave come from? I have just looked up four British references - Oxford Dictionary of Music. ABRSM "Rudiments and Theory of Music", Imogen Holst "An ABC of Music" and Otto Karoly, "Introducing Music". All of them at some point say "Staff or Stave" but make no reference to a difference in US and British usage. The last reference actually includes an appendix on "American Usage" which includes things like bar/neasure but does not mention "Staff" or "Stave". Imogen Holst writes about the history of notation and on the first mention of the term says "Staff or Stave" but then uses "Stave" throughout. I don't think I would have found it odd if she had chosen the other option.

Personally, I (a Brit) use both when talking about music but tend to use stave more frequently. Possibly I might use staff to refer to the 5 line thing as a whole (for example as in "The soloists part is shown in its own staff above the piano part.") but stave when I am using it in relation to something else ("I added a crescendo to to top stave".), but that may be just my idiosyncrasy. In non-musical usage a staff or stave generally refers to something made of wood but there is a subtle difference in usage; I think of a staff as something that I might carry (a walking stick or something to hit someone with) but a stave would be a long piece of wood that is part of larger construction, for example a barrel is made up of individual staves; a fence has upright staves attached to horizontal arris rails.

Reply

• May 23, 2021 - 02:21

FWIW, I'm pretty sure I've worked out how to fix the specific bug (basically, ensuring that the spanStaff property is true for barlines created for multi-staff parts - _pass1.getPart(partId)->nstaves() > 0 - when importing XML, the logic is pretty basic), but unfortunately I'm stuck trying to get the thing to compile.
BTW why does greater-than get converted to HTML entity encoding even when using ``` for literal/code segments?

Reply