Note value syntax allows for infinite number of dots

[mnquintana]

👋🏽 I ran into an interesting consequence of the Note Value Syntax spec as I was trying to implement it (nothing production-ready! I saw the warning 😅 ) and I'm not sure if it was intentional or not – it seems that, according to the note value parsing algorithm, any number of dots in a dotted note is legal:

9. If parsing a general note value, collect a sequence of characters that are U+0064 LOWERCASE D characters. Set number of dots to the length of this sequence.

This is the only part of the algorithm that sets / gets the number of dots before returning it at the end.

1. Should any number of dots be allowed? (I haven't seen more than a double-dotted note before, but this might just be my own lack of exposure 😅 )
2. If not, should the algorithm be updated to throw an error if more than ~2~ n dots are collected?

Thanks so much for taking a look at this! I'm very excited about the prospect of MNX.

[davemacdo]

Is there a benefit to limiting the number other than simplifying a setter/getter?

I can imagine a it being pretty rare to go beyond two dots in rep, and I can only think of one or two examples of triple-dotted notes (Chopin: G Major Prelude from Op. 28, excerpt below). However, I am uncomfortable setting an arbitrary limit without a clear gain. I would hope that MNX is capable of encoding music that is outside my own feeble imagination!

[adrianholovaty]

@mnquintana Nice catch! Thanks for bringing this up. :) Also thanks to @davemacdo for the repertoire example with three dots.

I'm of two minds on this. I agree with Dave that there doesn't appear to be a clear gain by having a limit. But at the same time, it feels kind of "dirty" to allow, say, one hundred dots.

MusicXML has no limit on the number of dots (see the DTD here). I wonder whether @mdgood has any insights on whether this was a good/bad/neutral approach historically.

Perhaps the most reasonable solution would be to allow any number of dots but add the following recommendations somewhere in the documentation:

• For producers, if you use more than one dot, it's not guaranteed that consumer applications will be able to correctly render/interpret the music.
• For consumers, if you encounter an MNX file with more dots than your engine supports, raise some sort of user-facing error.

[notator]

Yes, its a nice catch! :-) Four dots are not unknown. See http://homes.sice.indiana.edu/donbyrd/CMNExtremes.htm

MNX should, like MusicXML, have 14 note-value-types, ranging from maxima (=8 whole-notes) to 1024th note. So the maximum number of legal dots (on a maxima) is actually 13. The other note-value-types have smaller maximum numbers of dots. A 1024th note can't have any.

It would be fairly straightforward in MNX to limit the maximum number of dots for each note-value-type. Shall we do that? :-)

[mdgood]

Allowing an unlimited number of dots hasn't been a problem for MusicXML historically. I think most applications can handle dots down to whatever the lowest note value that they support.

The Verdi Requiem has quadruple dotted half notes in the Rex tremendae. (Yes, I'm that guy who shares this information about record-setting notation with other choristers.) According to @donbyrd's Extremes of Conventional Notation, quadruple-dotted half notes are also present in works by Liszt, Schumann, Franck, Hindemith, Bartók, and Rautavaara.

I am also not sure how much the spec should be mandating (or even recommending) particular error handling methods. If we do I suspect we may want to do it more generally, rather than on a case-by-case basis for specific issues.

@notator is correct about the maximum number of dots allowed per note type. So it could be a good idea to tighten this up accordingly. It's easier to specify that in modern schema technologies than it was in DTD days.

[evanlenz]

Coming out of lurk mode for a moment. I am sympathetic to Adrian’s idea of having compatibility caveats in lieu of actual limits. One use case for MNX that I am interested in is arbitrary musical transformations. This might include arbitrary scaling and stretching of rhythms, especially as waypoints on a processing path toward a usable, renderable result. It would be unfortunate if these limits meant I had to make special cases while processing just to work around them.

It might be that MNX wouldn’t be the native format for such waypoints anyway, so it might not make much of a difference to me in practice. However, I am someone (and there are other freaks out there like me) for whom XML at least is our native format (using XSLT for all processing, for example) as opposed to another programming language’s object model. Like I said, MNX might not be the ideal intermediate format for every kind of processing step, but it would be nice not to disqualify it from the get-go with inflexible limits that don’t in and of themselves add value.

On Thu, Feb 18, 2021 at 9:10 AM James Ingram notifications@github.com wrote:

Yes, its a nice catch! :-) Four dots are not unknown. See http://homes.sice.indiana.edu/donbyrd/CMNExtremes.htm

MNX should, like MusicXML https://usermanuals.musicxml.com/MusicXML/Content/ST-MusicXML-note-type-value.htm, have 14 note-value-types, ranging from maxima (=8 whole-notes) to 1024th note. So the maximum number of legal dots (on a maxima) is actually 13. The other note-value-types have smaller maximum numbers of dots. A 1024th note can't have any.

It would be fairly straightforward in MNX to limit the maximum number of dots for each note-value-type. Shall we do that? :-)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/mnx/issues/226#issuecomment-781496585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAETWLWN3L752TJ3EDWISS3S7VCW7ANCNFSM4X2PJB7A .

[notator]

Further thoughts: We are currently just talking about the common1900 version of MNX, so I'd be quite happy to limit the number of dots on any duration class (except the shortest four) to 4. The limit on the number of dots for the shortest four duration classes should be 3, 2, 1 and 0 respectively. Some composers in the 20th century may have tried using more than four dots, but such notations are actually illegible and should be classed as "experimental". Putting 7 or 8 dots on a quarter note seems to me to be "kind of dirty".

[adrianholovaty]

A while ago, we updated the spec for the "dots" object to say:

Though MNX has no limit on number of dots encoded, we advise software implementations not to worry about supporting more than 5.

That feels like a practical solution — document the practical constraint but don't enforce a limit technically. With that in mind, I'm marking this as closed.