Re: A working MusicXML engraver?

Joe,

Agree with all your points (especially group consensus and avoiding ad hoc
implementations), which is why I think a reference implementation should
come from this group rather than using a 3rd party implementation.

Other W3C groups have test suites, and I think a test suite for MusicXML
would be useful, but it may be difficult to implement given that MusicXML
software is written in a variety of languages and platforms. Perhaps a
test-driven approach would work, where test cases are written first, then a
reference implementation follows because it implements those test cases.
However, this could be a very long process because there are so many edge
cases in music notation.

On Mon, Nov 30, 2015 at 10:31 AM, Joe Berkovitz <joe@noteflight.com> wrote:

> To chime in on this subject -- I agree that some sort of reference
> renderer will be an important component of any specification to emerge.
>
> The notion of using any present-day application as a solution to this
> problem is rather tricky. For starters, any reference implementation needs
> to faithfully track a specification that results from the group's decisions
> (not those of a particular member), must be very strict, and must avoid the
> type of ad hoc interpretations that are required today in order to
> successfully import MusicXML from the most popular applications. These are
> perhaps the biggest problems with using anything that exists today.
>
> Also such a reference solution would effectively be part of the
> specification, not just a helpful piece of external software: it would have
> the same status as, say, test suites in other W3C specs.  So it needs to be
> not only open source but also to have key IP rights assigned to the W3C, as
> is now the case with MusicXML itself.
>
> Just my thoughts so far.
>
> Best,
> ...Joe
>
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> 49R Day Street / Somerville, MA 02144 / USA
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>
> On Mon, Nov 30, 2015 at 10:09 AM, L Peter Deutsch <aemusic@major2nd.com>
> wrote:
>
>> > Sibelius 6.1 is over 6 years old, and is not even the latest free update
>> > for the Sibelius 6.x line.
>> >
>> > Maybe you should try a more recent version of Sibelius?
>>
>> I cannot upgrade Finale beyond 2012, and I am sure I cannot upgrade
>> Sibelius
>> beyond 6.2 (the last free update offered for 6.x), because newer versions
>> of
>> these applications require newer versions of MacOS; and I cannot upgrade
>> MacOS beyond 10.6.8, because newer versions of MacOS require newer Apple
>> hardware; and I cannot upgrade my hardware any further, because Apple did
>> not design it to be upgraded beyond its current level.
>>
>> The sibelius.com Web site says the current release of Sibelius requires
>> MacOS 10.9 or later.  I'm downloading the 6.2 update now (it will take
>> several hours, because I live in a rural area), but even if it will
>> install
>> and run on my Mac system, it too is surely several years old.
>>
>> Sibelius, like Finale (and most commercial MS Windows and MacOS
>> applications, and MS Windows and MacOS themselves), shackles users to the
>> upgrade treadmill.  That is why I run only Open Source OSs and
>> applications
>> on all of my computers, except when there is no alternative.  There too I
>> am
>> forced onto the upgrade treadmill at times (I had to upgrade Ubuntu Linux
>> earlier this year to be able to run a version of Firefox recent enough to
>> access an essential Web site), but I am not forced to pay hundreds of
>> dollars for new, buggy software releases every year or two, or to replace
>> my
>> hardware every couple of years if I don't want to.  (Yes, Open Source
>> software has bugs too, but they get fixed on a timescale determined by the
>> community and not by a single vendor.)
>>
>> > If you have full reproduction for a MusicXML import bug, it's useful to
>> > ensure that the repro is reported on http://sibelius.ideascale.com/
>>
>> sibelius.ideascale.com is a "feedback community": I don't understand what
>> connection it has with Avid's developers, since it's not an avid.com or
>> sibelius.com system.  I tried to access the site, but the very first page
>> stalled in downloading, most likely because it requires a newer Web
>> browser
>> than I can install on my Mac (see above).  In any case, do you have reason
>> to think that Avid will even look at bugs reported in Sibelius 6.2?  That
>> would be quite exceptional for a maker of commercial software.  On the
>> other
>> hand, Avid did provide me with an older version of Sibelius when I
>> requested
>> one for compatibility testing, which MakeMusic would not do for Finale,
>> despite my having paid for licensed copies of newer versions in both
>> cases.
>>
>> Meanwhile, this is a nice example supporting my strong advocacy of open
>> file
>> formats, even undocumented ones.  If Sibelius and Finale didn't
>> deliberately
>> lock up their native file formats, third parties would have a shot at
>> creating their own, better importers and exporters.  I made this point on
>> the mup users discussion list recently: Finale and mup have compatible
>> models of headers / footers / page numbering / left/right page adjustment
>> that are more semantically oriented than that of MusicXML, so a direct
>> Finale-to-mup translator could do a better job than one that uses MusicXML
>> as an intermediate format; but because Finale has encrypted their file
>> format as of 2014 (and Sibelius has always encrypted theirs, at least as
>> far
>> back as I have samples), such a translator cannot be written now, at least
>> not one that can be written without a NDA and used without running a
>> sufficiently recent licensed copy of Finale.  (The situation in Sibelius
>> is
>> only a bit better: ManuScript plug-ins do not require a NDA, but they
>> don't
>> have access to all of the score information, at least as of 6.x, and they
>> also require running Sibelius.)
>>
>> If MusicXML or something inspired by it can reach maturity as a
>> well-specified, well-implemented standard, users will have alternatives to
>> this situation.  Despite the serious issues I've encountered with MusicXML
>> in both design and practice, I am still optimistic that this may be
>> possible.
>>
>> Finally, I've received a number of helpful suggestions for where to look
>> for
>> an existing (or nearly-existing :-)) MusicXML renderer.  Thanks to all who
>> responded to my request.
>>
>>                                                 L Peter Deutsch
>>
>>
>