[MEI-L] dots on chords and rests

[Laurent Pugin]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151014/5e711e7a/attachment.html>