Re: Revised Community Group charter – request for feedback. A list of Musical Symbols in "Deliverables"?

Hi Mogens, Glenn,

The suggestion is appreciated. At present the chairs don't feel it's
productive to include this as a separate deliverable in the charter,
because the SMuFL specification enumerates many supported musical symbols,
and the MNX spec will also provide details on standard semantics (where
they are agreed on) for all supported symbols and symbol classes in terms
of rendering and playback. A concordance between documents is useful, but
that can be added to the MNX specification.

We also expect certain MNX profiles to identify a set of core supported
symbols.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Mon, Jul 3, 2017 at 4:14 PM, Jeremy Sawruk <jeremy.sawruk@gmail.com>
wrote:

> "It does seem to me that a list of symbols and semantics, perhaps partly
> by reference to existing works, would be an extremely valuable foundation
> for standards that are trying to use those symbols and semantics" - I agree
> that such a document would be useful if it already existed, but it sounds
> like an enormous undertaking would be required to produce this document
> (i.e. a greater amount of effort would be required than would be needed for
> MNX or SMuFL).
>
> "If the character exists, but the semantics are not well-defined, it
> leads to use of the existing character for the omitted semantic, instead of
> defining a new character (with the same shape) for the omitted semantic." -
> This is a valid point, but again, I think it is too ambitious to try to
> document every single use case of a symbol before releasing the standard.
>
> MusicXML, MNX, and SMuFL are evolving standards, and they expand as new
> use cases are discovered. That being said, I think all three standards
> provide a solid foundation, and MNX starting from a clean slate, can learn
> from previous semantic issues in other music encodings. MusicXML does have
> a history of ambiguity in semantics, but I think MusicXML 3.0 and 3.1
> really clean up the issue, and newer versions of MusicXML are always
> backward compatible to earlier versions through the use of XSLTs which are
> included with every version of MusicXML.
>
>
>
> On Mon, Jul 3, 2017 at 3:12 PM, Glenn Linderman <v+smufl@g.nevcal.com>
> wrote:
>
>> The list sounds extremely useful, though. I too have found other lists of
>> notation incomplete.
>>
>> SMuFL documentation does include names of many symbols (but in particular
>> doesn't mention volta brackets, I was surprised at its omission in the past
>> and wrote something about it somewhere in one of these mailing lists), and
>> together with the Bravura font including the samples of what they look
>> like, it is very inclusive, but not yet all inclusive.
>>
>> SMuFL does distinguish semantic differences of various symbols that look
>> the same by giving them different names and codes. In at least these cases,
>> it would be appropriate to define exactly what those semantic differences
>> are; it would also be useful to have a cross-reference of symbols that look
>> the same but are used with different semantics.
>>
>> It does seem to me that a list of symbols and semantics, perhaps partly
>> by reference to existing works, would be an extremely valuable foundation
>> for standards that are trying to use those symbols and semantics in
>> meaningfully interchangeable formats. If there is a semantic use of a
>> character that is inadvertently omitted from SMuFL, it is much easier to
>> discern that if the semantic use of each SMuFL codepoint is documented. If
>> the character exists, but the semantics are not well-defined, it leads to
>> use of the existing character for the omitted semantic, instead of defining
>> a new character (with the same shape) for the omitted semantic.
>>
>> I don't know what to say about English versus German versus other
>> languages. Only English is directly useful to me, unfortunately, although I
>> do work with multi-lingual people on multi-lingual projects, but those
>> people must know some English to communicate with me. How broadly
>> international standards are translated into languages other than English is
>> unknown to me, but I have no issues with them being translated. I guess I
>> don't see a particular benefit to translating only a fraction of such a
>> document, the symbol names, without translating the rest of the document as
>> well.
>>
>> On 7/3/2017 11:52 AM, Jeremy Sawruk wrote:
>>
>>> Hi Mogens,
>>> I'm sorry, but I don't think such a document should be a deliverable of
>>> the group for the following reasons:
>>> - I think it is too open ended and broad in scope. Group members could
>>> end up spending a lot of time on this when they should be focused on
>>> developing our core deliverables (such as MNX standards etc.)
>>>
>>> - A lot of this is already covered in the SMuFL documentation. I find
>>> the SMuFL documentation to be one of the most comprehensive list of musical
>>> symbols. To your point, however, it is not related to MusicXML or MNX, and
>>> I don't think it should be. I think it is important to keep SMuFL separate
>>> from MusicXML/MNX, as it can be used in other contexts (just like Unicode
>>> can be used outside of HTML).
>>>
>>> - I don't understand why you would want the symbol names in just English
>>> and German. Music is an international language, so this decision seems
>>> arbitrary.
>>>
>>> If you wish to pursue such a project on your own, then others in the
>>> group (and elsewhere) may find this information useful. Unfortunately, I
>>> feel that it detracts from the primary focus of the group.
>>>
>>> J. Sawruk
>>>
>>> On Mon, Jul 3, 2017 at 2:26 PM, mogens@lundholm.org <mailto:
>>> mogens@lundholm.org> <mogens@lundholm.org <mailto:mogens@lundholm.org>>
>>> wrote:
>>>
>>>     Thanks.
>>>
>>>     Another consideration: I think that the section ”Deliverables”
>>> should have a document ”List of musical symbols”. Several such documents
>>> are on the net but they are all incomplete and not exact in the
>>> description. And not related to MusicXML/MNX.
>>>
>>>     Then for every symbol the corresponding MusicXML and MNX keyword
>>> should also be noted. Also it would be good to have the symbol name in both
>>> German and English. (The German word would normally be the same as in
>>> Danish, Swedish, Norwegian etc.). Maybe also the references to SMuFL could
>>> be included.
>>>
>>>     Examples of how a description should be like:
>>>     1. Repeats: A Repeat Start shall save current repeat position and
>>> repeat number. And set current repeat number to one.
>>>
>>>     2. Repeats: A Repeat End shall set the current position back to
>>> repeat position and restore the saved repeat position and repeat number.
>>> (image and translation ...)
>>>
>>>     3. Volta brackets (endings): A Closed Volta bracket shall be played
>>> if the current repeat number is equal to the volta number.
>>>     (image and translation ...)
>>>
>>>     4. Volta brackets (endings): An Open Volta shall be entered if the
>>> current repeat number is equal to the volta number. The repeat number shall
>>> be set to one. A repeat inside a volta must appear after the keyword for
>>> volta (<ending …>). ...
>>>     (image and translation ... )
>>>
>>>     This document would also be a link between the other documents. With
>>> a proper tool missing links could be identified.
>>>     Would this List of Musical Symbols be a good idea?
>>>
>>>     /Mogens
>>>
>>>     On 2017-06-24 12:41, Daniel Spreadbury wrote:
>>>
>>>>     CG does indeed stand for Community Group, but CLA stands for
>>>>     Contributor License Agreement. See here:
>>>>
>>>>     https://www.w3.org/community/about/agreements/cla/
>>>>     <https://www.w3.org/community/about/agreements/cla/>
>>>>
>>>>     Daniel
>>>>
>>>>
>>>
>>
>>
>