Some thoughts on arpeggiated chords

[cecilios]

After dealing with importing MusicXML <arpeggiate> elements, I have some thoughts that I would like to share with this group for future MusicXML improvements or for MNX design. Sorry for arriving late, when arpeggios were reviewed for 4.0, issue #281

Who is arpeggiated, the chord or the notes?

My understanding is that when a chord is arpeggiated all its notes are arpeggiated (maybe I'm wrong, I'm not a professional musician), so to me it is non-sense to exclude certain chord notes from the arpeggio. Thus, <arpeggiate> should be just a chord attribute, an element included in the first chord note (let's call it the chord base note) and not an attribute defined on every chord note. The MusicXML specification says: "The arpeggiate element indicates that this note is part of an arpeggiated chord". But defining that a note is part of a chord is already stated by the <chord> element. Thus, there is no need for re-state that the note is part of a chord, and if the chord is arpeggiated the note should be automatically arpeggiated. The only exception I see is for the chord 'base note', as it does not have the <chord> element. Thus, by specifying <arpeggiate> in the chord base note it will be clear that the chord is arpeggiated and every note in the chord is arpeggiated, thus avoiding the need to include the <arpeggiate> element on every chord note. And also avoiding setting contradictory arpeggio attributes in other chord notes <arpeggiate> elements.

The length of the arpeggio line

Should it cover all chord notes? The MusicXML specification says: "The length of the sign can be determined from the position attributes for the arpeggiated elements used with the top and bottom notes of the arpeggiated chord". This suggests that the idea of including <arpeggiated/> on every note is just to deal with densely populated scores in which the arpeggio line would be rendered shorter, excluding it from the top or the bottom notes to not collide with accidentals and save space. Thus my interpretation is that probably MusicXML decided to model the arpeggio line as a set of arpeggio line segments associated to every chord note, to give flexibility for defining arpeggio line extent. By this, it is possible to shorten the arpeggio line if necessary by excluding the <arpeggiated/> attribute from, for instance, the top or the bottom chord notes. But this decision has terrible costs: first, what is the impact for playback of not including a chord note in the arpeggio? should it be played non-arpeggiated, simultaneously with the first note played?. And second, the specification results too permissive, allowing to define valid MusicXML files with multiple contradictory arpeggio attributes and to create non-sense arpeggios. For instance:

note
    arpeggiate up/
note
    chord/
    arpeggiate down/
note
    chord/
note
    chord/
    arpeggiate/

Is the arpeggio up or down? Is the third note excluded from the arpeggio? Should we render a gap in the arpeggio line?

Arpeggios that go cross staff across sets of chords

For brevity I will call them "cross-chord" arpeggios. About them, the MusicXML specification says: "The number attribute can be used to distinguish between two simultaneous chords arpeggiated separately (different numbers) or together (same number)"; and in https://github.com/w3c/musicxml/issues/281#issue-422841317 Michael Good comments that "In practice this has not worked very well, and cross-staff arpeggios typically do not transfer well between applications". In my understanding, the problem is in defining this relation in a total different way from all other relations (beams, slurs, etc.). All other relations define explicitly the start and end of the relation (e.g. type=start, type=continue, type=end), but in arpeggio lines the end of the line is not defined and must be deduced: the arpeggio line can only be considered ended when a new measure is processed and you cannot expect more chords with the same arpeggio number. Thus, arpeggio number 1 defined in measure 3 is a different arpeggio line than the arpeggio number 1 defined in measure 4. Therefore, depending on how an specific MusicXML consumer application is designed, as the arpeggio treatment is totally different from that of other relations, implementing this could be costly and importer/exporters are probably lacking proper implementation. The new unbroken attribute in 4.0 version will help to deduce the end of the arpeggio line but, unfortunately, it is not mandatory.

Possible ideas for improvement

I would suggest restricting the <arpeggiate> element to two places (mandatory): 1) in the chord base note of chords affected by the arpeggio, to define that the chord is arpeggiated and to define its type (type=start or type=continue, mandatory) and the arpeggio attributes (only valid for type=start). And 2) in the last note of the last chord affected by the arpeggio line, to define the end: type=stop and its number; no more attributes allowed in this final element.

Arpeggio line extent should be normally automatically computed by MusicXML consumer applications. For special positioning/length requirements, printing attributes should be defined.

Hope this could help.

Regards, Cecilio

[mdgood]

Thanks for these suggestions @cecilios. The representation of arpeggiated chords could indeed be improved. However, since these involve incompatible changes, could you please post this as an MNX issue?

[cecilios]

Of course. I'll post some comments to MNX. Thank you.