Re: Shorter and longer term agendas

Dear Joe, Michael, Daniel and CG,

First, let me thank the founders of this Community Group for setting up
this exciting initiative! Second, I would also like to disclose Tido's
commitment to the MEI community, myself being part of the Technical Team.

At Tido we have chosen MEI as the core framework for our music notation
encoding, because its philosophy is aligned with the way we think about not
only music notation, but music in general. We find that the underlying
principles behind MEI make it a very powerful tool, albeit one that needs
skill to operate. Just as musical works are multi-dimensional abstract
objects (including, but not restricted to notation and media), the notation
model itself also has to be as rich and semantically well-structured as
possible, and only such a model can facilitate truly rich user experiences.
As far as I can see, this is among the motivating factors for most of us in
this community, be it publisher, musicologist or developer.

*> If its conceptual model and setup is of interest to a wider, potentially
commercial community*

Not only from our own point of view, but judging by the responses so far
(Adrian's and Jamie's comments are particularly reassuring that some
MusicXML users too, think along the same lines), the answer to the question
implied above is definitely yes. I think the remaining question is if
this W3C group will be the ground where the commercial and academic
communities compare their notes, and establish a common language. At Tido,
we strongly believe this could only be beneficial for everyone involved.

We realise that, given Tido's approach to music encoding in general, our
contribution may be most valuable regarding the long-term goals. However,
we will be following the short-term efforts closely, and will participate
wherever we feel our contribution is of any value to the community.

Best wishes

Zoltan Komives

Tido Enterprise GmbH

On Tue, Sep 29, 2015 at 2:56 PM, No-C-Notes Music <xinamusic@no-c-notes.com>
wrote:

> Hi,
>
> I use MusicXML to produce my product No-C-Notes audio music description.
> I am totally with Adrian on his response point #1.
>
> I end up using 3 different software because each does not export MusicXML
> in the same way, therefore my audio output is varied with each.  Because of
> this, I am the only one who can use my application unless I design it to
> work with only one music scan and print notation software.
>
> Short term list:  <fingerings> and <repeat> cause me the most time and
> grief.
> Long term list:  Ditto on Adrian's point #2.
>
> With appreciation,
> Christina Cotruvo
> www.no-c-notes.com
>
>
> On Mon, Sep 28, 2015 at 4:10 PM, Adrian Holovaty <adrian@holovaty.com>
> wrote:
>
>> Hi all,
>>
>> Here's my two cents.
>>
>> Context: I run Soundslice (soundslice.com), which makes interactive,
>> web-based sheet music technology. It's our own JavaScript-based music
>> engraving engine that can read MusicXML and a few other formats. It uses
>> SMuFL exclusively. We also run a free MusicXML viewer:
>> https://www.soundslice.com/musicxml-viewer/
>>
>> Clearly this has been quite a free-ranging discussion so far! Here are
>> two questions I want to raise:
>>
>> 1. How can we ensure vendors do the right thing?
>>
>> "Enforcing" the standard is just as important as creating it. In my
>> experience, the primary pain of dealing with MusicXML is that each vendor
>> (Sibelius, Finale, MuseScore, Notion) generates it differently, leading to
>> inconsistency. The biggest general problem is lack of semantics -- like
>> piano fingerings getting saved as <words>. Or data that's completely
>> missing -- like the fact that Sibelius doesn't export various guitar
>> notations such as bends and slides.
>>
>> One simple idea is to make it crystal clear where to report
>> vendor-specific MusicXML-related bugs. When I find a problem in Sibelius, I
>> have no idea whom to contact, so I just hold my nose and code around it.
>>
>> Also, I like the idea of the MusicXML Sanitizer as a stopgap, but it's a
>> proprietary thing owned by a for-profit company, with an uber-long ToS; it
>> should be a free, open-source tool.
>>
>> 2. How can we ensure human engravers (and other users of notation
>> software) input their notation in the most semantic way possible, so that
>> our efforts to improve MusicXML will actually be worthwhile?
>>
>> Michael G. wrote: "Nor can [MusicXML] distinguish formatting that
>> clarifies semantics, such as for collision avoidance, from formatting that
>> is more a matter of house style, such as font choices and spacing
>> preferences."
>>
>> YES! I love this idea! But even if we make it happen, all that work will
>> be for nothing unless people in the Real World start caring about semantics
>> in their notation.
>>
>> MusicXML will only know something is presentational if a notation editor
>> makes the distinction in the first place. Does the notation editor
>> encourage you to do things the right way, or is it easy to "hack" things?
>> In my experience, human engravers prioritize print layout instead of
>> semantics, which leads to subpar MusicXML data. (By the way, this problem
>> is rampant in many industries; I wrote about the same problem in the
>> journalism world back in 2006:
>> http://www.holovaty.com/writing/fundamental-change/)
>>
>> Perhaps the answer to this second question is showing people the kinds of
>> things that are possible if notation is properly input.
>>
>> As for the short-term projects Michael G. suggested (build initial
>> MusicXML spec, add support for SMuFL glyphs within MusicXML, fill remaining
>> gaps in SMuFL, document notation use cases): all sounds fine as a first
>> step.
>>
>> Adrian
>>
>> --
>> Adrian Holovaty
>> Soundslice: https://www.soundslice.com
>> Personal: http://www.holovaty.com
>>
>> On Mon, Sep 28, 2015 at 3:06 PM, Michael Good <mgood@makemusic.com>
>> wrote:
>>
>>> Thanks to everyone for your responses the proposed agenda for the
>>> community group. So far the discussion has focused largely on longer-term
>>> goals and alternate representations. There has been great material for
>>> discussion and we would like to hear from more people about this. In
>>> particular, we would like to identify specific cases and scenarios where a
>>> comparison with other music representations is most valuable.
>>>
>>> We would also like to see more feedback on the other questions posed to
>>> the group:
>>>
>>>    - Are we picking the correct short-term projects to start with?
>>>    These are 1) Initial MusicXML specification 2) MusicXML support for SMuFL
>>>    glyphs, 3) Identify and fix any remaining gaps and adoption barriers in
>>>    SMuFL.
>>>    - Have we defined the short-term projects properly?
>>>    - What would you most like to see done with MusicXML right away?
>>>    - What would you most like to see done with SMuFL right away?
>>>
>>> We would be especially interested in hearing from more of those who are
>>> currently using MusicXML and/or SMuFL. At this point it is just as helpful
>>> to hear "yes, this sounds like the right projects" as it is to hear "here
>>> are some proposed alternatives."
>>>
>>> We would like to start work on the shorter-term projects soon. Could you
>>> please send your responses by the end of this week?
>>>
>>> We know that some people have had trouble posting to the list. Sometimes
>>> your first post to a W3C mailing list can take a little time to get mailed
>>> out. If you encounter any problems posting to this list, please feel free
>>> to contact one of the co-chairs directly.
>>>
>>> Best regards,
>>> Michael
>>> _________________________________
>>>
>>> *Michael Good*
>>> VP Research and Development
>>> MakeMusic, Inc.
>>>
>>>
>>
>
>
> --
> Christina Cotruvo
> No-C-Notes
> Duluth, MN  USA
> www.no-c-notes.com
>

-- 
www.tido-music.com

Tido Enterprise GmbH (Amtsgericht Leipzig, HRB 29529), Talstrasse 10, 04103 
Leipzig, Germany. Disclaimer: The information in this e-mail including any 
attachments is confidential and may be legally privileged. If you have 
received this message in error, please contact the sender immediately and 
delete this message and any copies from your computer and network. The 
unauthorized use, distribution, copying or alteration of this e-mail and 
any attachments is strictly forbidden.