[MusicXML import] Floating-Point Alter tag interferes with import of accidental

• Apr 15, 2020 - 15:54
Reported version
3.4
Type
Functional
Frequency
Few
Severity
S4 - Minor
Reproducibility
Always
Status
GitHub issue
Regression
No
Workaround
No
Project

I am not sure if this is intended behavior. In issue #303918: Microtonal information in Alter MusicXML tag not preserved. I uploaded an example MusicXML file which included floating-point alter tags. I additionally encountered unexpected behavior in the import of the F# in the first measure. This note has tag (see source, XML tags do not seem to be friendly with Markdown)

<note>
    <chord />
    <pitch \>
      <step > F </step>
      <alter>1.05865 </alter>
      <octave> 4 </octave>
    </pitch>
    <duration> 20160 </duration>
    <type> half </type >
    <accidental> sharp </accidental>
  </note>


However it is imported as an F natural. The Accidental tag in this case was ignored.

Thank you for taking the time to review these issues! I thoroughly enjoy using Musescore and only recently started looking into microtones.

Attachment Size
comma_pump_min.xml 4.14 KB
Comma_pump.mscx 5.49 KB

Comments

<note>
  <chord/>
  <pitch>
    <step>F</step>
    <alter>1.05865</alter>
    <octave>4</octave>
  </pitch>
  <duration>20160</duration>
  <type>half</type>
  <accidental>sharp</accidental>
</note>

(use <xml>...</xml> to embed xml code)

Title Floating-Point Alter tag on musicxml interferes with import of accidental [MusicXML import] Floating-Point Alter tag interferes with import of accidental

The MusicXML importer expects alter to be an int. The float causes parsing to fail, which result in importing an F4 instead of an F#4. This is definitely a bug. Even when microtones are not supported, accidentals should be imported correctly.

I would like to work on this issue, to ensure that microtones are properly imported. But before I start to code, I'd like to run my suggested approach by all of you here:

  • Import the "alter" value as double, not as int, in mxmlNotePitch::pitch()
  • Modify microtonalGuess() to make range comparisons, not just comparisons around single values. This would allow assigning the same accidentals as today, but encompassing different tunings.
  • Ensure that the bug reported in this issue no longer shows.

If this makes sense, I'll go ahead. Thanks!

In reply to by infojunkie

Hi @infojunkie, help is always welcome.

I am in no way an expert on microtonal music notation, but this is my understanding:

You probably want to make sure:
- handling an integer alter value stays unchanged
- a float alter value affects the note's _tuning value
- an explicit microtonal accidental is imported as specified
- a missing microtonal accidental is guessed based on alter

Furthermore, it would be even nicer if these values export correctly (to MuseScore and MusicXML format) and if the import effect is identical (or similar enough) to what the existing microtonal plugins do.