en:mei-friend-compendium

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
en:mei-friend-compendium [2026/04/14 05:00] – [Important restriction] egorpolyen:mei-friend-compendium [2026/04/14 13:32] (aktuell) – [Generalbass] egorpoly
Zeile 23: Zeile 23:
 ===== Open bugs ===== ===== Open bugs =====
  
-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!!!+  * mei-friend may create new branches if it cannot properly save work on the **main** branch. 
 +  * **Always check which branch you are saving your work on.**
  
 ==== Requested features / improvements ==== ==== Requested features / improvements ====
Zeile 40: Zeile 41:
   * ''<mSpace>'' = an explicitly empty measure, where no musical content is encoded but nothing is considered missing   * ''<mSpace>'' = an explicitly empty measure, where no musical content is encoded but nothing is considered missing
  
-===== When do we use ''<rest>''? =====+=== When do we use ''<rest>''? ===
  
 Use ''<rest>'' when the source shows a rest with a specific notated duration inside the rhythmic flow of the layer. Use ''<rest>'' when the source shows a rest with a specific notated duration inside the rhythmic flow of the layer.
Zeile 60: Zeile 61:
 </code> </code>
  
-===== When do we use ''<mRest>''? =====+=== When do we use ''<mRest>''? ===
  
 Use ''<mRest/>'' when the layer is silent for the entire measure and the source expresses that as a full-bar rest. 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}+This is the preferred encoding for a complete measure rest because it does not depend on the current meter.
  
 Example: Example:
Zeile 78: Zeile 79:
 </code> </code>
  
-===== Local recommendation =====+=== Local recommendation ===
  
 For our corpus work: For our corpus work:
Zeile 85: Zeile 86:
   * use ''<mRest/>'' when a whole measure is silent in that layer   * 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   * 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"+  * prefer ''<mRest/>'' when the notation is semantically a “whole measure rest”
  
-===== Important restriction =====+=== Important restriction ===
  
-MEI states that it is a semantic error to mix ''<mRest>'' with other events in the same layer.   +A layer containing ''<mRest/>'' should not also contain notes or ordinary rests.   
-So a layer containing ''<mRest/>'' should not also contain notes or ordinary rests. Control events such as fermatas may still occur alongside it.+Control events such as fermatas may still occur alongside it.
  
-===== Full-bar silence in different meters =====+=== Full-bar silence in different meters ===
  
 A full-bar rest should usually still be encoded as: A full-bar rest should usually still be encoded as:
Zeile 108: Zeile 109:
   * etc.   * 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}+The point of ''<mRest>'' is that it means “this whole measure is silent”, regardless of how many beats the measure contains.
  
-===== What about multi-measure rests? =====+=== What about multi-measure rests? ===
  
 Use ''<multiRest>'' when the source compresses several complete silent measures into a single multiple-rest symbol. Use ''<multiRest>'' when the source compresses several complete silent measures into a single multiple-rest symbol.
Zeile 122: Zeile 123:
 </code> </code>
  
-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} +=== Local recommendation for multi-measure rests ===
- +
-===== Local recommendation for multi-measure rests =====+
  
 For our project: For our project:
Zeile 132: Zeile 131:
   * if consecutive silent measures are shown individually in the source, encode them as separate measures with separate ''<mRest/>'' elements   * if consecutive silent measures are shown individually in the source, encode them as separate measures with separate ''<mRest/>'' elements
  
-===== Empty measure vs. rest =====+=== Empty measure vs. rest ===
  
 Do not confuse: Do not confuse:
Zeile 139: Zeile 138:
   * ''<mSpace>'' = explicitly empty measure with no encoded content   * ''<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}+Use ''<mSpace>'' only when the layer is intentionally empty and this emptiness is itself what needs to be represented.
  
-===== Practical examples =====+=== Practical examples ===
  
-===== Example 1: ordinary rest =====+==== Example 1: ordinary rest ====
  
 <code xml> <code xml>
Zeile 157: Zeile 156:
 </code> </code>
  
-===== Example 2: full-bar rest =====+==== Example 2: full-bar rest ====
  
 <code xml> <code xml>
Zeile 169: Zeile 168:
 </code> </code>
  
-===== Example 3: multiple-rest in a part =====+==== Example 3: multiple-rest in a part ====
  
 <code xml> <code xml>
Zeile 181: Zeile 180:
 </code> </code>
  
-===== Project rule of thumb =====+=== Project rule of thumb ===
  
 Ask: Ask:
Zeile 190: Zeile 189:
 ==== Voice handling ==== ==== Voice handling ====
  
-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}+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.
  
-===== What is a layer? =====+=== What is a layer? ===
  
 A layer is best understood as a single rhythmic and event stream within one staff. A layer is best understood as a single rhythmic and event stream within one staff.
Zeile 201: Zeile 200:
   * multiple layers are usually used when distinct voices must be represented independently   * multiple layers are usually used when distinct voices must be represented independently
  
-===== When does one staff need more than one ''<layer>''? =====+=== When does one staff need more than one ''<layer>''? ===
  
 Use more than one layer when the notation clearly contains multiple independent voices on the same staff. Use more than one layer when the notation clearly contains multiple independent voices on the same staff.
Zeile 209: Zeile 208:
   * tenor and bass on one staff   * tenor and bass on one staff
   * independent rhythms in upper and lower voices   * independent rhythms in upper and lower voices
-  * overlapping note values that cannot be represented cleanly in one single stream+  * overlapping note values that cannot be represented cleanly in a single stream
   * voice-specific ties, rests, slurs, or cues that belong to different voices   * 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.+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.
  
-===== How do we distinguish voices clearly? =====+=== How do we distinguish voices clearly? ===
  
 At minimum: At minimum:
Zeile 236: Zeile 235:
 </code> </code>
  
-===== Local project policy for layer numbering =====+=== Local project policy for layer numbering ===
  
 Recommended local convention: Recommended local convention:
Zeile 245: Zeile 244:
   * only add ''n="3"'', ''n="4"'', etc. when genuinely required   * 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 ===
- +
-===== Shared stems and polyphonic overlap =====+
  
 Shared stems and polyphonic overlap are often visually complex, but the encoding priority should be: Shared stems and polyphonic overlap are often visually complex, but the encoding priority should be:
Zeile 259: Zeile 256:
   * if the notation is only visually compressed but musically still one stream, keep one layer   * if the notation is only visually compressed but musically still one stream, keep one layer
  
-===== Why this matters for ties and other relations =====+=== Why this matters for ties and other relations === 
 + 
 +This matters because some relations are layer-sensitive.
  
-This is especially important because some relations are layer-sensitive.   +For example: 
-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}+  * a tie that starts in one layer should also end in that same layer
  
 So unstable or inconsistent layer assignment can create problems later. So unstable or inconsistent layer assignment can create problems later.
  
-===== Recommended workflow =====+=== Recommended workflow ===
  
 When deciding whether to split into layers, ask: When deciding whether to split into layers, ask:
Zeile 273: Zeile 272:
   - are there overlapping note values that imply separate voices?   - are there overlapping note values that imply separate voices?
   - are rests voice-specific?   - are rests voice-specific?
-  - do ties/slurs belong to separate voices?+  - do ties or slurs belong to separate voices?
   - would one-layer encoding become confusing?   - would one-layer encoding become confusing?
  
Zeile 280: Zeile 279:
 ==== Generalbass ==== ==== Generalbass ====
  
-MEI supports figured bass through harmonic indication markup. The key elements are:+MEI supports figured bass through harmonic indication markup. 
 + 
 +The key elements are:
   * ''<harm>'' = the harmonic indication as the attached object   * ''<harm>'' = the harmonic indication as the attached object
   * ''<fb>'' = the figured-bass container   * ''<fb>'' = the figured-bass container
-  * ''<f>'' = one individual figure or component inside the figured bass sign :contentReference[oaicite:8]{index=8}+  * ''<f>'' = one individual figure or component inside the figured bass sign
  
-===== Which elements do we use? =====+=== Which elements do we use? ===
  
 For our corpus, the default pattern should be: For our corpus, the default pattern should be:
Zeile 302: Zeile 303:
   * ''f'' holds the visible figure component   * ''f'' holds the visible figure component
  
-===== How do we align figured bass with notes or harmonic events? =====+=== How do we align figured bass with notes or harmonic events? ===
  
-The Guidelines state that ''harm'' must define a point of attachment using one of these attributes:+''harm'' must define a point of attachment using one of these attributes:
   * ''startid''   * ''startid''
   * ''tstamp''   * ''tstamp''
Zeile 310: Zeile 311:
   * ''tstamp.real''   * ''tstamp.real''
  
-The most common attachment methods are ''startid'' and ''tstamp''. :contentReference[oaicite:9]{index=9}+The most common attachment methods are ''startid'' and ''tstamp''.
  
 For practical work, I recommend: For practical work, I recommend:
Zeile 318: Zeile 319:
   * prefer ''startid'' when stable note-level linking matters for editorial or computational reuse   * prefer ''startid'' when stable note-level linking matters for editorial or computational reuse
  
-===== Example with ''tstamp'' =====+=== Example with ''tstamp'' ===
  
 <code xml> <code xml>
Zeile 336: Zeile 337:
 </code> </code>
  
-===== Example with ''startid'' =====+=== Example with ''startid'' ===
  
 <code xml> <code xml>
Zeile 355: Zeile 356:
 </code> </code>
  
-===== Ordering of figures =====+=== Ordering of figures ===
  
-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}+The order of ''f'' elements is significant. Figures should be encoded in the order they appear, usually top to bottom on the page.
  
 So this: So this:
Zeile 370: Zeile 371:
 is not just an arbitrary list; the order carries meaning. is not just an arbitrary list; the order carries meaning.
  
-===== Accidentals in figured bass =====+=== Accidentals in figured bass ===
  
-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}+Accidentals can be encoded directly in the figure content.
  
 Example: Example:
Zeile 384: Zeile 385:
 </code> </code>
  
-===== Uncertain or editorially supplied figures ===== +=== Recommended local policy ===
- +
-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 +
- +
-===== Recommended local policy =====+
  
   * use ''harm'' + ''fb'' + ''f'' as the default structure   * use ''harm'' + ''fb'' + ''f'' as the default structure
Zeile 409: Zeile 395:
 ==== Ties ==== ==== Ties ====
  
-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}+A tie connects two notes of the same pitch so that the first note sounds for the combined duration of both notes.
  
-===== Basic principle =====+=== Basic principle ===
  
 Use ties only when: Use ties only when:
Zeile 418: Zeile 404:
   * the sounding duration is continued across noteheads   * the sounding duration is continued across noteheads
  
-===== How are ties encoded? =====+=== How are ties encoded? ===
  
 The simplest MEI method uses the ''tie'' attribute. The simplest MEI method uses the ''tie'' attribute.
Zeile 436: Zeile 422:
 </code> </code>
  
-===== Ties across barlines =====+=== Ties across barlines ===
  
 A tie may continue into the following measure. A tie may continue into the following measure.
Zeile 460: Zeile 446:
 </code> </code>
  
-The Guidelines explicitly state that the tie-terminating event may lie in the following measure. :contentReference[oaicite:14]{index=14} +=== Ties and layers ===
- +
-===== Ties and layers =====+
  
 This point is crucial for corpus consistency: 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
-A tie that starts in one layer must end in the same layer. :contentReference[oaicite:15]{index=15}+
  
 So for local practice: So for local practice:
Zeile 475: Zeile 458:
   * check layer assignment before debugging a “broken” tie   * check layer assignment before debugging a “broken” tie
  
-===== Ties on chords =====+=== Ties on chords ===
  
-The Guidelines also allow the ''tie'' attribute on ''chord''.   +The ''tie'' attribute can also be used 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}+ 
 +When used on a chord, it acts as shorthand for multiple ties on all unchanged pitches in the chord.
  
 Example: Example:
Zeile 495: Zeile 479:
 </code> </code>
  
-===== Local recommendation =====+=== Local recommendation ===
  
 For our project: For our project:
Zeile 504: Zeile 488:
   * check pitch identity carefully before calling something a tie   * check pitch identity carefully before calling something a tie
  
-===== Tie vs slur =====+=== Tie vs slur ===
  
 Do not confuse: Do not confuse:
   * tie = same pitch, sustained duration   * tie = same pitch, sustained duration
-  * slur = phrasing / articulation grouping, usually across different pitches+  * slur = phrasing or articulation grouping, usually across different pitches
  
 This distinction matters both musically and computationally. This distinction matters both musically and computationally.
  
-===== Minimal checklist =====+=== Minimal checklist ===
  
 Before encoding a tie, ask: Before encoding a tie, ask:
Zeile 519: Zeile 503:
   * does the tied continuation stay in the same layer?   * does the tied continuation stay in the same layer?
   * if the notes are in a chord, are all pitches tied or only some?   * if the notes are in a chord, are all pitches tied or only some?
- 
  • en/mei-friend-compendium.1776142828.txt.gz
  • Zuletzt geändert: 2026/04/14 05:00
  • von egorpoly