Re: Shorter and longer term agendas

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