DAISY Braille Music working group
Following our last meeting, Michael worked through the issues submitted by the DAISY Braille music working group and sent a detailed response to project coordinator Sarah Morley Wilkins, Matthias Leopold, and Haipeng Hu. We are now waiting on a formal response from the DAISY group.
Splitting MNX-Common and MNX-Generic specs
Adrian has created a new branch where the changes to split the MNX-Common and MNX-Generic specifications are now in progress. Michael and Daniel will review the newly-split specifications, and once the co-chairs agree Adrian will proceed with a pull request for community review.
MNX-Common by example
When Adrian was working on splitting the MNX-Common and MNX-Generic specs, he came to the realisation that no developer would really be able to plough through the spec and clearly understand the differences between the well-understood MusicXML format and the new MNX-Common, so he started working on a page that shows a number of examples encoded in both MusicXML and MNX-Common, to provide simple illustrations of the differences. This is at a very early stage, but Adrian wanted to seek consensus from Michael and Daniel about whether this is a good approach. Michael and Daniel agree enthusiastically that this is a very valuable approach.
Adrian wonders whether we could even use this approach as a means of coming up with concrete syntactic proposals to address issues, so that the process would be to produce a worked example before creating a pull request on the specification. The goal would be to encourage wider participation by lowering the barrier to entry for members of the community to be able to discuss concrete examples. Michael and Daniel agreed that this would be a great approach.
Adrian will look into integrating the examples into the main MNX repository and do some reorganisation of the code to allow easier expansion. Adrian will also add some further examples to the current page, starting with examples that encode the recent decisions on sounding versus written pitch. In order to do this, we’ll need to address issue #111 and specify the way transposition will be encoded. Michael proposes we should follow the pattern suggested by the MusicXML transpose element, but use more attributes rather than separate child elements. Adrian will put together an initial proposal of how this might look.
The next meeting is scheduled for Tuesday 18 June.