Re: The MusicXML challenge

...and the voice determines which noteheads are stemmed together?

James Sutton
Dolphin Computing
http://www.dolphin-com.co.uk <http://www.dolphin-com.co.uk/>



> On 21 Oct 2015, at 19:29, mogens@lundholm.org wrote:
> 
> 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. 
>> ....
> 
>