Re: Shorter and longer term agendas

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.
>
>