MusicXML Importer Comprehensive Refactor and Added Handling for Various Tags

[Scowluga]

This PR refactors the entire importer as set up in the first PR. The diff is virtually meaningless due to so many refactors. But the majority of the code is new anyways. All changes are open to discussion and improvement. The number of line changes looks scary, but most of it is just exported MusicXML files from MuseScore for testing.

Overall Importer Changes

File Organization

• I decided to change the file organization to be more clear and organized.
• Now the MusicXML importer is located in client/interop/musicxml/importer which is logical.
• Within this folder, I have split up the importer into various files for better encapsulation.

Importer State

• The state of the importer has changed drastically.
• Previously, the handling of all tags returned a []model.ScoreUpdate.
• Unfortunately, to support chords and ties, we now need knowledge of previous parsed results.
• Now the importer stores a []model.ScoreUpdate for each voice. Each elementHandler modifies this as necessary.
• musicXMLImporter now also supports various helper methods.

Nested Index

• A []model.ScoreUpdate can contain model.Chord structs and potentially other structs with nested elements. Then I've created a nestedIndex class that can contain this information. I also added various helpers all in nested_index.go.
• To see use cases, go to noteHandler and you will see how I use these for dealing with chords & ties.

Post Processing

• Due to various reasons, the []model.ScoreUpdate returned by the importer is not ideal. There are various changes that can be made to generate more idiomatic Alda.
• This will be done in post_process.go. This work is quite straightforward and low priority, so will be completed after the important tags are handled.

New Handled Tags

Barlines

• This PR introduces barlines into the imported Alda representation.
• I insert these into the last note/rest/chord to simulate how Alda parses and stores barlines.

Chords

• This PR adds support for handling chords.
• We just search for the last chord/note. If it's a chord, we add the note to the chord. If it's a note, we remove it and create a chord with both notes.

Ties

• This PR adds support for handling ties. This was quite hard.
• MusicXML handles ties by just a tie start / stop. If a note is a tie stop, it is tied to the previous note with the same pitch.
• We find this note with the same pitch using findWithState .
  • Note that Alda notes do not maintain octave which is part of a note's pitch. I did a workaround for this by maintaining current octave while looping backwards (see getOctaveChange).
• Then we need to ensure that the tied notes are "adjacent". That is, they happen one-after-another.
  • If tied notes are not adjacent, we ignore them (doesn't really make sense).
  • If tied notes are adjacent, we add the duration to the previous note.
• Determining adjacency was non-trivial. I won't test this comprehensively either as I believe it should barely be a use case. But the code is there and works at least for the ties2 and ties3 tests which are non-trivial.

Voices

• This PR adds basic support for handling multiple voices. This is complicated.
• MusicXML handles multiple voices in very convoluted manner with the backup and forward tags. These tags move the current "time" counter of the score by an amount.
• I thought of two solutions. The first one solves the problem generally, but is a bit more complicated. The second one I believe will cover all cases we need, and is a little easier. I went with the second for now.
• Solution 1: To support generalized backup and forward, the importer would need to undergo a drastic restructuring.
  • Essentially, we would require accessing updates by "time". This means our data would need to be considered as an array instead of the current consideration as a linked list.
  • Then we would be able to insert and update elements by time. How many indices do you keep? Well that can be determined by divisions.
  • In theory this is possible, I don't see any blocking problems. It would be a little complicated to change divisions (change indices) and other things, but it's doable
  • That being said, I believe it is quite complicated. We could always backtrack and implement this (not too much work), but I believe I have a simpler solution which will work almost just as well.
• Solution 2: As an alternative solution I believe is easier:
  • We note the following key insight: there's never a need to backup to before an existing note in a voice. That is, for one voice, you'll never do some rests, then some notes, then backup and fill in those rests.
  • I have not proven this fact to be true, but I cannot think of any reasonable software developer who would write an exporter to do that. The software I use (MuseScore) also does not appear to.
  • In this case, we can continue to treat our updates as linked lists.
  • To do this, we maintain "beats" for our current part, but also individually for each voice.
    • As we update, we move forward the beats counter for the part, and the voice we are parsing to.
    • When we backup or forward, we simply move the part-level beats counter.
    • When we switch to a new voice, the part-level beats counter should always be >= the voice-level counter. Then we can just pad with rests as necessary, and continue importing.
  • This method has proven sufficient at least for MuseScore. For an example, see ties2.
  • I believe this method is easier, so we will implement it for now and see where it goes. We can switch to the array implementation if we find a need for it. I believe it is more complicated, but still doable.

Slurs

• This PR adds support for slurs.
• Slurs can be nested, so for each voice we store a "depth". Otherwise, this is quite simple.

Dotted notes

• This PR adds support for dotted notes.
• For dotted notes we need to do a bit of math to restore the "original" duration of a note before the dots are applied. This is because MusicXML gives the duration with the dots.
• Fortunately, this can be accomplished quite easily with knowledge of geometric series.

Parts

• This PR introduces basic support for scores with multiple parts.
• I use the midi-program attribute and get the MIDI instrument number then convert it to a name.
• Unfortunately this means all names are the "longer" MIDI instrument names. Maybe we can add code to get the "last alias" (more user friendly name) for each instrument, but that can be an optimization in the future.
• Dealing with parts also involves dealing with transposition. This was not hard.
• I haven't dealt with percussion yet, that can be lower priority.

[Scowluga]

Great. There's definitely a lot of rough edges. Edge cases, logging, testing. But I think with this PR most of the functionality itself will be "working". Then we can iron out details. One step at a time!

Will merge and aim to make future PRs smaller.