Home
Status ✅
MEI files can be imported from the Open... menu with a selection of *.mei files:
Previously opened MEI files appear in the file list with a dedicated <xml> 🎵 MEI file icon:
The Preferences dialog includes a MEI checkbox option Import MEI layout in the Import section:
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:
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:
Additional lower-level feedback might be provided in the logs
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>- 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.
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.meiConverting and MEI file to MuseScore:
mscore file.mei -o file.msczThe option -f can also be added to by-pass score corruption warnings.
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.thruis determined by the spanning of the first staff, and only for the first level of nestingstaffGrp.
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.
No ID in MEI data imported into MuseScore will be preserved and all IDs will newly generated if the file is re-exported. However, the MuseScore MEI IDs are generated in a deterministic manner. This means that exporting exactly the same file twice from MuseScore will produce two MEI files with identical IDs as long as the content of the file has not changed.
There are two types of generated IDs. The first one are the IDs assigned to durational elements corresponding to MuseScore ChordRest belonging to a Segment in MuseScore. These IDs are track- and time-based and are assigned to MEI chord, note, rest and space elements, however only when these correspond to a ChordRest belonging directly to a Segment. This means that it excludes grace notes, or notes within a chord.
The second type of IDs are counter-based, and the value of the @xml:id is constructed based on the value of multiple counters that are incremented or reset as appropriate during the file export.
Example of a track- and time-based ID (second staff, first layer, time 15 / 2):
<note xml:id="s2l1_t15_2"/>Example of a counter-based ID (first tempo indication in the 14th measure):
<tempo xml:id="m14tp1"/>The main difference between the two types of IDs is that track- and time-based IDs are more stable. For instance, the @xml:id of a rest that is a the fourth quarter note position of the second measure will remain the same when re-exporting the file to MEI even if some notes or rests have been added or removed before it. On the contrary, counter-based IDs are more likely to change. For example, the ID of an element of a certain type (e.g., accid) will change if an element of the same type has been added or removed before it, however only within a limited scope (in the same layer for the accid example) since counter are reset whenever possible.
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:
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.
Status ✅
Transposing information is encoded in [email protected] and [email protected]
Relevant tests:
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 finaldoes not exist in MEI, it is exported as doubledblbarline. - Measure numbers with text (e.g.,
3a) are represented by text elements in MuseScore and are currently not exported.
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:
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:
Status ✅
Relevant tests:
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 .
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:
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
@breaksecis not available in MEI-Basic, these are represented with the@typeattribute. This can be changed if eventually@breaksecis added to MEI-Basic - Feathered beams are not supported.
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-codafor the MuseScore coda variation. -
repeatMark@type="mscore-jump-dc-al-double-codafor 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.
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.
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.
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.