Voice standardization

[lucvdv-git]

Hello,

I'm looking at musicxml as a vendor-independent description of piano sheet music.
I use it to digitalize my sheet music by running an OMR program that generates a musicxml file and using it in Musescore to visualize the content.

Voices are used to describe notes that start at the same moment but have different durations, or more generaly: notes that overlap.
Now the 3 programs I use have all a different interpretation of how voices should be assigned to notes.

I have been looking at the definitions on the W3C website, but I can't find any information about this matter.

It would be nice that there is a concensus about how to use voices in the next release of musicxml.

Is there a site where the content of a new release is discussed?

Thanks,
Luc.

[mscuthbert]

Hi Luc: can you give a concrete example of something where different interpretations do not make perfect sense?

MusicXML was created at a time when multiple possible encodings was considered more of a feature than a problem. (A sister format MEI takes this idea further). Today the pendulum has swung more in the direction of "one musical score=one correct encoding" because of the various machine learning and other advantages this entails. I want to gently nudge MusicXML in that direction and best practices in docs are a good way to do that. So any proposed language would help there.

[samuelbradshaw]

The difference between <part>, <voice>, and <instrument> and when you would use each is also confusing / could be documented better. Related (instrument): #277

[lucvdv-git]

Hi Michael,

can you give a concrete example of something where different interpretations do not make perfect sense?

I don't know if I can answer your question. If the description of a score leaves room for interpretation, then there is something wrong with the description.

I can explain why I started this discussion.
I'm used to use playscore as OMR program and Musescore as editing program.
Musescore maps the voices attached to notes in the musicxml file to its own voices and assigns the voice to the staff having the most occurrences of that voice in the complete score.

Now I have some scores that Playscore can't handle and I looked at Newzik. that gave a better result but in Musescore I got a lot of cross-staffed notes and it's not easy to assign them to the right staff.
I looked a bit closer to the musicxml files, and noticed that Newzik looks at the voices one measure at a time. That results in assigning voice numbers that make Musescore generating the cross-staff notes.
I wondered what the definition of voice and cross-staff notes was in musicxml, but couldn't find a description.
So I thought asking here.

I saw in Musescore that you can export a file into MEI format, but didn't know what that was until now. I took a quick look at it.
MEI has the notion of layers which fit better the structure of piano scores.
Each layer starts at the beginning of the measure which makes it easier to read than the backup/forward directives in musicxml.

In the meanwhile, I checked how Finale imports the newzik musicxml file, and there I get the result I expected.
Finale is also using layers.

Best Regards,
Luc.

[mdgood]

The basic issue is that an exchange format like MusicXML has a way of representing voices that is not identical to the way that software applications represent voices. Each application has to map between MusicXML's concept and its implementation. Apps that use layers usually have a pretty straightforward mapping, but things can get more complicated depending on how cross-staff notes are implemented. There's only so much an exchange format like MusicXML can do.

If Finale is importing the Newzik file correctly and MuseScore isn't, I'd file a bug report with MuseScore.

[Jojo-Schmitz]

(S)He did bring it up in the musescore forum: https://musescore.org/en/node/366874, where it was claimed to be one of the MusicXML gray areas by our resident MusicXML guru (@lvinken) ;-)

[dougheyer]

Interesting conversation. Perhaps the voice attribute "Number" should be changed to "ID". Some thoughts about this:

A voice can represent a particular timbre (violin, flute, soprano, alto) or a single timbre which breaks into one or more subvoices (piano, classical guitar). In the case of subvoices it might be useful to think of specifying a subvoice ID. Assigning a unique ID to a voice helps determine stem directions when multiple voices or subvoices share a staff. The voice ID also helps determine stem ownership as well as stem direction and length when notes in the same chord appear in adjacent staffs.

Controlling voices can be like controlling cats. Because they can wander across staffs, appear above and below other voices with no respect for heirarchy, it seems futile to think of voices as having a numerical sequence (as is the case with Lyrics). Although there could sometimes be a case for subvoices to have sequential numbers within a voice ID--if you can keep them on a leash. The voice problem also shows why notes and rests should always have reliable voice ID (and Staff ID) attributes.

[dougheyer]

Sorry to inject opinions without introducing myself, I'm not sure what the protocol is for making comments here. My name is Doug Heyer. I had a career in music and computing, and spent several years working on the Personal Composer program while it was still alive. I am now retired and have lots of time to reflect on that effort. This is a fascinating subject.