Co-chair Meeting Minutes: April 16, 2019

MNX-Common

• Discussion of #4. Adrian will post a comment saying that we are going to encode written pitch. He’ll follow it up with a pull request to change the spec to fill that part in. Initial pull request will clarify that we will encode written pitch rather than sounding pitch. We will also add definitions for written pitch and sounding pitch to the specification.
• Some discussion about whether “written pitch” includes octave transposition (e.g. from octave lines or clefs with octaves indicated). Michael proposed that we should use the same approach as MusicXML, i.e. to include the totality of octave transpositions. Daniel and Adrian were unsure about this, since on its face it goes against the views expressed in the meeting by developers that they want the pitch encoded to match the displayed page, but Michael thinks we should do what MusicXML does and see whether there are objections.
• Michael to see whether there is a good definition of written vs. sounding pitch in the MusicXML schemas or tutorial.
• Discussion of #138. Adrian will post the same comment as in issue #4. We propose to then close this issue after bringing the relevant parts of Joe’s original proposal for realisations and layouts to the other issues, e.g. #34 for differences between full scores and parts, and issue #57 for system/page flow.
• Following on from the pull request, Adrian will review Christina Noel’s proposal for how pitch might be encoded and consider whether or not this could be the basis of the approach.

MusicXML 3.2

• We discussed how we should handle additional issues for MusicXML 3.2, including Cyril’s proposal for handling swing, and whether Michael should bring those issues into scope for the next release. We agreed that if Michael is happy to handle the specification duties, he can add them to the milestone without heavyweight co-chair review.
• Adrian expressed concern that the approach suggested in #283 is possibly not the most semantic approach, and could break display and playback into separate elements. Michael believes these can indeed be combined in one element and address Adrian’s concern.
• We discussed what to do with issues in the MusicXML repository that we have agreed to handle in MNX-Common. Michael will link them to an existing or new issue in the MNX repository and then close the issues in the MusicXML repository.
• In the next week or so, Michael plans to put together the first pull requests for MusicXML 3.2, e.g. upping the version number and switching back to the Contributors License Agreement (CLA) for the development period, etc.

The next co-chair meeting will be on 30 April 2019.