[MusicXML Import] Final barlines no longer spanning staves on imported MusicXML files
Reported version
3.1
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
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
- Open this exported MusicXML file.
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 |
Fix version
4.0.0
Comments
Even worse, the type of the barline on the bottom staff is lost.
See also #290696: Barlines not spanning stave in added piano stave
relates to #270643: [EPIC] MusicXML import/export issues
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.
In reply to Definitely just a problem… by Dylan Nicholson1
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)
Staff vs Stave (in the UI) is a US vs UK thing and as such a matter of translations.
In reply to Staff vs Stave is a US vs UK… by Jojo-Schmitz
Hmm, interesting, I'm in Australia and while I do occasionally use "stave" I tend to stick to "staff" for the singular. But from a programming POV arguably "stave" is better because at least it has a regular plural!
In reply to Hmm, interesting, I'm in… by Dylan Nicholson1
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.
Seems this discussion about staff vs. stave is not topical in this issue and should, if at all, get continued in the translation forum, https://musescore.org/en/forum/9
In reply to Definitely just a problem… by Dylan Nicholson1
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?
See https://github.com/musescore/MuseScore/pull/8146
BTW: if you use <cpp>...</cpp> it'd format properly here
In reply to It seems there's a related… by Dylan Nicholson1
So I've got confirmation from the MusicXML team that having barline breaks between staves of a single part isn't supported as of MusicXML 4.0.
Meaning it's rather inadequate for something like http://www.petruccilibrary.us/files/imglnks/music_files/PMLUS00573-Pian… (see page 12 for a start, but lots of examples of barline breaks throughout).
See also https://github.com/musescore/MuseScore/pull/8175, which fixed this for the 3.6.2 backend (as used on musescore.com)
Fixed in branch master, commit c7d43026cb
[MU4] fix #290694 - ensure that final barline created automatically (e.g. during musicxml import) spans to next staff if on a multi-stave part
Automatically closed -- issue fixed for 2 weeks with no activity.
This issue should (IMHO) not have been set to closed, as the problem reported has been solved only partially (only for the final barline).
Propose not to re-open, updating the title to match the actual contents of the fix instead.
See already created #307042: Non-final barlines are not connected on MusicXML import for remaining work (still applicable to master as of yesterday, commit 68dd530).