[MEI-L] dots on chords and rests

Thu Oct 15 17:10:55 CEST 2015

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

> 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]" im Auftrag von "Johannes Kepper [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>:
> 
>> 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> 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>
>> 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
>>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mei-l mailing list
>> 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
>> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151015/466b9b4a/attachment.sig>