[MEI-L] Repeats

[Craig Sapp]

Hi Andrew,

Here is an email from Perry to this list on 16 June 2015 related to the
subject:

-=+Craig

=====

I thought this was covered in the Guidelines, but taking a closer look, I
find that it isn't.  So, I'll try to explain.

There are multiple aspects of repeated sections that must be taken into
account.  First, there are the signs found in the notation. Second, there
is the question of how the signs should be interpreted in performance.  The
first aspect is partially covered, as you already know, by the @left and
@right attributes on <measure>.  The second is encoded using the
<expansion> element.  <expansion> provides the means to encode the
performance order of <section> and <ending> elements.  There could be
multiple interpretations of the repeat structure, so <expansion> is
repeatable.

Here's an encoding of the relevant portion of your first example:

<section>
  <expansion plist="A Ending1 A Ending1 A Ending2"/>
  <section xml:id="A">
    <measure n="1" left="rptstart"/>
    <!-- measures 2 - 8 -->
  </section>
  <ending n="1" xml:id="Ending1" label="1. 2.">
    <measure n="9" right="rptend"/>
  </ending>
  <ending n="2" xml:id="Ending2" label="3.>
    <measure n="10" right="end"/>
  </ending>
</section>

The repeat signs and the ending bar are encoded using @left and @right
attributes.  <ending> elements are used to wrap the measures under the
first and second ending brackets.  In order to be able to assign an ID to
the repeated part of the music (measures 1 - 8), these measures are wrapped
in a child <section> element.  It's the performance order of the children
of this outer section that the <expansion> element's @plist attribute
describes: section A, then Ending1, section A, then Ending1, section A,
then Ending2.

The only other "wrinkle" is the labeling of the endings.  The @n attribute
can be used to give a number or name to elements, such as the endings in
this case.  But, since @n can only hold a single token, if you want a space
in the name, it's better to use the @label attribute. (I'll leave the
larger discussion of "name" vs. "label" for another time.)

Your second example doesn't introduce any new problems, so I leave it to
you to work out its encoding.  If you run into difficulty, though, just let
me know.


On 18 July 2016 at 17:56, Andrew Hankinson <andrew.hankinson at gmail.com>
wrote:

> Hi everyone,
>
> I was just looking at how repeats are defined, and it strikes me as a bit
> odd.
>
> Currently, it seems as though repeats are encoded by using the `@right`
> and `@left` attributes on `<measure>`. My biggest concern with this is that
> it seems to confuse logical and visual functions of repeats; that is, it
> encodes where a particular symbol is drawn, but doesn't actually encode the
> semantic existence of a repeat.
>
> I am also trying to figure out the note on `@left` which, essentially,
> states that you should not use it. I'm not sure how else you would encode a
> repeat start on a measure without using `@left="rptstart"`. Any insights?
>
> An alternate solution may be to re-work '@left' and '@right' into three
> new attributes to separate visual from functional. The first `@repeat`,
> takes values of "start", "end", or "both." Two others, "@startbarline" and
> "@endbarline" can contain the visual values "dbldotted", "dbldashed", etc.
> A Schematron rule might be set up to catch the cases where there exists
> 'repeat="start"' and 'startbarline="dbldotted"' and set a warning or an
> error. (It may be desirable to have 'repeat="start"' and
> 'startbarline="invis"', though...)
>
> -Andrew
> _______________________________________________
> 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/20160718/2499de09/attachment.html>