Re: The MusicXML challenge and Chords

James Sutton wrote:
> ..and the voice determines which noteheads are stemmed together?

Well - you have a point. (I may have too much focus on playing the music.)
No, I would not like to let the voice determine this.

Then would rather group notes:
<notes><note ...> </note></notes>
and keep the simplicity (i.e. also for single notes).

I think the music should be the base, the graphic appearance an addition.
(Like MIDI: notes are "events", other stuff is "metaevents"). But this 
is MusicXML,
and we must be pragmatic.

Chords are also related to the <instrument..>-definition, which causes
much complexity. I think there should have been only one instrument
per part. This would require a new command, could be like:
<part-merge 1,2>
to show the instruments mixed.

Just some thoughts - another way is to keep it as it is, but make a
document with statements about MusicXML. I would divide this into
  "Mandatory", "Recommendations" and "Clarifications" in order to
make MusicXML more aligned.

Kind regards
Mogens


On 2015-10-23 19:07, James Sutton wrote:
> ..and the voice determines which noteheads are stemmed together?
>
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk
>
>
>
>> On 21 Oct 2015, at 19:29, mogens@lundholm.org 
>> <mailto: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.
>>> ....
>>
>>
>