Corpora Work Progression

This page tracks the current state of corpus work, known issues, recurring MEI encoding patterns, and links to general documentation.

• Introduction to Git and GitHub

• Introduction to MEI and XML schema

tba

tba

mei-friend is creating new branches if it cant be properly saved on main branch. ALWAYS CHECK WHICH BRANCH ARE YOU SAVING YOUR WORK ON!!!

tba

In MEI, ordinary rests and full-bar rests are not the same thing.

• <rest> = a non-sounding event with a specific written duration
• <mRest> = a complete measure rest, independent of meter
• <multiRest> = multiple consecutive complete-measure rests compressed into one symbol, typically in parts
• <mSpace> = an explicitly empty measure, where no musical content is encoded but nothing is considered missing

Use <rest> when the source shows a rest with a specific notated duration inside the rhythmic flow of the layer.

Typical cases:

• quarter rest inside a 4/4 measure
• half rest followed by notes
• a rest that is part of ongoing voice activity
• silence in one voice while another voice continues

Example:

<layer n="1">
  <note pname="c" oct="4" dur="4"/>
  <rest dur="4"/>
  <note pname="d" oct="4" dur="2"/>
</layer>

Use <mRest/> when the layer is silent for the entire measure and the source expresses that as a full-bar rest.

This is the preferred encoding for a complete measure rest because it does not depend on the current meter. MEI explicitly defines <mRest> as a complete measure rest in any meter. :contentReference[oaicite:1]{index=1}

Example:

<measure n="12">
  <staff n="1">
    <layer n="1">
      <mRest/>
    </layer>
  </staff>
</measure>

For our corpus work:

• use <rest> for ordinary rests with explicit duration inside a measure
• use <mRest/> when a whole measure is silent in that layer
• do not replace a full-bar rest with a duration-based <rest> just because the meter happens to allow it
• prefer <mRest/> when the notation is semantically „whole measure rest“

MEI states that it is a semantic error to mix <mRest> with other events in the same layer. So a layer containing <mRest/> should not also contain notes or ordinary rests. Control events such as fermatas may still occur alongside it.

A full-bar rest should usually still be encoded as:

<mRest/>

This remains true in different meters:

• 2/4
• 3/4
• 4/4
• 3/8
• 6/8
• etc.

The point of <mRest> is precisely that it means “this whole measure is silent”, regardless of how many beats the measure contains. :contentReference[oaicite:3]{index=3}

Use <multiRest> when the source compresses several complete silent measures into a single multiple-rest symbol.

Example:

<layer n="1">
  <multiRest num="9"/>
</layer>

MEI describes <multiRest> as common in performer parts and notes that it is not used in scores because of synchronization problems across staves. :contentReference[oaicite:4]{index=4}

For our project:

• use <multiRest> only when the source actually presents a compressed multi-measure rest
• avoid <multiRest> in score-like encodings
• if consecutive silent measures are shown individually in the source, encode them as separate measures with separate <mRest/> elements

Do not confuse:

• <rest> = actual notated rest event
• <mRest> = actual complete-measure rest
• <mSpace> = explicitly empty measure with no encoded content

Use <mSpace> only when the layer is intentionally empty and this emptiness is itself what needs to be represented. :contentReference[oaicite:5]{index=5}

<measure n="5">
  <staff n="1">
    <layer n="1">
      <rest dur="4"/>
      <note pname="e" oct="4" dur="4"/>
      <note pname="f" oct="4" dur="2"/>
    </layer>
  </staff>
</measure>

<measure n="6">
  <staff n="1">
    <layer n="1">
      <mRest/>
    </layer>
  </staff>
</measure>

<measure n="20">
  <staff n="1">
    <layer n="1">
      <multiRest num="8"/>
    </layer>
  </staff>
</measure>

Ask:

• is this a rest with its own written duration inside the measure? → use <rest>
• is the whole measure silent? → use <mRest>
• are several full silent measures compressed into one sign? → use <multiRest>

In MEI, a <layer> is an independent stream of events on a staff. A staff may contain more than one layer in order to represent multiple voices. The Guidelines explicitly describe layers this way and show that multiple layers on one staff can be used to reflect multiple voices. :contentReference[oaicite:6]{index=6}

A layer is best understood as a single rhythmic and event stream within one staff.

For beginners:

• one staff may have one layer
• one staff may also have two or more layers
• multiple layers are usually used when distinct voices must be represented independently

Use more than one layer when the notation clearly contains multiple independent voices on the same staff.

Typical cases:

• soprano and alto on one staff
• tenor and bass on one staff
• independent rhythms in upper and lower voices
• overlapping note values that cannot be represented cleanly in one single stream
• voice-specific ties, rests, slurs, or cues that belong to different voices

In contrast, do not create extra layers just because stems point in different directions once or twice if the passage is still best understood as one continuous voice. That last point is a local editorial recommendation rather than a strict MEI rule.

At minimum:

• give each layer its own n value
• keep one voice consistently in the same layer as far as possible
• avoid switching the same musical voice back and forth between layers without a good reason

Example:

<staff n="1">
  <layer n="1">
    <note pname="g" oct="4" dur="2"/>
    <note pname="a" oct="4" dur="2"/>
  </layer>
  <layer n="2">
    <rest dur="2"/>
    <note pname="e" oct="4" dur="2"/>
  </layer>
</staff>

Recommended local convention:

• layer n=„1“ = upper voice or primary voice
• layer n=„2“ = lower voice or secondary voice
• keep this convention stable across the corpus
• only add n=„3“, n=„4“, etc. when genuinely required

This is not imposed by MEI itself; it is a local consistency rule.

Shared stems and polyphonic overlap are often visually complex, but the encoding priority should be:

• represent the musical voices clearly
• keep each independent voice in its own layer when needed
• avoid forcing polyphonic notation into one layer if that makes duration or tie logic unclear

A useful practical rule is:

• if two events behave like separate voices, encode them in separate layers
• if the notation is only visually compressed but musically still one stream, keep one layer

This is especially important because some relations are layer-sensitive. For example, the Guidelines state that the scope of the tie attribute is the musical layer: a tie started in one layer may only end in the same layer. :contentReference[oaicite:7]{index=7}

So unstable or inconsistent layer assignment can create problems later.

When deciding whether to split into layers, ask:

1. are there two independent rhythmic streams?
2. are there overlapping note values that imply separate voices?
3. are rests voice-specific?
4. do ties/slurs belong to separate voices?
5. would one-layer encoding become confusing?

If yes to several of these, use multiple layers.

MEI supports figured bass through harmonic indication markup. The key elements are:

• <harm> = the harmonic indication as the attached object
• <fb> = the figured-bass container
• <f> = one individual figure or component inside the figured bass sign :contentReference[oaicite:8]{index=8}

For our corpus, the default pattern should be:

<harm tstamp="1">
  <fb>
    <f>6</f>
  </fb>
</harm>

This means:

• harm provides the attachment point
• fb says this is figured bass / Generalbass
• f holds the visible figure component

The Guidelines state that harm must define a point of attachment using one of these attributes:

• startid
• tstamp
• tstamp.ges
• tstamp.real

The most common attachment methods are startid and tstamp. :contentReference[oaicite:9]{index=9}

For practical work, I recommend:

• use startid when the figure clearly belongs to a specific encoded note or event
• use tstamp when the figure is best attached to a beat position in the measure
• prefer startid when stable note-level linking matters for editorial or computational reuse

<measure n="1">
  <staff n="1">
    <layer n="1">
      <note pname="c" oct="3" dur="1"/>
    </layer>
  </staff>
 
  <harm tstamp="1">
    <fb>
      <f>6</f>
    </fb>
  </harm>
</measure>

<measure n="1">
  <staff n="1">
    <layer n="1">
      <note pname="c" oct="3" dur="1" xml:id="b1"/>
    </layer>
  </staff>
 
  <harm startid="#b1">
    <fb>
      <f>6</f>
      <f>4</f>
    </fb>
  </harm>
</measure>

The Guidelines note that encoding order of f elements is significant. Figures should be encoded in the order they appear, effectively top to bottom on the page. They also note that character order within each f matters for locating accidentals. :contentReference[oaicite:10]{index=10}

So this:

<fb>
  <f>6</f>
  <f>4</f>
</fb>

is not just an arbitrary list; the order carries meaning.

The Guidelines show accidentals encoded directly in the figure content, including the natural sign as a Unicode music natural sign. They also show chromatically altered figures encoded as text inside f. :contentReference[oaicite:11]{index=11}

Example:

<harm tstamp="1">
  <fb>
    <f>7♭</f>
  </fb>
</harm>

For local corpus policy, I recommend the following distinction:

• source-visible figures: encode directly in fb / f
• editorially supplied figures: encode them, but mark editorial responsibility explicitly using MEI editorial mechanisms or clear local documentation
• uncertain readings: record the uncertainty in a way that remains visible in project documentation

The official figured-bass section emphasizes semantic capture over exact visual imitation and also allows links to user-defined symbols via altsym when precise rendition is needed. :contentReference[oaicite:12]{index=12}

Because editorial treatment varies by project, I would write your local policy explicitly, for example:

• supplied figures must be marked as editorial
• uncertain figures must be noted in comments or project documentation
• do not silently normalize ambiguous source notation

• use harm + fb + f as the default structure
• prefer startid for note-bound corpus work when possible
• use tstamp when note-level linking is not practical
• preserve figure order as written
• keep editorial additions explicitly distinguishable from source readings

In CMN, the Guidelines define a tie as a curved line connecting two notes of the same pitch so that the first note sounds for the combined duration of both notes. They say ties can be encoded in different ways, and the simplest method is the tie attribute on note and chord. :contentReference[oaicite:13]{index=13}

Use ties only when:

• the connected notes have the same pitch
• the notation indicates a tie rather than a slur
• the sounding duration is continued across noteheads

The simplest MEI method uses the tie attribute.

Allowed values:

• i = initial
• m = medial
• t = terminal

Example:

<layer n="1">
  <note pname="f" oct="4" dur="2" tie="i"/>
  <note pname="f" oct="4" dur="4" dots="1" tie="t"/>
</layer>

A tie may continue into the following measure.

Example:

<measure n="1">
  <staff n="1">
    <layer n="1">
      <note pname="g" oct="4" dur="2" tie="i"/>
    </layer>
  </staff>
</measure>
 
<measure n="2">
  <staff n="1">
    <layer n="1">
      <note pname="g" oct="4" dur="2" tie="t"/>
    </layer>
  </staff>
</measure>

The Guidelines explicitly state that the tie-terminating event may lie in the following measure. :contentReference[oaicite:14]{index=14}

This point is crucial for corpus consistency:

The scope of the tie attribute is the musical layer. A tie that starts in one layer must end in the same layer. :contentReference[oaicite:15]{index=15}

So for local practice:

• never begin a tie in layer 1 and end it in layer 2
• if the voice continues, keep it in the same layer
• check layer assignment before debugging a “broken” tie

The Guidelines also allow the tie attribute on chord. When used on a chord, it acts as shorthand for multiple ties on all unchanged pitches in the chord. :contentReference[oaicite:16]{index=16}

Example:

<chord dur="4" tie="i">
  <note pname="f" oct="4"/>
  <note pname="a" oct="4"/>
  <note pname="c" oct="5"/>
</chord>
<chord dur="4" tie="t">
  <note pname="f" oct="4"/>
  <note pname="a" oct="4"/>
  <note pname="c" oct="5"/>
</chord>

For our project:

• use tie on note for simple cases
• use tie on chord only when the shorthand is genuinely clear
• if only some notes of a chord are tied, encode ties on the individual note elements instead
• check pitch identity carefully before calling something a tie

Do not confuse:

• tie = same pitch, sustained duration
• slur = phrasing / articulation grouping, usually across different pitches

This distinction matters both musically and computationally.

Before encoding a tie, ask:

• are the connected notes the same pitch?
• is this really a tie, not a slur?
• does the tied continuation stay in the same layer?
• if the notes are in a chord, are all pitches tied or only some?