Closed WolfgangDrescher closed 4 months ago
Thanks for the report! I'll take a look at this today to see what the issue might be. (Unrelatedly, there is no such option at the moment, although there is an option mechanism that could be extended in future to include such things: for example, converter21's MEI exporter has an option to request an MEI v4 file instead of the usual MEI v5 file.)
It looks like m21Stream.recurse().getElementsNotOfClass(m21.stream.Stream)
will not return any music21.bar.Barline
elements other than the last bar line.
I took a look at the barline issue. When music21's MusicXML parser (music21/musicxml/xmlToM21.py) imports this file, it produces almost no barlines in the music21 score (measure.rightBarline is None and measure.leftBarline is None). So converter21's Humdrum exporter doesn't produce any. This is weird: I need to think more about what this actually means. The MusicXML file doesn't actually mention any barlines beyond the very last "light-heavy" one. But should that be interpreted as "normal default barlines should be assumed"? And if so, is it music21's bug for not doing that? Or does music21 also require that interpretation, and it is converter21's bug for not assuming default barlines? And then there's the big "did Dorico produce incorrect MusicXML" possibility, in which the MusicXML should have explicit normal barlines? (This seems unlikely, since Musescore displays this MusicXML file with barlines, but I'll check.) I'm off to read some MusicXML/music21 documentation.
One very quick answer from the MusicXML docs: "If a barline is other than a normal single barline, it should be represented by a
Unrelatedly, there is no such option at the moment, although there is an option mechanism that could be extended in future to include such things: for example, converter21's MEI exporter has an option to request an MEI v4 file instead of the usual MEI v5 file.
This is probably not really important since for this specific option with stem directions it's quite easy to use the humdrum tool shed
and parse it after the conversion.
But should that be interpreted as "normal default barlines should be assumed"? And if so, is it music21's bug for not doing that? Or does music21 also require that interpretation, and it is converter21's bug for not assuming default barlines?
It is difficult for me to help with these questions as I have not dealt with music21 before.
One very quick answer from the MusicXML docs: "If a barline is other than a normal single barline, it should be represented by a element that describes it." So the MusicXML is doing the right thing, and normal barlines should be assumed.
Okay still the question remains whether this element is missing in music21 (which I can hardly imagine, as such behavior would certainly have been noticed beforehand) or if we need to implement it into converter21 because Kern syntax explicitly needs them.
I don't see anything conclusive in the music21 docs about what a missing barline means. I am leaning towards interpreting a missing barline in music21 the same way it should be interpreted in MusicXML, since music21 is pretty MusicXML-centric. I did try exporting to MusicXML from this music21 score, and it came out the way it went in, with all those barlines still missing, rather than present, with bar-style=none.
If I'm right, then converter21 has some work needed (in the Humdrum exporter, and maybe also in the MEI exporter), to interpret missing barlines as "normal" instead of as "not present".
I will try to get a conclusive answer from Michael or Jacob (the two main developers of music21). More likely Jacob, since Michael is on sabbatical.
Thank you very much for your efforts. This feature would be a great help for a project of a student of mine, as he feels more comfortable writing the scores in Dorico and then converting them to Humdrum.
No worries! I filed an issue in music21 #1669 (and sent a private email to @jacobtylerwalls as well).
Is the goal is to have it import/export correctly into/from music21, or to convert to Humdrum? The latter can be done in VHV:
I am seeing barlines, which do not seem to have any strange format in the MusicXML data (Dorico does some weird things as I remember that I needed to compensate for in the MusicXML-to-Humdrum converter).
To use the same convert on the command-line, it is called musicxml2hum
from humlib. (xml2hum
is the prior version of the converter in Humdrum Extras which I keep for reference).
Here is the score imported and exported to/from Musescore, which is useful for testing:
I agree with @craigsapp (and was about to mention this tool, although I probably would have confused xml2hum and musicxml2hum). The humdrum parsing/writing code in converter21 is generally translated from (a large subset of) Craig's humdrum code, so Craig's code supports more music notation features, and is definitely always faster, since it is in C++ rather than Python. The only thing I don't know is how musicxml2hum's MusicXML parser compares with music21's. I suspect they are similar.
I probably would have confused xml2hum and musicxml2hum
I should probably rename xml2hum
to xml2hum-old
:-)
I still use xml2hum
to compare outputs from musicxml2hum
and xml2hum
when there are problems in musicxml2hum
, but musicxml2hum
handles more complex cases in general (such as grand-staff parts for piano music).
Thank you @craigsapp! I don't know how I missed that there is a humlib
tool for this. I only found hum2xml
, but probably I was in the wrong directory (humextra) or something. I will try it out!
You can also use musicxml2hum
via verovio (since humlib is embedded in verovio):
verovio -f musicxml-hum -t humdrum file.musicxml
this will create file.krn which is a conversion of file.musicxml using musicxml2hum.
-f musicxml-hum
means load from MusicXML via the musicxml2hum
converter (rather than the musicxml-to-mei converter).
-t humdrum
means output data to Humdrum.
Note that musicxml2hum
has two options:
option | meaning |
---|---|
-s |
Preserve stem directions (by default they are omitted). |
-r |
Include a **recip spine for the composite rhythm of the score (useful for avoiding having to calculate this information from the plain Humdrum score). |
Works perfectly, thank you! Even figured bass numbers are imported!
Most excellent!
BTW, I have heard from Jacob, and he confirms that no barline in music21 means the same thing as no <barline>
in MusicXML. So I will be fixing that in the Humdrum (and maybe MEI) exporters in converter21 soon. Thanks for the report!
On the webpage https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/barline:
If a barline is other than a normal single barline, it should be represented by a
element that describes it.
So if there is no <barline>
for the end of the measure, it should be assumed to be an implicit regular
barline:
<barline location="right">
<bar-style>regular</bar-style>
</barline>
An invisible barline should be encoded explicitly:
<barline location="right">
<bar-style>none</bar-style>
</barline>
Fixed on develop branch (a pretty stable branch that previews stuff that's ready for the next release).
I have this MusicXML file: 1-Beatus-vir.xml.zip
When I try to convert this file from MusicXML to Humdrum (Kern), measure numbers and measure data lines are missing from the output.
I'd be happy to contribute with a PR if I get a little guidance where to start for this issue.
Unrelated, but is it possible to pass options to the converter, e.g. to ignore stem direction signifiers (
/
and\
) during conversion.