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

Sorry for letting this drop for a couple of weeks. It’s a very busy time for me.

In principle I agree that a stronger and more defined set of criteria for inclusion in SMuFL is a worthy goal – indeed, this whole conversation was prompted by an initial impulse in that direction. This is definitely an area that requires more thought and discussion, so I will try to set aside some time to draw up a more detailed proposal.

To answer your question about how much room we have, SMuFL uses the Private Use Area of the Basic Multilingual Plane, which provides 6,400 code points. The area from U+F400 to U+F8FF is reserved for font-specific and optional glyphs; that’s a range of 1,280 code points. This means the main SMuFL area is limited to 5,120 code points. The highest numbered range currently ends at U+EF0F, so we have around 1,200 spots remaining before we have to either reduce the font-specific range, or expand into another PUA, e.g. PUA-A from U+F0000 to U+FFFFD in Plane 15, which provides a further 65,534 code points.

So in practical terms we are in no danger of running out of code points, but we should balance our desire to be inclusive against the burden we place on font designers, application developers and all other down-stream consumers of SMuFL.

Daniel

From: Andrew Hankinson <andrew.hankinson@gmail.com>
Date: Saturday, 24 May 2025 at 11:13
To: Daniel Spreadbury <D.Spreadbury@steinberg.de>
Cc: team-community-process@w3.org <team-community-process@w3.org>, public-music-notation@w3.org <public-music-notation@w3.org>
Subject: Re: Co-chair meeting minutes: May 23, 2025 [via Music Notation Community Group]
Thanks Daniel,

From the MEI community we often get a lot of projects interested in encoding their corpora, particularly for repertoire that may be seen as “niche” in the face of the CWMN juggernaut. I’m thinking here specifically of the recent CMO proposals for Ottoman symbols, and previous conversations with the Greek Byzantine Neume community. Many of the conversations we have with them, particularly when involving rendering with Verovio, is “first, have your symbols in SMuFL.”

However these notations may not meet the criteria that the minutes communicated, which is why I felt the need to speak up.

Do these notations meet the criteria of a “general” need? They probably don’t. Should SMuFL work with these folks to help them move their music into a digital form? Personally, I think that would be a very good thing to do.

This is why I suggested improving the process of proposing additions, rather than setting in place rules governing what cannot be included. With a process in place, the merits of the proposal itself can be judged, preferably in conversation. What may not be novel or important to some people may be a significant cultural innovation to others. It’s not because there is conflict or controversy, it’s more to give space and process for a group to make their case fairly and equitably.

There was a recent email to this list trying to re-propose a ticket that was already opened for the CMO symbols. I see this not as someone being pushy, but as an indication that there needs to be some idea of what step they are in the process of their proposal being accepted (or rejected).

As SMuFL matures, the bulk of the new proposals will be for niche or specialized notations, and setting in place criteria which many of these notations will not meet would seem counterproductive — a gated community rather than an inclusive (but structured) initiative.

Is there a particular reason why some symbols shouldn’t be included? How many more code points in the private use area are available? Is there a danger of running out? If so, then yes there probably needs to be some form of gatekeeping. But if not, does it hurt anything to have the symbols of Easley Blackwell Jr., as long as they are well-defined?


On 24 May 2025, at 00:20, Daniel Spreadbury <D.Spreadbury@steinberg.de> wrote:

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.