[MEI-L] dots on chords and rests; chords with notes of differing duration

Thu Oct 15 20:13:29 CEST 2015

I expanded the subject line because (IMO) the basic issue here has to do with _any_ differing durations; there may or may not not be dotted notes.

Good question, Johannes; this is a bit tricky! After looking at a few examples (Mozart, Chopin, Brahms, Amy Beach, Ysaye), I'd say there are three situations. The first is the one you mention, involving dotted and undotted versions of the same duration, where there aren't enough dots for all the notes (generally because of 2nds) but all notes are intended to be played with the same duration.

The second situation is where the notes obviously belong to one voice and some really are intended to be sustained longer than others. Every example I've seen in music for strings is like this and is a chord of at least three notes, the obvious reason for the notation being that modern instruments can sustain only two notes. Anyway, the duration of the chord is simply the duration of its longest note.

But there's yet another situation, of which the first page of Chopin's "Raindrop" Prelude (in D-flat, Op. 28 no. 15) has many examples; the attached excerpt is from a Universal edition. Here there are clearly two voices, and the longer note(s) (halfs or dotted halfs) are in a different voice from the shorter one(s) (eighths or dotted eighths). Or it might be better to think of the longer notes as "really" hiding eighth-note heads at the same pitch, so there are two notes of the same pitched attacked at the same time. There are two examples of this situation in m. 1. For tbe one on the 2nd beat, the duration of the chord in one voice is a half, while in the other voice it's an eighth.

--Don

On Oct 15, 2015, at 11:10 AM, Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> wrote:

Dear all,

thanks for the responses. By no means I question that there are chords with insufficient dots for all contained notes. The point is: Are these lacking dots just lacking in the visual domains, but contained in the logical domain (~ intended to be played), or do they really say that the notes should be played with different durations. Especially in manuscripts, I think it is often the first case. However, there are certainly cases when chords intentionally have notes of uneven durations, and they're probably not restricted to printed music. My question is if these chords should be modeled in MEI using the <chord> element, or if they should be split up into layers. I know this may result in problems with parallel vs. shared stems, but from a logical point of view, it seems more faithful to me. If you keep different durations inside a chord, it seems unclear to me when following notes should start – after the shortest note in the chord, or after the longest. In essence, this introduces ambiguity in the encoding which normally isn't found in the original. I kind of like Perry's approach to say that the chord's attributes specify the logical duration, while the child notes provide information about the graphical appearance. That way, one can still "calculate" with the duration, while tracking the visuals independently from that. This would even allow to have different durations in chords (even though I still don't like them).

My original concern was that querying the duration from the chord element and grandchildren <dot> elements seems impractical. If we'd clarify the guidelines in the direction above, I'm happy :-)

Johannes

Am 15.10.2015 um 06:51 schrieb Christine Siegert <Christine.Siegert at beethoven-haus-bonn.de<mailto:Christine.Siegert at beethoven-haus-bonn.de>>:

Dear Johannes and all,
looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes.
All the best,
Christine

Prof. Dr. Christine Siegert
Leitung Beethoven-Archiv und Verlag
Beethoven-Haus Bonn
Bonngasse 24-26
D-53111 Bonn
Tel.: +49(0)228-98175-22

________________________________________
Von: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>]" im Auftrag von "Johannes Kepper [kepper at edirom.de<mailto:kepper at edirom.de>]
Gesendet: Mittwoch, 14. Oktober 2015 19:13
An: Music Encoding Initiative
Betreff: Re: [MEI-L] dots on chords and rests

I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of <space> elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper…

Just my 2c,
jo

Am 14.10.2015 um 18:42 schrieb Laurent Pugin <lxpugin at gmail.com<mailto:lxpugin at gmail.com>>:

Quick question: how would you encode a chord where only some notes have a dot?

On Oct 14, 2015 5:17 PM, "Byrd, Donald A." <donbyrd at indiana.edu<mailto:donbyrd at indiana.edu>> wrote:
I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations.

--Don

On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>
wrote:

The lack of <dot> within <rest> is an oversight that can be easily remedied.  It will be there in the next release.

<dot> within <chord>, however, is a completely different problem.  It seems to me that chords are never dotted, only the notes within them.  It is true that @dots is allowed on <chord>, but it was placed there as a convenience.  However, one cannot extrapolate from its existence the need to allow <dot> within <chord>.  As Jo has already noted, allowing <dot> within <chord> introduces unnecessary complexity and ambiguity, so I advise against that approach.

I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding

<chord dur=”2” dots=”1”>
<note />
<note />
<note />
</chord>

is short hand for

<chord>
<note dur=”2” dots=”1” />
<note dur=”2” dots=”1” />
<note dur=”2” dots=”1” />
</chord>

and because these attributes are all optional, then there’s nothing inherently wrong with

<chord dur=”2” dots=”1”>
<note dur=”2” dots=”1” />
<note dur=”2” dots=”1” />
<note dur=”2” dots=”1” />
</chord>

The @dur and @dots attributes on <chord> are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking.

Similarly, there is nothing wrong with the following:

<chord dur=”2” dots=”1”>
<note dur=”2” dots=”1”>
  <dot /> <!—points to SVG shape -->
</note>
<note dur=”2” dots=”1”>
  <dot /> <!—points to SVG shape -->
</note>
<note dur=”2” dots=”1”>
  <dot /> <!—points to SVG shape -->
</note>
</chord>

Again, there is redundancy between the @dots attribute on <note> and the <dot> element, but they serve different purposes -- @dots exists in the logical domain and <dot> exists in the visual one.  The <dot> element is providing additional information not communicated by the @dots attribute, not supplanting it.

It’s often difficult to draw a bright line between the logical and visual domains.  As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains.  The addition of another “source”, such as note/dot, separates the domains.  In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements.  (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.)

<dot> is permitted inside <layer> in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization.  Using layer/dot in this case would be abuse in my opinion.

--
p.

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

*****************************************************************
Sonderausstellung im Museum
Originalhandschriften Beethovens – vermittelt von Stefan Zweig
13. Mai 2015 bis 17. Oktober 2015
Mehr...<http://www.beethoven-haus-bonn.de/sixcms/detail.php?id=84917&template=&_mid=Wechselnde%20Ausstellungenn>
*****************************************************************

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington

[cid:AF47F267-9EA0-4D3B-9B05-832E93315F6D]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151015/71a05339/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chopin_RaindDropPrelude_MultidurChords.png
Type: image/png
Size: 275461 bytes
Desc: Chopin_RaindDropPrelude_MultidurChords.png
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151015/71a05339/attachment.png>