We have addressed the following issues:<\/p>\n\n\n\n
smuflFont<\/code> from events, in line with the change made to remove smuflFont<\/code> from notes<\/li>\n\n\n\n- #438<\/a>: Adrian renamed the new
soundID<\/code> key name to simply sound<\/code>, for consistency with other similar places in the specification<\/li>\n\n\n\n- #441<\/a>: Adrian added some additional fields to
kitNote<\/code>: id<\/code>, class<\/code>, and perform<\/code>.<\/li>\n<\/ul>\n\n\n\nMyke fixed a problem in the doc generator that was resulting in Windows newline characters unexpectedly appearing in the HTML output.<\/p>\n\n\n\n
We discussed #436<\/a>, which raises the issue of how to represent more than two spellings for a note, given the and came to the consensus view that if you require more than two spellings for a note, for the time being, our recommendation will be to encode the whole part separately, and use layouts to exclude any alternative transpositions from the score and part instantiations as needed.<\/p>\n\n\n\nWe also discussed #432<\/a>, concerning the naming and use of the interval<\/code> object, and decided that we would change the names of both keys of the interval<\/code> object: instead of diatonic<\/code>, we propose staffDistance<\/code>, and instead of chromatic<\/code>, we propose halfSteps<\/code>. Using staffDistance<\/code> instead of diatonic<\/code> makes a value of zero clearer, i.e. it doesn’t move the note by any staff positions; and if we’re not going to use diatonic<\/code>, we should likewise not use chromatic<\/code>. <\/p>\n\n\n\nNext meeting<\/h2>\n\n\n\n
The next meeting is scheduled for Thursday 14 August 2025<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"MNX We have addressed the following issues: Myke fixed a problem in the doc generator that was resulting in Windows newline characters unexpectedly appearing in the HTML output. We discussed #436, which raises the issue of how to represent more … Continue reading