Re: Co-chair meeting minutes: May 23, 2025 [via Music Notation Community Group]

Hi Andrew,

Unless otherwise stated, all the co-chairs (Adrian, Myke, and me) are always in attendance at the co-chair meetings. We very rarely have guests, but if we do happen to have guests, we will be sure to mention it.

What I wrote in the minutes perhaps didn’t capture the full context of our discussion. Obviously we were not proposing that, for example, plainchant neumes should not be included in SMuFL (indeed, they already are) because they don’t meet the criteria Myke proposed. Our discussion was centred around novel notations, e.g. the accidentals used by Easley Blackwell Jr that don’t seem to have been adopted by other composers since, or other similar proposals stemming from individual composers or academics.

I think it’s a reasonable goal for SMuFL that the symbols added to the standard should have at least some general applicability or interest. SMuFL aims to capture notations that are already in use more than it does to propose new notations that might find use in the future. Even if somebody is willing to do a good deal of work to bring something into SMuFL, if what they propose finds no use outside their own work or is a completely novel thing of their own invention, I’m not sure it fits.

I’m not opposed to having clearer guidelines for how things should make their way into SMuFL, of course. In general, I don’t think that we have had too many controversial cases along the way, so at the same time, I wouldn’t be in favour of adding a more heavyweight process if we don’t actually need it.

Daniel

From: Andrew Hankinson <andrew.hankinson@gmail.com>
Date: Friday, 23 May 2025 at 22:55
To: team-community-process@w3.org <team-community-process@w3.org>
Cc: public-music-notation@w3.org <public-music-notation@w3.org>
Subject: Re: Co-chair meeting minutes: May 23, 2025 [via Music Notation Community Group]
Regarding the criteria for SMuFL inclusion, this seems like it could use some refinement. The criteria of a “composer” rather than a community of practice, (as many non-Western, non “work” oriented bodies of music are) is quite narrow. Why should a composer of a very small body of works have inherent privilege over a large, defined but anonymous body of work? (This criteria, for example, would exclude Latin plainchant).

Similarly, the notion of “publisher” is commercial in nature, and would seem to exclude quite a large body of music transmission media and methods, including manuscript materials. What definition of “published” are you using here? If a publishing company is holding the copyrights of a dead composer’s work and not allowing independent publication, does that fail the criteria?

Rather than defining rules about what shouldn’t be included, why not define a process for how something should be included? Right now the process seems to be to open up a GitHub issue and hope for the best [1]  More clarification on the rules and requirements, expected timelines, and perhaps a more open process of community feedback and peer review, might be a welcome improvement. As part of these rules the community member proposing the change would be responsible for doing some of the technical work and documentation as a requirement for inclusion, which might have the happy consequence of taking a bit of the workload off the editors.

-Andrew

PS: I have been reading these emails for a very long time, but have always wondered which of the editors were in attendance. Would it be possible to include a note in these minutes stating who of the editors (or any guests, if such a thing happens) was there for each meeting?

[1] https://w3c.github.io/smufl/latest/about/missing-symbols.html



On 23 May 2025, at 21:11, W3C Community Development Team <team-community-process@w3.org> wrote:
SMuFL



To start the meeting, we had a brief discussion about whether we could or should try to formalise the criteria for whether a set of symbols can be considered for inclusion in SMuFL, since we have had a number of recent proposals that have presented difficulties in assessing whether they are in sufficiently common use.



Myke proposed that we use the following criteria: a symbol can be encoded in SMuFL if it has been used in at least two works by different composers and published by different, independent publishers. We welcome community feedback on this proposal.



MNX



After we made the MNX example documents more accessible in the filesystem, @paulbayleaf found a couple of errors which he reported in #422 and #423, which Adrian has now fixed.



Adrian has added a means of encoding common time and cut common time signatures, which closes issue #94. He has also added an example document that exercises these changes.



Adrian has also brought the MNX converter up to date with a number of the most recent changes to MNX, including to ties, accidentals, slurs, and so on. There are still further things on Adrian's wish list that he plans to work on.



On the continuing topic of beams, Adrian has closed issues #299 and #399, leaving issue #419 open. (We spent the whole of our last meeting on 8 May discussing beams without arriving at any firm conclusions, which is why there were no minutes from that meeting.)



After a great deal of discussion, we believe we have hit upon a scheme for encoding beams that is both less verbose than the original proposal, but still completely explicit for every beam line. We will encode each visible beam line, specifying the first and last note in that beam (with the rule that grace notes encountered in the sequence are ignored). The beam object will itself be nestable, so beam lines after the primary beam will be encoded in a dictionary within the primary beam.



Adrian will write up our proposal and publish it in #419 for community feedback. The co-chairs all feel good about this proposal, and it has come after a great deal of consideration, so we hope it will meet with community approval!



Next meeting



The next co-chairs' meeting is scheduled for Thursday 5 June 2025.



----------

This post sent on Music Notation Community Group



'Co-chair meeting minutes: May 23, 2025'

https://www.w3.org/community/music-notation/2025/05/23/co-chair-meeting-minutes-may-23-2025/




Learn more about the Music Notation Community Group:

https://www.w3.org/community/music-notation


Phone: +49 40 21035 0

Steinberg Media Technologies GmbH
Beim Strohhause 31, 20097 Hamburg, Germany

Managing Directors: Clyde Sendke, Yoshiyuki Tsugawa, Marco Papini
Registration Court: Hamburg HR B 86 534 | VAT ID: DE118677139

Visit the Steinberg website<http://www.steinberg.net> or connect with us on Facebook<http://www.facebook.com/Steinberg>, Instagram<http://www.instagram.com/steinbergmedia>, TikTok<https://www.tiktok.com/@steinbergmedia>, SoundCloud<http://www.soundcloud.com/steinbergmedia> and LinkedIn<https://www.linkedin.com/company/steinberg-media-technologies-gmbh/>.
Watch our Cubase<https://www.youtube.com/cubase>, Dorico<https://www.youtube.com/dorico>, Mobile Apps<https://www.youtube.com/mobile_apps_steinberg>, Nuendo<https://www.youtube.com/nuendo>, Steinberg<https://www.youtube.com/user/SteinbergSoftware>, Audio Interfaces<https://www.youtube.com/audiointerfaces>, VST Instruments & Plug-Ins<https://www.youtube.com/VSTinstrumentsplugins> and WaveLab<https://www.youtube.com/WaveLab> videos on YouTube.

Steinberg’s General Terms and Conditions<https://o.steinberg.net/en/extras/general_terms_and_conditions.html> apply.