RE: The MusicXML challenge

Hello, all!
I’m just joining the MusicXML discussion. I am a software developer for Musicnotes.com (which, if you don’t know, is a digital sheet music publisher), and am interested in participating in creating a sheet music format that makes us more able to import and export with other publishers. We are interested primarily in preserving the musical layouts we receive from those other publishers. My musical training comes from a few years of piano lessons and many, many years as part of 4-part choirs. In addition, I’ve been working on the display of musical notation here at Musicnotes for several years, which has given me a grasp of the needs of other instruments, especially guitar. The following suggestions are made from the standpoint of someone who has had to write a program to process both the Finale and Sibelius versions of MusicXML 2.0 and 3.0 in order to import them into our own music editing software.

In regards to Modens suggestion below, in my opinion, part of the challenge of representing sheet music (as opposed to audio music), is that the graphics is part of it. If all we wanted was to represent audio music, we could create a human-readable version of MIDI, for which Modens suggestion would work very well.

The beauty of the vision of MusicXML, though, is that it’s not just the music. There are several ways of displaying 8th notes: are they notes with flags, or beamed to each other? Do the stems go up or down? Do we, due to other musical considerations, need to represent a dotted quarter note instead as a quarter note tied to an 8th? The problem with finding only one way to represent the notes is that there are more than one way to represent the notes in musical notation, and each one has its place, even if it’s just the composer’s preference.

On the other side, if you just specify the notes as the location of characters on a page without respect to the flow of the music, you lose all coherency. The <harmony> tag used for guitar chords seems to be one of the worst for this, and it is one of the cases that is hardest to handle, since they aren’t actually notes and don’t actually have built-in durations, but they do have a time at which they are supposed to occur.

Like Peter Deutsch, I am in favor of a system that specifies note (and harmony) locations musically within a measure. We can make many of the same assumptions that MIDI timing does for this. Assume that each note starts musically at the same time as the previously specified note, unless an offset is specified. Unlike MIDI, and Peter, I don’t consider it vital that time order equal file order, and would recommend this offset be specified “from start of measure” instead of “from last note”, but that can be debated – there are pros and cons both ways, usually having to do with whether you care more about the audio or graphics. For instance, audio is forward-only, and wants all the data for the current time specified at once before skipping “forward” to the next played notes. However, for graphics, it is more logical to represent a set of beamed notes one after another, and then “backup” to a specific offset from the measure in order to specify another voice that happens at the same time. I agree that explicit “backup” and “forward” commands should go.

Each note should also specify its notational type (e.g. quarter, 8th, etc.), stem direction, beaming, slurring, and audible duration. Tied notes should have their initial note specify the entire audible duration of the note and have the following notes specify a 0 duration because they do not actually sound. How to represent the audible duration of staccato or legato notes is something I’m undecided on: it could be shortened in the xml itself, or the interpreter could be left to recognize the staccato articulation and apply it itself.

Layout is very important in many applications. Knowing where the “line breaks” and “page breaks” come in the original composition can be important, since there are often usability issues around turning pages or tied notes when you are dealing with a printed version, or if you are trying to faithfully reproduce an original score. It should not be so important that reflow is impossible, though, so while I support continuing to have these constructs in MusicXML, the location of non-notes that are musically important (lyrics, harmonies, dynamic indicators, coda, etc.) should be tied in at the measure or note level (possibly also using an offset from start of measure) , and not to x-y locations on the page.

On a completely different note, as a sheet music publisher, being able to clearly define the title, subtitle, proper attributions (composer, etc.), and copyright declaration as part of the specification, rather than simply as extra text on the first page, would be very good. And (also like Peter Deutsch), I would like to be able specify “Page number on top right of even pages, top left of odd pages” without having to list each page number individually (once again, that goes back to the reflow issue).

--Christina Noel
Musicnotes.com



---

Christina Noel
Sr. Software Engineer, Musicnotes

Direct:  |  Fax: 608.662.1688  |  CNoel@musicnotes.com<mailto:CNoel@musicnotes.com>

[Musicnotes.com]<http://www.musicnotes.com>

www.musicnotes.com<http://www.musicnotes.com/>  |  Download Sheet Music

Musicnotes, Inc  |  901 Deming Way, Ste 100  |  Madison, WI 53717
Facebook<http://www.facebook.com/musicnotesdotcom>  |  Twitter<http://twitter.com/musicnotes>

From: mogens@lundholm.org [mailto:mogens@lundholm.org]
Sent: Wednesday, October 21, 2015 1:30 PM
To: public-music-notation-contrib@w3.org
Subject: Re: The MusicXML challenge

My point of view is the music - not the graphics. (Making a MusicXML player) but ...

About changing the <chord>-command, I would prefer a very simple solution: Remove <chord>, <backup>, <forward> and
<tie>-commands (for longer notes). Let all duration be a total duration and do not step the time-division
by a <duration>. Add a new command <timestep> to advance the time. This would make it a lot easier to handle notes.
Notes to be played under same time division should be specified low to high and <divisions> should be as small as
possible - then I could have a dream: That there was only one way to represent the notes!

However - we do have the existing system. We have program code to handle the existing system.

Regards
Mogens

On 2015-10-20 07:51, L Peter Deutsch wrote:
....

The obvious fix for <chord/> is to replace this element with a <chord>
element at the measure level whose children are the notes of the chord,
and to consider carefully which of the current attributes and elements of
notes should be associated only with chords, only with notes, or (in as
few cases as possible) with either.

<backup> and <forward> are much worse: they interact with *every* element
that refers to the conceptual flow of time in the score *or* settings such
as margins that may change in the course of the file.  For every such
element, the specification must state whether "before" and "after" refer
to the time sequence as modified by backup/forward, or to the sequential
position of the element in the file.  Again, a very large red design flag.
....