An incorrect readNext() caused the MusicXML parser to get out of sync
if no white space is present between the end elements of fingering
and technical. This is legal but seems to occur only in files produced
by ScanScore. It results in incomplete import.
When reading a score with parts, we currently set the defaults
for all styles in the score to those of the score itself.
This was done to make sure the "keep old style" option worked
for both score and for parts.
But this is not the right answer: scores can and do
often have different style settings from the parts.
Most critically, the score might be concert pitch
while the parts are transposed.
The result right now is that the parts are now somehwat "corrupt":
they claim to be in concert pitch mode and the pitches display that way,
but the key signatures are transposed.
That's the most critical effect of this,
but in general, there are many other situations where the score
can have different style settings from the parts,
and right now this difference is getting lost on save/reload.
Because the default for style in part is set from the score,
this means that if the score has any non-default settings,
these get propagate to the part on read even though the part
was using the actual program default settings.
Fix is to set the default style for the part on read
not to the *current* style of the score,
but to its own *default*.
This uses the same code as when reading the score,
checking the default style version,
and resolving the style defaults accordingly.
Thus, the default values for style settings not overriden in the part
come not from the current score settings,
but from the *defaaults* for the score.
This is consistent with how it worked before 3.6,
when there was just one set of defaults applied always (baseStyle).
3187570...
by
Matt McClinch <email address hidden>
Tempo in mscx/mscz files was previously stored with up to 6 significant
decimal digits (the default precision for number formatting). Since the
unit for tempo is 'beats per second', this caused rounding issues with
common tempo values. For example, the default palette presets for Andate
(92 BPM) and Alegretto (116 BPM) would actually be saved as 91.9998 BPM
and 115.9998 BPM respectively. This affected playback tempo as well as
exporting to audio and MusicXML.
Now tempo is stored with up to 17 significant digits (the maximum number
of digits needed to uniquely represent any `double`) to eliminate the
rounding error.
