MusicXML: request for more optimal calculation of "divisions"

a) Does this issue concerns specifically Musescore export function. ?
No doubt that the routine/algorithm used for writing the content of the xml file is questionable .
But in fact , there is also a major non-conformity in the “play function “ of Musescore. The sounds (let say their duration) produced through the speakers are not compliant/conform with what the listener can read on its computer screen. In the HBD example, the error in duration for the 19/16 Tuplet’s 1st note and the following ones_ is about 1% , precisely 0,811103 milliseconds_ (see calculations in attachment) . For sure whoever is singing the HBD song cannot see ( or ear ? ) this issue, even he/she is not yet completely drunk…
Note : Musescore can read (very well) the HBD Musicxml File previously exported . Therefore , a general comment can be made: what’s the hell !. What is the $)!.”? name of the person who approved the idea for musescore to record a given score simultaneously under 2 different files (an*.mscx and a *.musicxml) which are both xml formatted but with different content …
One must admit that the mscx design seems better . Especially because the concept of tuplet node between “measure and ”note”is adequately managed in the xml tree hierarchy .

b)Does Musescore dynamically adapt its divisions. ?
No, neither dynamically neither in real time. Musicxml documentation explains :” Musical durations are commonly referred to as fractions: whole notes, half notes, quarter notes, and the like. While each musical note could have a fraction associated with it, MusicXML instead follows MIDI by specifying the number of divisions per quarter note at the start of a musical part, and then specifying note durations in terms of these divisions.
MusicXML allows divisions to change in the middle of a part, but most software will probably find it easiest to compute one divisions value per part and put that at the beginning of the first measure. The divisions value of 24 in this example allows for both triplet eighth notes (duration of 8) and regular sixteenth notes (duration of 6).
See : https://www.musicxml.com/tutorial/the-midi-compatible-part/attributes/
https://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-divisions…
Muse score is one of those software who puts the “divisions” value in the first “measure xml node”. It’s clear that the Musiscore engine reads/ analyses the whole score before writing the first line of the musicxml file. This reading allows to search and detect the note (or rest) having the shortest duration in the score.
Note: In my opinion, this way of recording this value in the first measure is obnoxious. If the “divisions” value is related to the whole score (or the part) it should be escalated higher, as an attribute of the “score-part” xml node . (as in the mscx.file)
Note : If we create a score with a bunch of 4/4 measures containing only a bunch of quarters , except for the ultimate note which is a 128th , then the first measure (in *.musicxml file) will contain a “divisions” value of 32 , which is correct (32 = 128/4)
Note: Musiscore calculations are correct in most cases including when measures contain some ordinary triplets. However when a measure contains 2 tuplets (a triplet and an exotic one), as shown in the HBD example, calculations are risky , to not say false.
Note: Only the first measure of the HBD song has been entered in Musescore.(see attachments). Thus , values in the xmlfile are only specific to that measure . The attached MusicXml file is not an extract of a bigger one.

Hi Marc,
Information about “divisions” element in musicxml can be found in :
https://www.musicxml.com/tutorial/the-midi-compatible-part/attributes/
https://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-divisions…

Musescore calculates the “divisions” value by searching the shortest note in the score. It writes this information in the first measure in the musicxml file.
This works well in most cases , including when there is ordinary tuplets. However as shown previously, in the HBD sample, the calculations are erroneous when a single measure contains two tuplets : a triplet and an exotic one.
This leads to a difference of about 1 millisecond (0,81111 ms ) in duration in the loudspeakers, for each note of the 19/16 tuplet.
See calculations about current vs expected values in the following attachment.
This is not a major issue but as demonstrated before for the HBD example a simple algorithm can produce an exact “divisions” value . Such a correct value would avoid the score reader to make micro-movements (backward and forward) along the track. Another advantage would be a musicxml file less verbose as the backward/forward nodes would be superfluous.

Hi Leon,

Please see in attachment the compressed musescorefile

Hi Leon
You said "MuseScore indeed dynamically adapt its "divisions".;.
IMHO the word "dynamically adapt " is open to misinterpretation .
I'm sure you know that Musescore DO NOT adapt, trough an "on going process" , the divisions value "within the stream" or "in real time".
As the "divisions" is calculated before writing the first line of the xml file. The export function reads the entire score in order to search and detect the shortest note (or rest) duration in the score. Then , the notes (& rests) durations are based on this Lowest Common Multiple.

This way of doing things is cool and should be kept.
Nevertheless , there is some side effects.
This "divisions" value is currently recorded in the first measure when it should be recorded at the score node level in the xml hierarchy.
When we create a score with 3 staffs (one for the voice and 2 for a piano) ,we see that the "process" examine the 3 staffs (for the shortest note) and records the SAME "divisions" value in the first measure of part 1 (the voice ) and in the first measure of part 2 (the piano) . It's why I would suggest to place this "division" value at a score level where it should be logically located . Knowing that the Musicxml schema has no provisions to do that !