Re: A working MusicXML engraver?

Hi all

I am currently working on a MusicXML renderer using VexFlow but is part of
a larger architecture but happy to help contribute some aspects of it to
examples and help fleshing out a open-source music engraver.  It may be too
premature overall to offer the whole thing.

Just a thought - I do wonder if a specific implementation would necessarily
be a good idea (since we might get bogged down in implementation rather
than discussing the specification) and it might be better to have
pseudo-code algorithms to go with examples for each part of the
specification (the code could be javascript in nature however...).

Thanks
Joshan



On Mon, Nov 30, 2015 at 5:33 PM, Daniel Richmond <muffinmonsterdan@gmail.com
> wrote:

> Jeremy, thank you for the correction! I indeed had hit reply instead. I
> was thinking of if MusicXML is not the spec going forward, then an image as
> the reference document with notes on the specific notational considerations
> in the image has fidelity over a long term. It also would not be subject to
> any changes in format or handling.
>
> I also think it is worth considering separating playback from the notation
> entirely, taking an object-oriented approach that is dramatically more
> flexible by allowing for non-linear situations that audio isn't inherently
> designed for, unless the playback is also equipped to handle nonlinear and
> aleatoric situations (like some Max/MSP designed pieces).‎ It would be
> asking a lot of a reference suite, though.
>
> Sincerely,
> Daniel Richmond
>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Jeremy Sawruk
> *Sent: *Monday, November 30, 2015 11:17 AM
> *To: *Daniel Richmond
> *Subject: *Re: A working MusicXML engraver?
>
> Daniel,
> You sent your message just to me. Please also copy it to the group:
> public-music-notation-contrib@w3.org
> I definitely think an approach in which test cases are constructed first
> by hand, agreed upon, then tested in MusicXML or whatever supercedes it. I
> agree that it would be nearly, if not completely, impossible to account for
> every edge case in music, but I'm sure a few deliberately written scores
> could account for 95% of the difficulties, 95% of the time.
>
> I believe a set of 5 pieces per era (either chosen or made to meet the
> broad range of requirements) could allow for testing proper handling in
> many cases, particularly in nonstandard notation systems, or alternate
> tuning systems (the Rosary Sonata comes to mind).
>
> I know that as a music notation community group, the presentation of
> discrete objects both on the page and on the screen is the primary goal,
> with playback taking a rather secondary function (no pun intended), but
> test cases should be capable of handling both aspects.
>
> Is there an agreement on how more ambiguous cases (not necessarily rare)
> should be treated, if in any one way at all?
>
> This is my first real message, so I apologize if I am doing this
> incorrectly.
>
> Sincerely,
> Daniel Richmond
>
> Sent from my BlackBerry 10 smartphone on the Verizon
> Wireless 4G LTE network
> (I guess you hit Reply instead of Reply All)
>
> "a few deliberately written scores could account for 95% of the
> difficulties, 95% of the time" - 60% of the time, it works every time ;-)
>
> My opinion is that the tests should look similar to how Vexflow does
> notation testing: http://www.vexflow.com/tests/. These are what I would
> call "unit tests". A score isn't a unit test, but is still a useful test.
> There are already reference MusicXML scores, so I think we should start
> with those scores since their markup is already canonical.
>
> On Mon, Nov 30, 2015 at 12:02 PM, Daniel Richmond <
> muffinmonsterdan@gmail.com> wrote:
>
>> I definitely think an approach in which test cases are constructed first
>> by hand, agreed upon, then tested in MusicXML or whatever supercedes it. I
>> agree that it would be nearly, if not completely, impossible to account for
>> every edge case in music, but I'm sure a few deliberately written scores
>> could account for 95% of the difficulties, 95% of the time.
>>
>> I believe a set of 5 pieces per era (either chosen or made to meet the
>> broad range of requirements) could allow for testing proper handling in
>> many cases, particularly in nonstandard notation systems, or alternate
>> tuning systems (the Rosary Sonata comes to mind).
>>
>> I know that as a music notation community group, the presentation of
>> discrete objects both on the page and on the screen is the primary goal,
>> with playback taking a rather secondary function (no pun intended), but
>> test cases should be capable of handling both aspects.
>>
>> Is there an agreement on how more ambiguous cases (not necessarily rare)
>> should be treated, if in any one way at all?
>>
>> This is my first real message, so I apologize if I am doing this
>> incorrectly.
>>
>> Sincerely,
>> Daniel Richmond
>>
>>
>> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
>> *From: *Jeremy Sawruk
>> *Sent: *Monday, November 30, 2015 10:48 AM
>> *To: *Joe Berkovitz
>> *Cc: *L Peter Deutsch; Robin Walker; public-music-notation-contrib@w3.org
>> *Subject: *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
>>>>
>>>>
>>>
>>
>>
>
>