-
Notifications
You must be signed in to change notification settings - Fork 0
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.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.
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 nestingstaffGrp
.
Status ✅
Exporting from MEI from MuseScore generates MEI IDs (i.e., @xml:id
s). 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
.
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.
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 final
does not exist in MEI, it is exported as doubledbl
barline. - 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
@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.
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.
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.
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.
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.
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"
.
Status ✅
Relevant tests:
Status ✅
Relevant tests:
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)
Status ✅
Relevant tests:
Status ✅
Relevant tests:
Status ✅
Relevant tests:
Status ✅
Relevant tests:
Status ✅
Relevant tests: