Skip to content
Laurent Pugin edited this page Sep 25, 2023 · 60 revisions

Implementation status for MEI support

Input / output

File opening

Status ✅

MEI files can be imported from the Open... menu with a selection of *.mei files:

image

Previously opened MEI files appear in the file list with a dedicated <xml> 🎵 MEI file icon:

image

The Preferences dialog includes a MEI checkbox option Import MEI layout in the Import section:

image

File saving

Status ✅

MEI files can be saved through the Export... menu that includes an MEI section. The MEI section includes an option Include page and system breaks as well as the standard part extraction option:

image

User feedback

Status ✅

When possible, some feedback is provided when features cannot be imported. The feedback is shown in dialog that allows for the process to be continued if desirable:

image

Additional lower-level feedback might be provided in the logs

Metadata

Status ⚠️

The following metadata tags from the score properties are exported to the MEI header:

  • Work title
  • Arranger
  • Composer
  • Copyright
  • Lyricist
  • Translator
<meiHead>
    <fileDesc>
        <titleStmt>
            <title>Work title</title>
            <respStmt>
                <persName role="arranger">Arranger is me</persName>
                <persName role="composer">Composer is me</persName>
                <persName role="lyricist">Another lyricist</persName>
                <persName role="translator">Deepl</persName>
            </respStmt>
        </titleStmt>
        <pubStmt>
            <date isodate="2023-05-09-14:34:46" />
            <availability>
                <distributor>CC-By</distributor>
            </availability>
        </pubStmt>
    </fileDesc>
</meiHead>

⚠️ The following tags are currently not preserved since no obvious place in MEI-Basic has been found:

  • Creation date
  • Platform
  • Source

When importing and MEI file, the values in the MEI header (if found) as set back as score properties. The entire MEI header is also preserved. When exporting again to MEI, the original header is re-exported as such and the score properties are ignored. However, the original MEI header can be deleted from the score properties dialog.

Command-line

Status ✅

The conversion from and to MEI through the MuseScore is possible with standard MuseScore command-line options.

For example, converting a MuseScore file to MEI:

mscore file.mscz -o file.mei

Converting and MEI file to MuseScore:

mscore file.mei -o file.mscz

The option -f can also be added to by-pass score corruption warnings.

Core features

General score structure

Status ✅

The score structure is encoded in the top-level scoreDef that is the first child of score.

Since there is not direct mapping of part structure from MuseScore within the MEI scoreDef, the part structure is preserved through label and labelAbbr within staffGrp or staffDef elements.

Bracket supported are bracket, brace, bracketsq and line.

Relevant tests:

Known limitations:

  • Bar line spanning in MuseScore is defined on a staff level. In MEI, this is defined through [email protected]. The current implementation, the value for @bar.thru is determined by the spanning of the first staff, and only for the first level of nesting staffGrp.

XML IDs

Status ✅

Exporting from MEI from MuseScore generates MEI IDs (i.e., @xml:ids). These are used for internal referencing (e.g., the @startid on a dynam referencing the chord it is attached to), but they can also be used for referencing MEI elements externally.

The MEI IDs are randomly generated. This means that exporting a file twice will have different MEI IDs. However, it is possible to seed the random generator with a value to be given in a xml:id property in the MuseScore metatag properties. When exporting to MEI, the value in the metatag is set as the @xml:id of the root mei element. It is preserved at import too, meaning the the mei@xml:id is set as xml:id metatag property in the imported MuseScore file.

Some elements that do not have a corresponding MuseScore object have no @xml:id. These are:

  • accid
  • beam
  • gracegrp
  • syl
  • verse

It is also the case for scoreDef and its content as well as section, staff, layer.

Re-importing MEI data

When no mei@xml:id is given in the imported data, IDs in MEI data imported into MuseScore will be preserved, however only in memory and not in the MuseScore files. This means that they will be preserved only if the MEI file is re-exported straight away. All IDs will newly generated if the file is closed, re-open and then re-exported.

Modifying the data (e.g., changing the pitch of a note) will not modify the ID for the note. If some of the data is copied (e.g., the content of a measure), the copied data will be attribute new random IDs at export.

If a mei@xml:id is given in the imported data, the value will be used to seed the random generator and IDs will be regenerated. Having modified the data (e.g., changed the pitch of a note) will not impact the MEI IDs, which will remain the same. However, if some elements are inserted or deleted, that will modify the IDs in the resulting MEI file.

Layout option

Status ✅

The layout option in the export dialog and the import preferences (see above) triggers writing and reading pb and sb elements.

When writing, all page and line (system) breaks are encoded into the MEI. The ones manually entered in MuseScore have a @type="mscore-manual".

When reading the MEI, only pb and sb with @type="mscore-manual are set as page and line breaks and all the others are ignored.

Relevant tests:

Title frame (page head)

Status ✅

The top (first) text frame in MuseScore is encoded as pgHead. Text elements are placed and size according to their type:

  • Title: top-center, size x-large
  • Subtitle: top-center, size large
  • Composer: bottom-right, size normal
  • Poet (lyricist): bottom-left, size normal
  • Instrument excerpt: top-left, size normal

The pgHead is organized in <rend> elements (up to 9) representing positions aligned with @halign and @valign. Each text element is encoded in its own <rend> with the desired @fontsize. The type of the text element is encoded in @type. For example:

<pgHead>
   <rend halign="center" valign="top">
      <rend type="title" fontsize="x-large">Ach Gott und Herr</rend>
   </rend>
</pgHead>

Text element on multiple lines is supported will be encoded as mixed content and lb.

Known limitations:

  • Text formatting (i.e., italic, bold, etc.) within a text element is currently not preserved.

Transposing information

Status ✅

Transposing information is encoded in [email protected] and [email protected]

Relevant tests:

Measure numbering

Status ✅

Measure number in MuseScore are integers automatically incremented. They are encoded in measure@n. When a measure is excluded from the measure count in MuseScore, no @n is provided.

Irregular (e.g., a pickup measure) will be have a measure@metcon="false".

MuseScore also has the option of adding a number to the measure count. The value is taken into account when writing and reading measure@n.

For end barlines with a repetition, the number of sounding repetitions given in MuseScore is encoded as @type="mscore-repeat-n where n is the value of the repeat parameter in MuseScore.

Relevant tests:

Known limitations:

  • The MuseScore barline type Reverse final does not exist in MEI, it is exported as double dbl barline.
  • Measure numbers with text (e.g., 3a) are represented by text elements in MuseScore and are currently not exported.

Time signatures

Status ✅

Time signature changes occurring at all staves are encoded in a scoreDef change. When the time signature change is not the same on all staves, or is occurring only on some staves, a scoreDef with appropriate staffDef descendants is generated.

Relevant tests:

Key signature

Status ✅

Key signature changes work as time signature. That is, there are encoded in a scoreDef when the same for all staves or in staffDef when not.

Relevant tests:

Clefs

Status ✅

Relevant tests:

Notes and rests

Status ✅

Supported chord, note and rest durations range from long to 512th. Chords with different note durations are not supported.

Stem direction are encoded in @stem.dir. When the stem direction is set for notes within a beam, then all notes have a @stem.dir. (This could eventually be changed to beam@place if it is added to MEI-Basic.)

Stemless notes are encoded with @stem.len="0". (This could eventually be changed to @stem.visible if it is added to MEI-Basic.)

Cross-staff notation is encoded with @staff and the appropriate staff number value. It is supported for chord, note and rest. The staff displacement is constrained to one staff above or below since it seems there is not reason to allow for more than that.

Relevant tests:

Known limitations:

  • Enclosing accidentals are not supported (not available in MEI-Basic).
  • Triple flats / sharp are not preserved in the import.
  • Cross-staff for chords with only some one or some of the notes on the staff above or the staff below is not supported since this can only be achieved with a workaround in MuseScore .

Grace notes

Status ✅

Grace notes are encoded as graceGrp with the appropriate @attach and @grace. Preceding grace notes are encoded with @attach="pre", and ending (i.e., following) grace notes with @attach="post". For preceding grace notes, the acciaccature will have a @grace="unacc" and appogiature @grace="acc". For ending grace notes, the value is @grace="unknown". The grace groups will contain chord, note and beam. Note duration are encoded as standard MEI duration in @dur.

For wider compatibility, MEI import also supports grace notes encoded without being wrapped within a graceGrp. One limitation of this approach is that ending grace notes are not supported. The grace notes will always be attached to the following chord or note, or ignored if appearing at the end of a measure.

Relevant tests:

Tuplets and beaming

Status ✅

Tuplets are encoding with tuplet elements with corresponding @num and @numbase. Bracket and number styles and tuplet placement are encoded in @num.place, @num.visible, @num.format, @bracket.place, @bracket.visible.

Beams automatically calculated in MuseScore are exported as beam elements. However, these are not reimported as such. During the import, beam are ignored and beaming is performed by the MuseScore beaming algorithm.

Beam modes in MuseScore (e.g., forcing the start of a new beam, or joining beams) are exported as @type attributes as follow:

  • Beam start as beam@type="mscore-begin"
  • Beam middle (joining of a beams) as note|rest|chord@type="mscore-beam-mid"
  • No beam as note|rest|chord@type="mscore-beam-none"
  • 16th sub beam as note|rest|chord@type="mscore-beam-begin16"
  • 32nd sub beam as note|rest|chord@type="mscore-beam-begin32"

Relevant tests:

Known limitations:

  • Nested tuplets (tuplet within tuplet) are not supported.
  • Since @breaksec is not available in MEI-Basic, these are represented with the @type attribute. This can be changed if eventually @breaksec is added to MEI-Basic
  • Feathered beams are not supported.

Ending and repeat signs (jumps such as D.S. or D.C.)

Status ✅

Voltas are encoded with ending elements. The text of the volta is encoded in @label. Open voltas will have a @lendsym="none". The styling of the line is encoded in @lform with dashed and dotted possible values.

Sound processing parameters of the voltas are encoded with @type, with the repeat list encoded with one attribute value for each entry in the list. Namely mscore-repeat-1 mscore-repeat-3 for a list value 1,3 in MusesScore.

Jump and marker elements are encoded with repeatMark. The @func stores the type for Marker (coda, segno and fine) and Jump (dalsegno and dacapo).

An additional @type attribute is used to encoded the specific MuseScore type. For example:

  • repeatMark@type="mscore-marker-varied-coda for the MuseScore coda variation.
  • repeatMark@type="mscore-jump-dc-al-double-coda for the MuseScore jump D.C. al Double Coda.

Relevant tests:

Known limitations:

  • For Jump, values for jumpTo, playUntil and continueAt are not exported and default values are assume during import. Similarly, the default value for label is used for Marker during import.
  • Import uses default values for the text content for both Jump and Marker.

Tempo markings

Status ✅

Tempo indications are encoded with tempo control events within the corresponding measure. They are attached to a note, chord or rest.

The text of the tempo indication is encoded as text withing the tempo element. This can be mixed content (text mixed with additional elements) with rend or lb elements for representing SMuFL characters, or line breaks, respectively. For the SMuFL characters, the @glyph.auth="smufl" is set on the rend that wraps them.

The tempo value is encoded as @midi.bpm. And additional @type="mscore-infer-from-text" is added for indication for which MuseScore is expected to infer the tempo value from the text.

Relevant tests:

Known limitations:

  • Spanning tempo indications (e.g., ritardando) are currently not supported.

Dynamics (ff, s.p, sfz etc.)

Status ✅

Dynamics are encoded with dynam control events within the corresponding measure. Coded dynamics in MuseScore are encoded as text, such as pp. Dynamics with mixed text and coded dynamics, such as sempre pp or molto ff, are also supported.

In addition to the text, the dynamic code is encoded in @label. Multi-line dynamics is also supported.

Import of dynamic encoded with @tstamp attribute is also supported, even though these will not be preserved. Only dynamics for which a chord, note, or rest corresponding to the @tstamp can be found will be imported.

Relevant tests:

Known limitations:

  • Text formatting (i.e., italic, bold, etc.) within a text element is currently not preserved.

Fermata and breath

Status ✅

Fermata are encoded with fermata control events within the corresponding measure. They are attached to a note, chord or rest with @startid. Fermata attached to the end bar line of a measure are a special case and are encoded with the appropriate @staff and @tstamp and not with @startid.

Import of fermata encoded with @tstamp attribute is also supported, even though these will not be preserved. Only dynamics for which a chord, note, or rest corresponding to the @tstamp can be found will be imported. There is one exception for fermata with a @tstamp pointing to the end of the measure. These will be imported as a fermata attached to the end bar line.

For fermata with a custom shape, the MEI @shape attribute is used, i.e., for angular and square fermatas. Otherwise, @glpyh.auth and @glyph.name is used.

Breath are also encoded with a control event within the corresponding measure. However, the MEI element is breath or caesura, as appropriate. The @glyph.auth and glyph.name is encoded when the breath or caesura is not the common one.

Import with @tstamp encoded breath and caesura works as long as as corresponding element can be found.

Import of fermata, breath and caesura with glyph.num is also supported.

Relevant tests:

Known limitations:

  • The vertical position of a breath and caesura is different (lower) after import.

Chord labels and roman numerals

Status ✅

Chord labels and roman numerals in MuseScore are encoded with harm. In the export, the plain text (as entered by the user) is encoded as text content of the harm, with no formatting. When importing, the text is re-processed by MuseScore.

For distinguishing between chord labels and roman numerals, a harm@type attribute is used with mscore-roman for roman numerals.

Relevant tests:

Known limitations:

  • Chord labels or roman numerals attached to a voice for which there is no note or rest are ignored.

Additional text directives

Status ✅

MuseScore has different types of text directives, which are encoded with dir using @startid. The following MuseScore types of directives are exported as dir:

  • Expression
  • Playtech annotation
  • Staff text

The distinction of the type of directive is encoded in the dir@type attribute. The default is given to expressions, and others have the following values:

  • mscore-playtech-annotation
  • mscore-staff-text

The style (normal or italic) and the position (above or below) is inferred from the type. A custom position in MuseScore is encoded in @place.

Relevant tests:

Known limitations:

  • Text formatting within the directive is ignored.

Slurs and ties

Status ✅

Slurs are encoded with slur, and ties with tie, both using @startid and @endid.

The placement of the slurs or ties is encoded with @curvedir, and the style with @lform.

Relevant tests:

Known limitations:

  • The is no distinction in the export between dashed and wide-dashed slur and both are exported with @lform="dashed".

Additional features

Ottava lines

Status ✅

Relevant tests:

Hairpins

Status ✅

Relevant tests:

Lyrics

Status ✅

Relevant tests:

Known limitations:

  • Any SMuFL character within a lyric is considered to be an elision character
  • Elision character is always SMuFL character lyricsElision (U+E551)

Figure bass

Status ✅

Relevant tests:

Note articulation (stacc.)

Status ✅

Relevant tests:

Ornaments such as mordents and turns

Status ✅

Relevant tests:

Arpeggios

Status ✅

Relevant tests:

Piano pedal marks

Status ✅

Relevant tests:

Clone this wiki locally