Re: Proposal for Encoding Common Musical Notation in Unicode

Dear Jim,

Thank you for your comments. I find them *utterly *helpful.

If I may sum up, you are pointing to the following challenges:

   - The paragraph talking about plain text is missing its point; many
   people will consider CMN as formatting of underlying characters, it is
   therefore a controversial assumption of mine, that needs be elaborated and
   that could undermine the whole process. Your argument about the parallel
   between mathematics and music is a powerful one, which is due to come up.
   (You conveniently point to the arguments that would permit to re-write the
   paragraph and support this assumption.)
   - There have already been decisions made about CMN being out of scope,
   and we will need the Consortium to "overturn its precedent". I tried to
   provide a basis for this, but seemingly it is not enough.
   - The text layout engine designers are key stakeholders. (Aren't they
   supposed to meet Unicode's every desire? (sardonic laugh) OK. well. Erm.
   Fair point.) No, I had not thought of contacting them, so silly of me. I am
   not sure how to contact them either. I assumed that the first step was to
   contact you all first, i.e. experts and users, anyway.
   - There are ways to embed a music part in an otherwise textual document.
   I have not seen them used to a level I have seen pictures embedding (by
   far), which lets me assume that it is not convenient and that a direct
   copy-paste would be necessary, but all this is not written down or even
   mentioned and that is an issue. Let alone proven, which is your fifth point:
   - A demonstration application is a necessary next step. Something that
   Michael Good made crystal clear as well.


My conclusion of the discussions so far is that:

   1. Next step is the creation of a demonstration software, and without
   it, there is no going further.
   2. Revision of this document is necessary but depends on point 1.
   3. The proposal in itself reaches some interest, but the submission of
   this proposal, as of now, is pointless.

As told in my previous mail, I have no clue as to how to proceed with point
1. I do not know of any contact to help me, and do not have the necessary
proficiency myself to create the foundation of the application.
So... If anyone reading this is able and willing to tackle a part of step
1., or if anyone knows where I could find such a person, I would be
immensely grateful.
I will come back to you when we have something for you to play with.

Regards,
Bertrand.


On Fri, Sep 4, 2020 at 3:04 AM Jim DeLaHunt <list+w3c@jdlh.com> wrote:

> Bertrand Émerit:
>
> My name is Jim DeLaHunt. I am a software engineer who is subscribed to
> the W3C Music Notation group. Thank you for sharing your Unicode
> proposal with this list. I have a few comments for you. I hope you find
> them helpful.
>
> On 2020-08-31 16:46, Bertrand Émerit wrote:
> > Dear ladies and gentlemen,
> >
> > On September 30th I plan to submit the attached proposal to the
> > Unicode Consortium.…
> > I will be honoured for any review or comment of the documents. Feel
> > free to forward as needed, and I would appreciate that you inform me
> > if you forward outside your organization.
> >
> > The proposal should fit nicely if not enrich (and certainly not make a
> > dent in, or replace) your current works, including SMuFL, MusicXML and
> > MEI.…
>
>
> I have been following the Unicode Standard for a few years, as a
> participant on their lists. I see that you take the Unicode encoding
> process seriously. You have read the Unicode design principles, and
> section 12.11 “Musical Symbols”. Despite this care, I suspect that you
> will encounter resistance based on the design principle of "Plain text",
> and on the history of design decisions that music notation is outside
> the scope of Unicode.
>
> The question of what is and is not "plain text" is a surprisingly
> difficult one. It is hard to make a concrete argument that music
> performance and music notation are in the same scope as, or a different
> scope from, letters and words and sentences. However, I suspect you will
> get qualitative arguments that music is out of scope for plain text.
> This will likely boil down to music being different than spoken
> language, and to people not presently embedding music notation in
> textual mechanisms. The presence of emoji in the Unicode Standard makes
> this argument harder, because emoji are pictures, which are different
> than spoken language. However, there is rich current practice of using
> emoji as pictures within textual mechanisms, dating back to Japanese
> mobile phones of the 2000's, and newspaper typography earlier.
>
> Section 12.11 “Musical Symbols” is evidence that there was already a
> discussion about music notation being out of scope for Unicode. I would
> also point you to the analogous situation of mathematical markup.
> Mathematical expressions and layout are also out of scope for Unicode.
> The result was that parties interested in mathematical expressions got
> together and made a separate specification, MathML. I would argue that
> MusicXML, MNX, MEI, etc. are the analogues of MathML for music notation.
>
> It looks like one of the motivations for this proposal is "to be able to
> let scores be text in textual documents and rendered by the text
> renderers of common platforms." I am concerned that having this proposal
> accepted into the Unicode Standard will not be sufficient accomplish
> this goal. You will also need the text renderers (or in OpenType font
> and Unicode terms, the text layout engine, the font format, and the
> glyph shaping engine) to add code which supports this proposal, and for
> those text renderers to get deployed on users' computers over time. Have
> you made contact with the leadership of these text renderers and got
> their interest?
>
> There are other ways of mixing music notation and textual documents.
> This proposal is an approach that defines a form of music notation which
> fits within a text rendering environment. Your document points out
> another approach that renders music notation to an opaque image or
> visual form, and insert that in the textual documents. There are other
> approaches. TEI (an XML language for representing text documents) and
> MEI (an XML language for representing music notation) are working on
> ways in which MEI objects can be embedded in TEI documents. This creates
> a document representation which is richer than just TEI, and includes
> the full musical content of the MEI object. Another approach is
> application-level object linking. My word processor, LibreOffice, allows
> me to insert a Formula Object into a word-processing document. This
> provides a window into a mathematical expression editor, which contains
> the knowledge of representing expressions and rendering their correct
> appearance. It allows me to copy that Formula Object and paste into a
> compatible application's document, with the mathematical semantics
> preserved. You can imagine a word processor adding support for an MNX
> Object or an MEI object. That approach might address the user demand you
> are trying to serve.
>
> I second Michael Good's suggestion that a next step be to create some
> software which demonstrates this encoding system in use. Writing
> software is in part an exploration of the problem space. You will
> understand the strengths and weaknesses of this approach much better
> when you can use it practically. You can use PUA codepoints temporarily
> for this prototyping. It would be powerful to get user feedback on how
> useful this integration approach is, in comparison with the "insert
> opaque image" approach or an MNX Object approach. What kinds of notation
> and formatting will it not be able to represent?  How severe are those
> limitations? What kinds of easy intermixing of notation with text will
> it permit? How beneficial are those opportunities?
>
> This is a serious and interesting proposal. Thank you for putting it
> forward, and giving us all a new way of looking at the challenge of
> music notation. I would be happy to continue discussing it.
>
> Best regards,
>         —Jim DeLaHunt, software engineer, Vancouver, Canada
>
> --
> .   --Jim DeLaHunt, jdlh@jdlh.com     http://blog.jdlh.com/ (
> http://jdlh.com/)
>        multilingual websites consultant
>
>        355-1027 Davie St, Vancouver BC V6E 4L2, Canada
>           Canada mobile +1-604-376-8953
>
>