New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MusicXML voice numbers should be unique within a multi-staff part (reuse of voice numbers confuses Dorico) #1335
Comments
I don't blame Dorico, they're trying to pay correct attention to which notes go in which voice, and I'm happy about that. |
I would be happy to work on this, once I get an opinion about whether this is a fix you would want. My proposal would be to do something simple in the MusicXML writer, like pre-allocate 4 voice numbers to each staff (start staff 2 with voice 5), and let the chips fall where they may. |
Looks like the voice numbering happens in moveMeasureContents (in partStaffExporter.py). It looks suspiciously like it's trying to make voice numbers unique, but perhaps it doesn't know enough, and I can plumb more info down to it (and update it's uniqueness algorithm a bit)? Definitely looking for advice. |
Ah. Looks like the following code is the culprit:
|
Simple (well, sort of) test that I have added to partStaffExporter.py, which fails without my fix, and succeeds with my fix:
|
… unique within the StaffGroup.
Fixed in PR #1336 |
music21 version
7.3
Problem summary
Dorico believes the notes are in the same voice, so they end up rendered as a cross-staff two-note chord. Musescore doesn't mind.
Here's an example MusicXML file (produced by music21) that re-uses voice numbers within a multi-staff part.
And here's the Dorico rendering of that file:
I'm working on a simple test case that can trigger generation of that MusicXML (the test case I have involves my Humdrum parser).
The text was updated successfully, but these errors were encountered: