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/23 12:31] egorpolyen:mei-friend-compendium [2026/06/03 23:54] (aktuell) – [Generalbass] egorpoly
Zeile 15: Zeile 15:
 ===== Current corpus status ===== ===== Current corpus status =====
  
-tba+[[https://github.com/egorpol/DdT_1_vol_11#current-progress]]
  
 ===== Current corpus assignments ===== ===== Current corpus assignments =====
Zeile 291: Zeile 291:
  
 <code xml> <code xml>
-<harm tstamp="1">+<harm staff="3" tstamp="1">
   <fb>   <fb>
     <f>6</f>     <f>6</f>
Zeile 302: Zeile 302:
   * ''fb'' says this is figured bass / Generalbass   * ''fb'' says this is figured bass / Generalbass
   * ''f'' holds the visible figure component   * ''f'' holds the visible figure component
 +  * ''staff'' identifies the staff the figured bass belongs to
 +  * ''tstamp'' identifies the rhythmic position in the measure
  
 === How do we align figured bass with notes or harmonic events? === === How do we align figured bass with notes or harmonic events? ===
Zeile 313: Zeile 315:
 The most common attachment methods are ''startid'' and ''tstamp''. The most common attachment methods are ''startid'' and ''tstamp''.
  
-For practical work, I recommend:+For practical work in this corpus, I recommend:
  
-  * use ''startid'' when the figure clearly belongs to a specific encoded note or event +  * use ''tstamp'' + ''staff'' as the default encoding for figured bass 
-  * use ''tstamp'' when the figure is best attached to beat position in the measure +  * use fractional timestamps such as ''tstamp="4.5"'' when a figure changes on the second eighth of quarter-note position 
-  * prefer ''startid'' when stable note-level linking matters for editorial or computational reuse+  * avoid mixing ''startid'' and ''tstamp'' in the same local figured-bass passage, because Verovio may render the figures on different vertical baselines 
 +  * use ''startid'' only when a figure must be linked to a specific encoded event and no clean timestamp solution is available
  
 === Example with ''tstamp'' === === Example with ''tstamp'' ===
Zeile 329: Zeile 332:
   </staff>   </staff>
  
-  <harm tstamp="1">+  <harm staff="1" tstamp="1">
     <fb>     <fb>
       <f>6</f>       <f>6</f>
Zeile 337: Zeile 340:
 </code> </code>
  
-=== Example with ''startid'' ===+=== Example with sequential figures under one bass note ===
  
 <code xml> <code xml>
 <measure n="1"> <measure n="1">
-  <staff n="1">+  <staff n="3">
     <layer n="1">     <layer n="1">
-      <note pname="c" oct="3" dur="1" xml:id="b1"/>+      <note pname="b" oct="3" dur="4"/>
     </layer>     </layer>
   </staff>   </staff>
  
-  <harm startid="#b1">+  <harm staff="3" tstamp="4"> 
 +    <fb> 
 +      <f>7</f> 
 +    </fb> 
 +  </harm> 
 +  <harm staff="3" tstamp="4.5">
     <fb>     <fb>
       <f>6</f>       <f>6</f>
-      <f>4</f> 
     </fb>     </fb>
   </harm>   </harm>
 </measure> </measure>
 </code> </code>
 +
 +Use this pattern when the source shows two separate figured-bass signs during one written bass note, for example a quarter note whose harmony moves like two eighths.
 +
 +Do **not** create an extra ''<space>'' only to anchor the second figure. The timestamp is the anchor.
  
 === Ordering of figures === === Ordering of figures ===
  
-The order of ''f'' elements is significant. Figures should be encoded in the order they appear, usually top to bottom on the page.+The order of ''f'' elements is significant. Figures inside the same ''<fb>'' are simultaneous and should be encoded in the order they appear, usually top to bottom on the page.
  
 So this: So this:
Zeile 369: Zeile 380:
 </code> </code>
  
-is not just an arbitrary list; the order carries meaning.+means a stacked figure, not a sequence over time. It is not the same as ''6'' followed later by ''4''
 + 
 +For a time sequence, use separate ''<harm>'' elements with separate timestamps: 
 + 
 +<code xml> 
 +<harm staff="3" tstamp="2"> 
 +  <fb> 
 +    <f>6</f> 
 +  </fb> 
 +</harm> 
 +<harm staff="3" tstamp="2.5"> 
 +  <fb> 
 +    <f>4</f> 
 +  </fb> 
 +</harm> 
 +</code>
  
 === Accidentals in figured bass === === Accidentals in figured bass ===
Zeile 378: Zeile 404:
  
 <code xml> <code xml>
-<harm tstamp="1">+<harm staff="3" tstamp="1">
   <fb>   <fb>
     <f>7♭</f>     <f>7♭</f>
Zeile 388: Zeile 414:
  
   * use ''harm'' + ''fb'' + ''f'' as the default structure   * use ''harm'' + ''fb'' + ''f'' as the default structure
-  * prefer ''startid'' for note-bound corpus work when possible +  * prefer ''staff'' + ''tstamp'' for all figured-bass entries 
-  * use ''tstamp'' when note-level linking is not practical+  * use fractional timestamps for mid-note figure changes 
 +  * use multiple ''<f>'' elements only for simultaneous stacked figures 
 +  * use multiple ''<harm>'' elements for successive figured-bass signs 
 +  * avoid local ''vo'' fixes unless there is no cleaner encoding solution 
 +  * avoid artificial ''<space>'' events used only as figured-bass anchors
   * preserve figure order as written   * preserve figure order as written
   * keep editorial additions explicitly distinguishable from source readings   * keep editorial additions explicitly distinguishable from source readings
- 
 ==== Ties ==== ==== Ties ====
  
Zeile 586: Zeile 615:
   * does the ''facs'' value point to the correct zone id?   * does the ''facs'' value point to the correct zone id?
   * does each measure point to exactly the intended measure zone?   * does each measure point to exactly the intended measure zone?
 +
 +==== Duration encoding: dur vs. dur.ppq ====
 +
 +Please encode written musical duration with ''dur'' and, where needed, ''dots''.
 +
 +''dur'' records the notated value, for example ''dur="4"'' for a quarter note or ''dur="8"'' for an eighth note. ''dur.ppq'' records a calculated playback/timing value in pulses per quarter note. It is not the editorial duration and does not represent the visual notation directly.
 +
 +Local directive:
 +
 +  * use ''dur'' and ''dots'' as the authoritative duration encoding
 +  * do not add ''dur.ppq'' to notes, rests, chords, or spaces
 +  * do not add ''ppq'' to ''staffDef'' or ''scoreDef''
 +  * remove existing ''dur.ppq'' and ''ppq'' values from imported files during cleanup
 +
 +Reason:
 +
 +  * the edition is based on the facsimile and should preserve written notation, not generated timing data
 +  * ''dur.ppq'' is usually import or playback residue and can disagree with the written ''dur''/''dots''
 +  * rhythmic proofreading should check whether the written durations fill the measure
 +
 +Minimal checklist:
 +  * does every timed event have a clear written ''dur'' where required?
 +  * are dotted values encoded with ''dots''?
 +  * have ''dur.ppq'' and ''ppq'' been removed?
 +
 +==== Cross-staff notation ====
 +
 +For cross-staff chords encode it as one logical ''<chord>'' in a single ''<layer>'', and place the low (or high) note on the other staff with ''staff="5"'' (use the number of corresponding staff). The lower (or higher) staff's time is then filled with ''<space/>'' so that the rhythmic alignment remains complete.
 +
 +The MEI guidelines explicitly give this as an alternative for cross-staff chords. Some software handles this method better than separate cross-staff notes connected only by ''stem.with''.
 +
 +Example:
 +
 +<code xml>
 +<staff xml:id="j138ax0t" n="4">
 +  <layer xml:id="lie03m1" n="1">
 +    <chord xml:id="n1v09lce" dur="8" stem.dir="up">
 +      <note xml:id="m11lbwz8" oct="4" pname="f"/>
 +      <note xml:id="ooukl9j" oct="4" pname="d"/>
 +      <note xml:id="dgfh734" oct="3" pname="b" staff="5"/>
 +    </chord>
 +    ...
 +  </layer>
 +</staff>
 +
 +<staff xml:id="k10lc1io" n="5">
 +  <layer n="2">
 +    <space dur="8"/>
 +    <note xml:id="dfj82467" dur="4" oct="3" pname="g" stem.dir="up"/>
 +    <note xml:id="dfj82d467" dur="4" oct="3" pname="a" stem.dir="up"/>
 +  </layer>
 +</staff>
 +</code>
 +
 +For mei-friend / Verovio-style workflows, this second version is often the more robust semantic encoding because it represents one chord rather than two separate events that merely share a stem.
 +
 +Local recommendation:
 +
 +  * use a single ''<chord>'' with note-level ''staff'' when the source clearly shows one chord split across staves
 +  * fill the destination staff's elapsed time with ''<space/>'' when that staff has no independent sounding event at that moment
 +  * keep the written duration on the ''<chord>'' with ''dur''
  • en/mei-friend-compendium.1776947506.txt.gz
  • Zuletzt geändert: 2026/04/23 12:31
  • von egorpoly