[MEI-L] dots on chords and rests

[Johannes Kepper]

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

-------------- 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/20151014/60a1f0ae/attachment.sig>