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