From 639989473320fe7b92dc999d44cd069d0499d89f Mon Sep 17 00:00:00 2001 From: musicEnfanthen Date: Sat, 20 Jan 2024 00:03:35 +0100 Subject: [PATCH] fix(schema): add version number to canonicalized source --- ....xml => mei-source_canonicalized_v5.0.xml} | 0 dev/mei-source_canonicalized.xml | 43401 ---------------- 2 files changed, 43401 deletions(-) rename 5.0/{mei-source_canonicalized.xml => mei-source_canonicalized_v5.0.xml} (100%) delete mode 100644 dev/mei-source_canonicalized.xml diff --git a/5.0/mei-source_canonicalized.xml b/5.0/mei-source_canonicalized_v5.0.xml similarity index 100% rename from 5.0/mei-source_canonicalized.xml rename to 5.0/mei-source_canonicalized_v5.0.xml diff --git a/dev/mei-source_canonicalized.xml b/dev/mei-source_canonicalized.xml deleted file mode 100644 index f7730a7..0000000 --- a/dev/mei-source_canonicalized.xml +++ /dev/null @@ -1,43401 +0,0 @@ - - - - - - - - - - - The Music Encoding Initiative Guidelines - - Edited by - Johannes Kepper - Perry D. Roland - - - With contributions by - Benjamin W. Bohl - Andrew Hankinson - Maja Hartwig - Zoltán Kőmíves - Laurent Pugin - Kristina Richts - Axel Teich Geertinger - Raffaele Viglianti - Thomas Weber - Klaus Rettinghaus - Sophia Dörner - - Benjamin W. Bohl - BruxDDay - dinamix - Norbert Dubowy - Ichiro Fujinaga - Axel Geertinger - Andrew Hankinson - irmlindcapelle - franz kelnreiter - kepper - Zoltan Komives - DDMAL LabManager - Urs Liska - Elsa De Luca - Néstor Nápoles López - MajaHartwig - Stefan Münnich - pe-ro - Laurent Pugin - Juliette Regimbal - Klaus Rettinghaus - Agnes Seipelt - Martha E. Thomae - Raffaele Viglianti - Gabriel Vigliensoni - Thomas Weber - David M. Weigl - - - - Development Version - - - Music Encoding Initiative (MEI) Council - -

- Music Encoding Initiative (MEI) -

-

NOTICE: Copyright (c) 2017–2023 by the Music Encoding Initiative (MEI) Council.

-

Licensed under the Educational Community License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain a copy of the - License at http://opensource.org/licenses/ECL-2.0.

-

Unless required by applicable law or agreed to in writing, software distributed under - the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the specific language governing - permissions and limitations under the License.

-

This is a derivative work based on earlier versions of the schema copyright (c) - 2001-2006 Perry Roland and the Rector and Visitors of the University of Virginia; - licensed under the Educational Community License version 1.0.

-

CONTACT: contact@music-encoding.org

- - - -

- - - - - - -

- Introduction to MEI -

Welcome to the MEI Guidelines. They provide documentation for the Music Encoding - Initiative’s framework for describing music notation documents. This includes both a - technical specification of the XML-based implementation of MEI and an explanatory - description of its concepts.

-
- About these Guidelines -

The MEI Guidelines are intended to serve as a reference tool for music encoders. - Through the use of natural-language definitions and examples, this documentation - assists users of MEI in achieving effective and consistent markup. Despite - translating XML and RNG terminology and concepts into more accessible language, it is - still a technical one that presupposes a minimal understanding of XML and music - notation. Novice encoders may want to start their MEI experience by doing an introductory - tutorial first. These Guidelines will provide recommendations and arguments - for encoding different types of music notation for a variety of purposes. While the - specification of the framework is complete, the description is not necessarily - complete. MEI is used in various contexts, and not every use-case may be fully - reflected in these Guidelines. However, MEI is a community effort, so feedback and - suggestions for improvement are highly welcome. Several starting points to get in - touch with the MEI community can be found on the MEI - website.

-

These Guidelines make use of real-world examples to illustrate appropriate encoding - concepts. We consider the use of such images as fair use. Contributors to these - Guidelines are requested to given proper reference to the libraries holding the - material used here. They're also asked to be aware of potential copyright - infringements and avoid respective material, or replace it with hand-drawn, made-up - examples. If you find material that possibly offends copyright, please get in touch with us, and we will - take it down.

-
- Acknowledgments -

Many institutions and individuals assisted in the preparation of these - Guidelines and in the overall development of the Music Encoding Initiative - framework and community.

-

Grateful acknowledgment is given to the following institutions for their - generous contributions: the Akademie der Wissenschaften und der Literatur (AdW) - in Mainz for serving as hosting institution for the MEI Community, and the - National Endowment for the Humanities (NEH) and the Deutsche - Forschungsgemeinschaft (DFG) for their joint financial support of the MEI - project in its early stages. We thank several institutions that hosted Music - Encoding Conferences or other MEI-related meetings in the past: The AdW Mainz, - the University of Virginia Library, the Biblioteca Umanistica of the - Università degli Studi Firenze, McGill University Montréal, the Centre - d’études supérieures de la Renaissance Tours, the Maryland Institute for - Technology in the Humanities (MITH) in College Park, the Oxford e-Research - Centre, the Universität Paderborn and the Österreichische Akademie der - Wissenschaften Wien in conjunction with the Universität Wien and the Mozarteum - Salzburg. We also thank all other institutions that allow their researchers to - invest time into both the community and the encoding framework. It is their - interest that makes MEI an incredible platform for interchange and scholarly - progress.

-

The Text Encoding Initiative is also owed a special debt of gratitude. In - addition to providing much of the inspiration for MEI, the TEI organization - supplied funding for the MEI Technical Group in its efforts to adopt ODD. The - editors of these Guidelines are grateful for those of the TEI, which provided a - stellar exemplar and from which we have borrowed shamelessly.

-

MEI has been a community-driven effort for more than a decade, and many - individuals have provided significant and much-appreciated commitments of time - and energy to the development of MEI: Nikolaos Beer; Vincent Besson; Benjamin - W. Bohl; Margrethe Bue; Donald Byrd; Irmlind Capelle; Tim Crawford; David A. - Day; Giuliano Di Bacco; Norbert Dubowy; Richard Freedman; Ichiro Fujinaga; - Andrew Hankinson; Maja Hartwig; Kristin Herold; Franz Kelnreiter; Johannes - Kepper; Robert Klugseder; Zoltán Kőmíves; David Lewis; Urs Liska; Elsa De Luca; - Erin Mayhood; Stefan Morent; Stefan Münnich; Markus Neuwirth; Kevin Page; - Daniel Pitti; Laurent Pugin; Klaus Rettinghaus; Kristina Richts; Daniel - Röwenstrunk; Perry Roland; Craig Sapp; Agnes Seipelt; Eleanor Selfridge-Field; - Christine Siegert; Peter Stadler; Axel Teich Geertinger; Martha Thomae; Joachim - Veit; Raffaele Viglianti; Thomas Weber; and Sonia Wronkowska.

-

Thanks to Bernhard R. Appel; Richard Chesser; Morgan Cundiff; J. Stephen - Downie; Oliver Huck; Fotis Jannidis; John Rink; Federica Riva; Frans Wiering - and Barbara Wiermann for providing expertise on a wide range of topics related - to music notation modelling.

-

Also thanks to Syd Bauman, Terry Catapano, and Sebastian Rahtz for their - invaluable problem-solving assistance during the development of the 2010 RNG - schema. Thanks to Sebastian Rahtz and James Cummings of the Text Encoding - Initiative (TEI) for their help with making ODD work with MEI, their assistance - in more closely aligning MEI and TEI, and their quick responses to questions - and Roma bug reports.

-

Finally, the members of the Music Encoding Initiative would like to thank Perry - Roland for his foresight, engagement and dedication in laying the foundations - of this initiative.

-
-
- About version 5.0 -

Release 5.0 of MEI focuses primarily on the guidelines, development infrastructure, - and consistency, with only limited changes to the specifications. Perhaps the most important - additions are the introduction of the MEI Basic customization, and the availability - of an auto-generated PDF version of the Guidelines (see below for more details on both). - The Release Managers for MEI 5.0 were the Technical Co-Chairs, Benjamin W. Bohl and Stefan - Münnich. -

-
- MEI Basic -

As a framework to encode music, MEI offers extensive flexibility to encode music - documents of various kinds, and for a wide variety of uses. For scholarly research, - this flexibility is necessary and is one of the greatest strengths of MEI. At the - same time, we recognize that this flexibility presents challenges for broad adoption - of MEI as a notation interchange format. For developers, providing "full" MEI support - is a difficult and time-consuming chore, writing and supporting code for features - which most of their users will not use. Accordingly, MEI has not seen a great deal of adoption - by current score-writing applications.

-

This is addressed this with the release of MEI 5. We are now offering a new customization of MEI, - MEI Basic, that provides a simplified subset of the MEI framework that - reflects the capabilities of most popular "Common Western Music Notation" score-writing - applications currently in use.

-

In the full MEI schema there are often multiple ways to encode something. MEI Basic - simplifies this by providing only one approach for each music feature, making it significantly - easier to provide full feature support in software. As noted, MEI Basic only supports - Common Western Music Notation. Many of the more complex encoding mechanisms for - editorial and analytical workflows are also removed in MEI Basic. MEI Basic has a relatively - small footprint of supported features, which may be expanded over time as more software - applications adopt MEI and more use cases are identified. All MEI Basic files are - valid MEI "full" files, meaning MEI Basic files may be expanded and upgraded to MEI "full", - adding more complex features and encoding mechanisms as required.

-

We hope that this customization facilitates more application adoption, data sharing between - MEI projects, and conversion between MEI and other data formats.

-
-
- Guidelines -

With MEI 5, we re-introduce a PDF version of the MEI Guidelines. With a total - of more than 5,700 pages, this PDF clearly is not intended to be printed, but may - serve as a single-file reference to the current release of MEI. The PDF is - interactive, so may be offline with working links between sections. While the - largest part of the PDF is taken up by the formal specification of the format, - there are also more than 370 pages of prose documentation and examples of how to - use the MEI framework for various purposes. The PDF therefore gives a good - impression of the huge effort that went into the development of MEI.

-

The Guidelines have also had several notable contributions, led in large part - by our Interest Groups. These contributions have sought to make some chapters more - clear and consistent, to help newcomers to MEI understand how MEI encoding may be - applied.

-

In total, we have over 40 contributors actively involved in - the preparation of this release of MEI. Many of them are early-career researchers, - investing significant time and effort into the MEI Framework. Due to the open - nature of this community work, happening alongside conferences, workshops, and - other meetings, others may not be listed properly because of rather informal, - but no less important, contributions. Without the joint effort of all those involved, - an undertaking like MEI would not be possible.

-
-
- Model changes in MEI -

MEI 5 introduces five new elements: plica and - stem, for the encoding of documents written in Mensural - notation, and divLine for Neumes documents. The new CMN - element repeatMark can be used to express repetition marks - as a combination of text and symbols, and the added shared element - extData provides a container for non-MEI data formats. - The release technically removes the <fingerprint> element, which has been - deprecated for ten years. It also removes the elements <pgHead2> and - <pgFoot2>, which are now superseded by the func attribute on - pgHead and pgFoot respectively.

-

Most other changes affect more specific aspects in the model of MEI, usually - expressed in attributes. These include the refinement of the encoding of key - signatures, with key.sig moved to keysig, keysig.show moved to - keysig.visible, and keysig.showchange and sig.showchange moved to - keysig.cancelaccid and cancelaccid respectively. The instr - attribute is removed from quiet events like rest, - mRest, mSpace and multiRest, - and the visible attribute is also removed from mRest. - Moreover, attributes line.form and line.width on the arpeg - element are aligned with other line-like elements as lform and - lwidth. text.dist on scoreDef and - staffDef is removed in favor of the newly added attributes - dir.dist, reh.dist or tempo.dist. - meter.form="invis" is updated to meter.visible="false", - and the same change applies to form="invis" on meterSig, now replaced - with visible="false". The text-rendition values of letter-spacing - and line-height on rend are moved to separate attributes, that is, - rend="letter-spacing(0.25) line-height(120%)" will be now - letterspacing="0.25" lineheight="120%". Additionally, corrections - are applied to specific attribute values, such as changing Bagpipe on - midi.instrname to Bag_pipe and replacing dblwhole - on head.mod with fences. All changes can be traced in the - detailed Release Notes auto-generated from the Pull Requests on GitHub. A larger - group of changes affects the internal class structure of MEI only, where significant - effort went into improved consistency in naming things. While this set of changes - does not affect end users of MEI during validation of files, they may have - consequences for local customizations which reference classes not available anymore. - If you have advanced local customizations based on MEI v4 or older releases, - please check that the rules provided still work as expected under v5. A very helpful - addition for this task may be the validation for MEI customizations, which is now - available and used for all customizations officially provided by MEI.

-
-
- Infrastructural changes -

A lot of effort went into updating the infrastructure for generating releases. These - changes are designed to help improve the development workflow of MEI, improving consistency - and oversight of changes as they are contributed to MEI. Our new setup is explained in - great detail in the project README file. - We have also expanded our Contribution Guidelines - and other documentation files in the music-encoding GitHub repository.

-

The MEI documentation and guidelines are now expressed in TEI ODD again, - moving away from the MarkDown-based approach used in the preparation of - MEI v4 documentation. This re-introduces greater compatibility with the TEI toolset. - The source code for both the Guidelines and the Specification is now jointly - contained in the music-encoding GitHub repository, - which simplifies validation across both parts of MEI. All assets – web - documentation, PDF Guidelines, and schemata – are automatically generated from there. - A multi-platform Docker image for running these processes locally is also provided - to help new developers with getting started in contributing to MEI. - Setting up these technical workflows has taken considerable effort, but should now - simplify future development and releases considerably.

-

In addition to the main Music Encoding schema and Guidelines, we have also updated - our Sample Encodings and Encoding Tools repositories. Sample Encodings have been updated - to MEI 5.0, and several problems with encodings from older releases have been fixed. In the - Encoding Tools, several bugs were fixed with older upgrade XSLT scripts, and a new XSLT for - upgrading MEI 4 to MEI 5 was added.

-

To see all of the changes made for this revision, please visit our Git repositories: - - https://github.com/music-encoding/music-encoding - https://github.com/music-encoding/sample-encodings - https://github.com/music-encoding/encoding-tools - -

-

The editors wish to thank everyone who participated in this process. Of course, - errors and omissions are the sole responsibility of the editors.

-
-
-
-
- MEI Design Principles -

This section of the Guidelines defines principles and criteria for designing, - developing, and maintaining an XML-based encoding scheme for music notation - documents.

-
- Definitions and Parameters -

A music notation document is one that contains music notation; that is, any - one of a number of "visual analogues of musical sound, either as a record of - sound heard or imagined, or as a set of visual instructions for performers." - (Ian D. Bent, et al. "Notation." Grove Music Online. Oxford Music Online. 25 - May 2010. http://www.oxfordmusiconline.com/subscriber/article/grove/music/20114.) - However, MEI’s understanding is more inclusive than this restrictive - definition, i.e., Braille certainly qualifies as music notation - documents.

-

The encoding scheme permits both the creation of new music notation - documents and the conversion of existing ones from print and other - electronic formats. However, conversion of existing documents may require - revisions in content or rearrangement of information.

-
-
- General Principles -

MEI may be used to encode both primary sources of music notation, such as an - autograph or published score, and secondary sources, such as a scholarly - edition based on one or more primary sources. The format encompasses both - use cases, and the encoder must choose the elements and attributes most - appropriate in each case. These Guidelines aim to provide guidance on that - task.

-

As an encoded representation of one or more music notation documents, an MEI - file may be employed as a surrogate for the original materials.

-

Although the encoding scheme does not define or prescribe intellectual - content for music notation documents, it does define content designation and - is intended to be used with available data content standards. MEI identifies - the essential data elements within music notation documents and establishes - codes and conventions necessary for capturing and distinguishing information - within those elements for future action or manipulation. While there are a - few elements that ought to appear in any MEI document, various intellectual, - technical, and economic factors influence the level of detail of analysis - and encoding actually undertaken. Taking this into consideration, the - encoding scheme is designed with a minimum of required elements and allows - for progressively more detailed levels of description as desired.

-

The encoding scheme preserves and enhances the current functionality of - existing music notation documents. It permits identification of document - structures and content that support description, navigation, analysis, and - online and print presentation.

-

The encoding scheme is intended to facilitate interchange between notational - tools. It aims to assist in the creation of more effective and consistent - encoding, encourage the creation of cooperatively-created and widely - available databases of music notation documents, and permit the reuse of - encoded data for multiple output purposes. It will also ensure that - machine-readable music notation documents will outlive changing hardware and - software environments because they are based on a platform-independent - standard.

-
-
- Structural Features -

The encoding scheme is based on eXtensible Markup Language (XML), a - text-based format for representing structured information. It is expressed - as a One Document Does-it-all (ODD) document. For more information on ODD, please refer to .

-

Related or complementary standards, such as the Text Encoding Initiative (TEI) Guidelines for Electronic Text Encoding and Interchange, the Encoded Archival Description (EAD), MARC 21 Format for Bibliographic Data, existing notation encoding schemes, etc. have been consulted and employed as appropriate. For example, the data - model includes a header that is comparable to the TEI header, and TEI and - EAD naming conventions and tag structures have been used whenever feasible. - However, while some feature names are similar, or even the same, it is - important to recognize that MEI and TEI have different semantic scope. - Obviously, a note element in MEI does not carry the same meaning as the - element of the same name in TEI. Perhaps less obviously, a phrase in music - notation is unrelated to a textual phrase.

-

With respect to metadata, MEI recognizes the close relationship between the - metadata content found in the MEI header and that of catalog records, - authority records, and finding aids. Therefore MEI provides ways of - indicating in the encoding the corresponding fields of other metadata - standards.

-

To ensure broad international and multi-repertoire application of MEI, - existing musical terminology was used in building the data model where - practical. When appropriate, a more neutral terminology was used to - facilitate sharing of concepts and thus stressing the commonalities between - different repertoires. Finally, extensive use of attributes and - clearly-defined classification mechanisms in the schema permits the - refinement of element meanings within specific musical, geographic, or - temporal contexts.

-
-
- Control and Maintenance -

The Music Encoding Initiative Community has given itself By-laws, which regulate all essential properties and procedures. - The community elects a Board, - which in turn governs and represents the community. The Board consists of - nine elected members, with three seats standing for election for three year - terms each year. Everyone registered to the MEI-L mailing list is eligible to vote for the Board.

-

In addition to the Board, there is a Technical Team, which is open for anyone interested to work on the - maintenance and improvement of MEI itself. The Technical team will assist - Interest Groups and other interested community members in an advisory - capacity on how to further develop MEI for both existing and new fields of - application.

-
-
-
- Basic Concepts of MEI -

This chapter is intended to explain basic concepts of MEI, like events vs. - controlevents.

-
- Musical Domains -

The term "music" has many different notions, ranging from audible sounds over - written performance instructions or transcriptions of such events to conceptual - rulesets that establish different theories of what music is, and what is - allowed in music. In 1965, Milton Babbitt distinguished between graphemic, acoustic and auditory aspects of music (Babbitt, Milton: The Use of Computers in Musicological Research, in: Perspectives of New Music 3/2 (1965), p. 76).

-

Various music encoding formats took up this distinction, most notably SMDL, the - Standard Music Description Language (ISO/IEC DIS - 10743). While the format itself was hardly ever used for its impractical - implementation details, parts of its design certainly influenced the - development of other formats, including MEI. In a documentation draft (http://xml.coverpages.org/smdl10743-pdf.gz, p.5), SMDL identifies - four different musical domains:

- - - The logical domain is the basic musical content – the essence from which - all performances and editions of the work are derived, including virtual - time values, nominal pitches, etc. The logical domain is describable as “the - composer’s intentions with respect to pitches, rhythms, harmonies, dynamics, - tempi, articulations, accents, etc.,” and it is the primary focus of SMDL. - It can also be described as “the abstract information common to both the - gestural and visual domains.” […] - - The gestural domain is comprised of any number of performances, each of - which may specify how and when components of the logical domain is rendered - in a specific performance, including all the means whereby the performer - actually “expresses” (acoustically instantiates) the music (intonation, - agogic and dynamic stress, etc.). The gestural domain is perhaps most - succinctly described as “the information added by performers,” or “how the - music actually sounds during particular performances.” […] - - The visual domain is comprised of any number of scores, each of which - somehow specifies exactly how components of the logical domain is rendered - visually in some particular printable (and/or displayable) edition, - including such graphical details as symbology, symbol sets, fonts, page - layout, beaming conventions and exceptions, etc. The visual domain is - perhaps most succinctly described as “the information added by human - editors, engravers, and typesetters,” or “how the music actually looks in - some particular edition.” […] - - The analytical domain is comprised of any number of theoretical analyses - and/or commentaries, each of which somehow specifies opinions, exegeses, - etc. about any or all of the information in the other three domains. - […] - -

On a generic level, MEI follows the same definition, and it definitely shares - the same terminology. However, not all four domains are available throughout - the MEI schema, and quite frequently, two domains fall together in MEI. Very - often, MEI prioritizes the visual domain over the gestural domain by (partly) - conflating the logical and the visual domains. For example, MEI utilizes the - pname (pitch name) attribute on notes to capture the written - pitch of a note, whereas the sounding pitch may be described with the - pname.ges attribute. Here, the logical and visual domains go - without a special indication, whereas the gestural domain is identified by a - special suffix. However, in case of transposing instruments, additional markup - (namely the attributes trans.diat and trans.semi from - MEI’s attribute class att.staffDef.log) will create - a distinction between the logical and visual domain (see chapter ). In that case, pname will be restricted to - the visual domain, while the logical aforementioned attributes provide - additional information for the logical domain.

-

Even though the technical implementation of MEI prioritizes the visual domain - to some degree, this does not mean that any given encoding has to provide - visual information. MEI takes no assumption on what data is required: While an - OMR project (optical music recognition) may generate strictly visually - oriented data only, another project focussed on audio transcriptions may - generate gestural data only. A third project could integrate both - approaches.

-

In order to avoid ambiguous encodings, MEI is very strict and specific on the - scope of its individual markup elements. For an encoder, the suffixes mentioned - above provide clear hints on which domain is addressed by specific markup: Many - attributes carry a suffixed .log (logical), .ges (gestural), .vis - (visual), or .anl (analytical) in their name. In addition, the internal - structure of MEI heavily relies on those different domains. When customizing - MEI (see chapter ), it is possible to turn off - either visual or gestural domain encoding completely. That way, MEI allows to - address the four most eminent musical domains specifically and independent of - each other.

-
-
- Events and Controlevents -

MEI differentiates between two essential aspects of music notation: Events and ControlEvents. There - are other examples for such a separation of concerns with regard to music. In - Greg’s Copy-Text Theory (W.W. Greg: The Rationale of - Copy-Text, 1950), a distinction between primary and secondary text is - made; similar attempts have been made for music specifically.

-

In MEI, elements describing the basic musical text are referred to as Events. They are the building blocks for the stream of - music – mostly those are notes, rests, and chords. In contrast, ControlEvents make no independent contribution to that - flow of music. Instead, they provide additional information about the encoded - Events, they control their - performance. Examples for such ControlEvents are dynamic markings, tempos - indications, or performance directives. Depending on the - encoding strategy used, slurs and ties often also fall into this category (they may be encoded as - attributes instead, in which case they become a property of the basic events). - Simply put, Events describe what needs to be performed, and ControlEvents - indicate how it needs to be performed. In (-based) MEI, Events are nested inside - a layer element, while ControlEvents are direct children of the first measure they apply to, following all staff - elements there. These structural differences result in different markup - concepts. As Events are encoded inside layers, their semantic position inside the - encoded work can be derived from their structural - position – the measure, staff and layer they're nested in, and within - that layer by their position inside the sequence of all layer children. As - mentioned above, it is highly recommended to encode ControlEvents inside the first measure they apply to, but - they still require references to the actual events they apply to. There are two - common concepts to provide such a connection, both of which offering specific - benefits and drawbacks. A technically very stable connection between ControlEvents and Events can be - established by using pointers. In this case, all events - that need to be referenced need an xml:id attribute, which holds a - globally unique identifier for this very element. The referencing controlevent - then uses a startid and, if necessary, endid attribute to - create a link to where in the stream of music it is supposed to start or - end.

-

-

- - <measure n="10"> - <staff n="1"> - <layer> - <note pname="f" oct="4" dur="4"/> - <note pname="g" oct="4" dur="4" xml:id="c4ded06ff"/> - <note pname="a" oct="4" dur="4"/> - <note pname="c" oct="5" dur="4"/> - </layer> - </staff> - <dynam startid="#c4ded06ff">f</dynam> -</measure> - -
-

-

In the example above, the dynam element references the - second quarter in the given measure. Additional attributes like - place may be used to describe the position of the forte indication within the score. A hairpin element may use the endid attribute to indicate the - duration of the hairpin using the same mechanism as above.

-

- - - - -

-

A ControlEvent encoded like above will be strictly tied - to the referenced Events – if their position inside the - XML document changes for whatever reason, they will keep that connection. This - means that the semantic position to which they are bound - may change without affecting the binding. An example could be an inserted - additional note in front – the dynamic marking would not start on the second - quarter, but perhaps on the third instead.

-

As this behavior may not be desired in all cases, an alternative binding - between ControlEvents and Events - is possible, relying on timestamps instead. This - mechanism is illustrated in the following example:

-

-

- - <measure n="10"> - <staff n="1"> - <layer n="1"> - <note pname="f" oct="4" dur="4"/> - <note pname="g" oct="4" dur="4"/> - <note pname="a" oct="4" dur="4"/> - <note pname="c" oct="5" dur="4"/> - </layer> - </staff> - <dynam staff="1" layer="1" tstamp="2">f</dynam> -</measure> - -
-

-

Here, no xml:id is required on notes. Instead, the dynam element uses the staff and layer - attributes to indicate to which set of events the following tstamp - attribute refers to.

-

- - - -

-

This mechanism actually depends on what has been only recommended above: - placing the controlevent inside the measure where it starts. The - startid reference mechanism would work equally well if all - controlevents where positioned in the very first or last measure, or actually - even inside a separate file. The tstamp references however would - not, they depend on correct placement of the controlevents inside the XML tree. - For consistency, it is therefore recommended to always - use this placement.

-

The benefit of this concept is that controlevents are tied to a semantic position, but not necessarily to a given XML - element. The forte may still be placed on the second - quarter, even though the composer may have replaced that quarter G4 with a - different pitch and / or duration. Actually, it is not required that an Event can be found at the position indicated by a - timestamp. This may be useful to encode a slur ending at an arbitrary position - between two events, or dynam markings spread across otherwise empty - measures.

-

If the ending of a ControlEvent shall be given by - timestamp, the tstamp2 attribute is used.

-

- - - -

-

Because of potential inconsistencies, an encoding should not offer both - startid and tstamp or endid and - tstamp2. Though not being recommendable, it is possible to mix - startid with tstamp2 and tstamp with - endid. In general, it is easier for software to process - startid and endid. When no other arguments apply, - using xml:id-based pointers is therefore the most common way to - connect ControlEvents with Events.

-

The details on how timestamps are calculated and used in MEI are given in .

-
-
- Timestamps in MEI -

In MEI, timestamps are treated in a slightly simplified way: they have no - notion of beat. Instead, timestamps rely solely on the - numbers given in the meter signature. In a measure of 4/4, timestamps will - range from 1 to 4. The second eighth note will be 1.5 in this case. If the same - measure would be given in 2/2, it would be 1.25 instead.

-

- - - -

-

At this point, MEI uses real numbers only to express timestamps. In case of - (nested or complex) tuplets, this solution is inferior to fractions because of - rounding errors. It is envisioned to introduce a fraction-based value for - timestamps in a future revision of MEI. For now, it is recommended to round the - fractional part of the number to no more than five digits to avoid such - problems.

-

Durations may also be expressed based on timestamps. In this case, the values - are a combination of the count of measures that need to - be moved forward to reach the measure in which an encoded feature ends, and the - timestamp within that measure.

-

- - - -

-

The following example contains a number of slur examples - illustrating durations expressed by timestamps.

-

-

- - <!-- slur starting on timestamp 1, ending on timestamp 4 of the same measure --> -<slur tstamp="1" tstamp2="0m+4"/> - -<!-- slur ending on timestamp 1 of the following measure --> -<slur tstamp="1" tstamp2="1m+1"/> - -<!-- slur ending on timestamp 2.5 in the second next measure --> -<slur tstamp="1" tstamp2="2m+2.5"/> - -
-

-

Sometimes, timestamps are used to indicate positions where no music Events are located (see ). Therefore, the allowed range of timestamps - stretches from 0 to the current meter count + 1. By definition, a timestamp of - 1 indicates the position of the left bar line, while a timestamp of 5 (in case - of a 4/4 meter) indicates the right bar line. This makes it possible to encode - open-ended slurs in a graphical way. However, it should be kept in mind that - such timestamps may not be converted to startid and - endid, and not every application may be able to render them - correctly, even though they are perfectly valid MEI, and sometimes are - necessary to faithfully transcribe a source.

-
-
- MEI Profiles -

MEI is an encoding framework, not a data format. This means that MEI provides - recommendations for encoding music documents, but it depends on the encoder's - needs and requirements to which features and solutions are appropriate to the - task and should be used. MEI offers specific models for different notation - types and music repertoires, but it is rarely advisable to use them all side by - side in one encoding.

-

In order to use MEI, it is advised to use a restricted version of the schema, - which will make it easier both for an encoder and a reader of the encoded - files. MEI provides a number of pre-defined profiles, which focus on specific - uses of MEI while still maintaining a great level of flexibility. For projects - that need even better control over their data, it is highly recommended to - create a more specific customized version of MEI (see chapter ). The following customizations are provided - with every release of MEI:

- - - For most users, this will be the best starting point into music - encoding with MEI. The mei-CMN customization targets at documents that use - Common Western Music Notation. The specific rules for that notation are - specified in chapter , even though other chapters of these - Guidelines apply as well. - - For documents written in Mensural Notation (both black and - white), MEI offers the mei-Mensural customization. The specific rules for - that notation are specified in chapter , even though - other chapters of these Guidelines apply as well. - - This profile allows to encode medieval Neume Notation with MEI. - The specific rules for that notation are specified in chapter , even though other chapters of these Guidelines apply as - well. Please note that the mei-Neumes profile has undergone significant - changes from MEI version 3 to version 4. - - As an encoding framework, MEI offers multiple approaches to encode - certain features at various levels of detail. While this flexibility is at the - core of MEI and often required for research projects, it is an obstacle when - developing software and converters for MEI. The mei-Basic profile is a subset - of MEI which restricts it to one way of encoding for every feature of music - notation. It covers Common Western Music Notation only, and excludes all - editorial markup. In essence, it has the same functionality as most other music - encoding formats like MusicXML or MNX. The purpose of mei-Basic is to serve - as common ground for data interchange, both between projects using different - profiles of MEI, and other encoding schemes. - - This is the full definition of MEI. It includes all different - repertoires, which has certain side effects and enables encoding options that - are neither intended nor advocable. For example, in mensural notation music is - organized by staves. In contrast, Common Music Notation utilizes measures, - which in turn contain staves. These staves have a different meaning here, and - are modeled differently in MEI. mei-all mixes those models and thus invites - encoding errors. In general, you should almost never use mei-all except for - testing purposes. - - This profile includes all of mei-all, but extends it even - further so that it allows any MEI element as root of conforming MEI instances. - In regular MEI, the only allowed starting elements are mei, meiHead, music and - meiCorpus. The sole purpose of this customization is - to simplify validation at tutorial sessions and other educational purposes. It - should not be used in production. - -

The first three profiles provide good starting points to encode music from the - respective repertoires. They may also serve as template for further, - project-specific customizations. The latter two profiles target very - specific use cases and should not be used by default.

-
-
- Customizing MEI -

In production, it is best to use a customized version of MEI, restricted to the - very needs of a project. Such a custom schema will guide the encoders and will - help to ensure consistency and data quality throughout a project’s files. A - customization typically provides a subset of MEI’s encoding models (typically - starting from one of the official profiles mentioned in chapter ), with only one solution for any given situation - being allowed. The customization will help to reflect the scope of a project - into its data: Only those aspects of music notation a project is interested in - will be allowed, so that the absence of a specific information can not be - misunderstood as an oversight of the encoders. Larger editorial projects like - Complete Works editions typically use Editorial Guidelines (german: - Editionsrichtlinien) for the same purposes: (internal) quality control and - (external) documentation. In that sense, MEI customizations may serve as - Editorial Guidelines in digital form.

-

MEI is implemented in ODD. ODD, or One Document Does-it-all, is another - XML-based markup language developed and maintained by the TEI. TEI's - documentation for ODD can be found in the TEI Guidelines chapter 22: Documentation Elements, chapter 23: Using - the TEI, and the "Getting Started with P5 ODDs" document.

-

At this point, there is no specific documentation on how to customize MEI with - ODD beyond the generic TEI documentation. However, the provided are based on ODD customizations, and may serve as - starting point for further project-specific restrictions. They can be found - at https://github.com/music-encoding/music-encoding/tree/dev/customizations. - In addition, several projects have shared their customizations on GitHub, such - as Freischütz Digital or Beethovens Werkstatt.

-

MEI provides a web service at http://custom.music-encoding.org which allows to - compile such customizations against the MEI sources in order to generate - RelaxNG schemata, which can be used for validation. More documentation on - customizing MEI will be provided as time permits; until then, it is recommended - to reach out to the MEI Community for additional - assistance.

-
-
-
- Sample Encodings and Tools for MEI -

The Music Encoding Initiative provides a collection of sample encodings, which - demonstrate a wide-range of uses of MEI in real-world contexts. They are available - from https://github.com/music-encoding/sample-encodings.

-

For MEI, there is also a number of tools, which facilitate encoding of and working - with MEI instances in various contexts. These tools are available from the https://music-encoding.org/resources/tools.html website.

-
-
-
- Shared Concepts in MEI -

This chapter describes basic principles and shared concepts of MEI. Besides giving a general understanding of the basic structures of an MEI file it tries to introduce elements, models, and attributes that are part of the MEI.shared module, describe their use or at least point to chapters of these guidelines or tutorials that describe their use and application.

-
- Structural Elements -

Besides elements used by multiple other modules the MEI.shared module defines the main structural elements of an MEI file. Please be aware that there is also a A short tutorial about the basics of XML & MEI that helps understanding and learning the contents of this chapter.

-
- Document Root Elements -

MEI defines four elements qualifying as root elements (i.e., the element containing everything else) of an MEI document; the most common of these are defined in the MEI.shared module:

-

- - - -

-

The most straightforward – and probably the most common choice fitting most of the use cases when encoding music – is the mei element. It contains an meiHead element for capturing metadata and a music element for describing the musical text. A more detailed description of the application of music can be found in the course of this section (see ). If you want to learn more about the use of the meiHead element – formally declared in the MEI.header module – please visit the chapter in the section.

-

The below example shows the basic structure of an MEI file with mei as root element. Please be aware that this example still does not represent a valid MEI file:

-

-

- - <mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <!-- metadata goes here --> - </meiHead> - <music> - <!-- description of musical text goes here --> - </music> -</mei> - -
-

-

The other potential root elements serve different use cases or purposes.

-

- - - -

-

A document with music as root element provides music notation markup without metadata, and could serve embedding MEI within other kinds of markup, e.g., TEI (see ).

-

The below example shows the basic structure of an MEI file with music as root element. Basically this already represents a valid MEI file, although without any contents:

-

-

- - <music xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <!-- description of musical text goes here --> -</music> - -
-

-

- - - -

-

- meiCorpus contains an meiHead element describing a collection of related MEI-encoded texts – known as a corpus – and an mei element for each text. Further information regarding the organization and encoding of music corpora is given in chapter .

-

The below example shows the basic structure of an MEI file with meiCorpus as root element. Please be aware that this example still does not represent a valid MEI file:

-

-

- - <meiCorpus xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <!-- metadata on the corpus goes here --> - </meiHead> - <mei> - <meiHead> - <!-- metadata on first text goes here --> - </meiHead> - <music> - <!-- description of first musical text goes here --> - </music> - </mei> - <mei> - <meiHead> - <!-- metadata on second text goes here --> - </meiHead> - <music> - <!-- description of second musical text goes here --> - </music> - </mei> - <mei> - <meiHead> - <!-- metadata on … text goes here --> - </meiHead> - <music> - <!-- description of … musical text goes here --> - </music> - </mei> -</meiCorpus> - -
-

-

- - - -

-

The meiHead element, formally declared in the MEI.header module, is described in chapter . A document with meiHead as root element only contains metadata and is also known as an independent or stand-alone header. Stand-alone headers are more fully described in chapter .

-

The below example shows the basic structure of an MEI file with meiHead as root element. Please be aware that this example still does not represent a valid MEI file:

-

-

- - <meiHead xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <!-- metadata goes here --> -</meiHead> - -
-

-

The above examples all carry two attributes on their root elements. While the xmlns is a general feature of XML and not defined in MEI it is crucial for stating the fact that it is an MEI file you are dealing with. The second attribute is att.meiVersion.

-

- - - -

-

Although not required the att.meiVersion attribute is important for defining a stable reference to a specific MEI-version used in the enclosed encoding, and thus is highly recommended on your root element.

-
-
- General Music Structure Elements -

- - - -

-

As indicated above, the general place for encoding the musical text is the music element. MEI.shared offers two possible child elements:

-

- - - - -

-

While body holds the contents of a single musical text, group allows the textual body to consists of a series of (subordinate) musical texts or other e.g., to represent a collection of independent musical texts which is to be regarded as a single unit for processing or other purposes. It is provided to simplify the encoding of collections, anthologies, and cyclic works. It can also be used to record the potentially complex internal structure of corpora, covered more fully in chapter . Whether the musical text being encoded should be structured one way or the other is not to be decided here. For example, a collection of songs might be regarded as a single item in some circumstances, or as a number of distinct items in others. In such borderline cases, the encoder must choose whether to treat the text as unitary or composite; each option may have advantages and disadvantages.

-

There are several more possible child elements of the music element defined in other modules of MEI, such as front and back elements (defined in MEI.text module, cf. ), performance (defined in MEI.performance module, cf. ), genDesc (defined in MEI.genetic module, cf. ), facsimile (defined in MEI.facsimile module, cf. ).

-

Please be aware that the following examples still do not reflect valid MEI files as they are missing some required elements not defined in the MEI.shared module.

-

The basic structure of a unitary musical text:

-

-

- - <mei> - <meiHead> - <!-- metadata goes here --> - </meiHead> - <music> - <front> - <!-- front matter of text, if any, goes here --> - </front> - <body> - <!-- body of text goes here --> - </body> - <back> - <!-- back matter of text, if any, goes here --> - </back> - </music> -</mei> - -
-

-

Examples of composite texts which may be represented using the group element include anthologies and other collections. The presence of common front matter referring to the whole collection, possibly in addition to front matter relating to each individual musical text, is a good indication that a given musical text might usefully be encoded in this way.

-

For example, the overall structure of a collection of songs might be encoded as follows:

-

-

- - <music> - <group> - <music> - <!-- song 1 --> - </music> - <music> - <!-- song 2 --> - </music> - <!-- additional songs here --> - </group> -</music> - -
-

-

A group of musical texts may contain other unitary and grouped texts:

-

-

- - <music> - <group> - <music> - <!-- song 1 --> - </music> - <group> - <!-- songs sharing one or more characteristics, treated as a group --> - <music> - <!-- song 2 --> - </music> - <music> - <!-- song 3 --> - </music> - </group> - </group> -</music> - -
-

-

The group element may be used to encode any kind of collection in which the constituents are regarded by the encoder as works in their own right, such as ad hoc single- or multiple-composer collections or anthologies of works not originally conceived of as a single composition.

-
- Divisions of the Body -

This section describes sub-division of the body of a musical text. Front and back matter are described in chapter .

-

- - - - - -

-

The body of a unitary musical text may contain one or more discrete, linear segments. The names commonly used for these structural subdivisions vary with the genre, style, and time period of the music, or even at the whim of the author, editor, or publisher. For example, a major subdivision of a symphony is generally referred to as a ‘movement’. An opera, on the other hand, is usually organized into ‘acts’ and then further by ‘scenes’. All such divisions are treated as occurrences of the same neutrally-named mdiv element. The attributes type or class may be used to categorize them independently of their hierarchic level.

-

To accommodate "divisions within divisions", an mdiv element may contain additional mdiv sub-elements nested to any level required. For example, the encoding of a multi-movement work, such as a symphony, might have the following structure:

-

-

- - <body> - <mdiv type="symphony"> - <mdiv n="1" type="movement"> - <!-- contents of mvt 1 --> - </mdiv> - <mdiv n="2" type="movement"> - <!-- contents of mvt 2 --> - </mdiv> - <mdiv n="3" type="movement"> - <!-- contents of mvt 3 --> - </mdiv> - <mdiv n="4" type="movement"> - <!-- contents of mvt 4 --> - </mdiv> - </mdiv> -</body> - -
-

-

While dramatic works, such as Verdi's opera, Il Trovatore, often exhibit a more deeply-nested structure:

-

-

- - <body> - <mdiv type="opera"> - <mdiv n="I" type="act"> - <mdiv n="1" type="scene"> - <!-- contents of act I, sc. 1 --> - </mdiv> - <mdiv n="2" type="scene"> - <!-- contents of act I, sc. 2--> - </mdiv> - <mdiv n="3" type="scene"> - <!-- contents of act I, sc. 3 --> - </mdiv> - </mdiv> - <mdiv n="II" type="act"> - <mdiv n="1" type="scene"> - <!-- contents of act II, sc. 1 --> - </mdiv> - <mdiv n="2" type="scene"> - <!-- contents of act II, sc. 2 --> - </mdiv> - <mdiv n="3" type="scene"> - <!-- contents of act II, sc. 3 --> - </mdiv> - <mdiv n="4" type="scene"> - <!-- contents of act II, sc. 4 --> - </mdiv> - <mdiv n="5" type="scene"> - <!-- contents of act II, sc. 5 --> - </mdiv> - </mdiv> - <mdiv n="III" type="act"> - <mdiv n="1" type="scene"> - <!-- contents of act III, sc. 1 --> - </mdiv> - <mdiv n="2" type="scene"> - <!-- contents of act III, sc. 2 --> - </mdiv> - <mdiv n="3" type="scene"> - <!-- contents of act III, sc. 3 --> - </mdiv> - </mdiv> - <mdiv n="IV" type="act"> - <mdiv n="1" type="scene"> - <!-- contents of act IV, sc. 1 --> - </mdiv> - <mdiv n="2" type="scene"> - <!-- contents of act IV, sc. 2 --> - </mdiv> - <mdiv n="3" type="scene"> - <!-- contents of act IV, sc. 3 --> - </mdiv> - </mdiv> - </mdiv> -</body> - -
-

-

Conventionally, in performance the musical structures represented by mdiv elements are separated by pauses; however, attacca, attacca subito, seque, or similar terms are sometimes used at the end of an mdiv to indicate that the next mdiv should begin immediately after the conclusion of the current one. These terms have no effect, however, on the logical segmentation of musical content using mdiv elements.

-
-
- Content of Musical Divisions -

The contents of mdiv can be organized according to the two encoding paradigms provided by the score and parts elements.

-

- - - - -

-

The score element represents notation in which all the parts of an ensemble are arranged on vertically aligned staves, while the parts element collects the individually notated parts for each performer or group of performers. The explicit encoding of these two ‘views’ is necessary because it is not always possible or desirable to automatically derive one view from the other. In addition, separating scores and parts can eliminate a great deal of markup complexity.

-

-

- - <body> - <mdiv n="1" type="movement"> - <score> - <!-- markup of score goes here --> - </score> - <parts> - <!-- markup of performers’ parts goes here --> - </parts> - </mdiv> - <!-- additional movements go here --> -</body> - -
-

-

The score and parts elements may also be employed to accommodate different methods of organizing the markup – with no particular presentation implied. In this case, software may render a collection of parts as a score or a score as a collection of parts.

-

Within the collective parts element, notation for a single performer is represented by the part element:

-

- - - -

-

A part is effectively a small-scale score, allowing all the encoding features of a full score, such as multiple staves, performance directives, and so on. A group of part elements is useful for encoding performing parts when there is no score, such as in early music part books; when the parts have non-aligning bar lines; when different layout features, such as page turns, are needed for the score and parts; or for accommodating software that requires part-by-part encoding.

-

Please note that part elements in MEI are not an indication of voice leading or staff grouping. Voice leading can be encoded using the next attribute, available on all the members of the model.eventLike class. The staffGrp element handles grouping of staves in the score context.

- - <parts> - <part label="Violin 1"> - <!-- first performer’s part --> - </part> - <part label="Violin 2"> - <!-- second performer’s part --> - </part> - <!-- additional performers’ parts --> -</parts> - -
-

-

In both score and part views, the scoreDef element is used to describe logical characteristics of the encoded music, such as key signature, the sounding key (as opposed to the notated key signature), meter, etc., and visual features, such as page size, staff groupings and display labels, etc. The staffGrp elements within scoreDef and the order of staffDef elements inside staffGrp should follow the score order of the source for the encoding.

-

A part or score may be further divided into linear segments called "sections".

-

- - - -

-

- section elements are often used as a scoping mechanism for clef signs, key and meter signatures, as well as metronome, tempo, and expression markings. Using section elements can help to minimize the need for backward scanning to establish context when the starting point for access is not at the beginning of the score. section elements may also be used for other user-defined, i.e., analytical or editorial, purposes and may therefore be arbitrarily nested to any desired level.

-

The ending element shares the same model as the section element. Unlike section, however, it may not be recursively nested.

-

- - - -

-

The most common (non-analytical, non-editorial) use of section and ending elements is illustrated below:

-

-

- - <music> - <body> - <mdiv> - <score> - <section> - <!-- section one to be repeated --> - </section> - <ending n="1"> - <!-- 1st ending --> - </ending> - <ending n="2"> - <!-- 2nd ending --> - </ending> - <section> - <!-- next section --> - </section> - </score> - </mdiv> - </body> -</music> - -
-

-

Within section elements, several methods of organization are possible, depending upon the notational style of the source material and the encoder's needs. For example, when the MEI.cmn module is used, the default organization is measure-by-measure, with staff and layer sub-elements within each measure. Further discussion of CMN notation is continued in chapter .

-

However, staff-by-staff organization is more appropriate for music without measures and is provided when either the MEI.mensural or MEI.neumes module is employed. Coverage of mensural notation is provided in chapter , while describes neumatic notation.

-

It must be noted that, when both the MEI.cmn and MEI.mensural modules are available, it is possible to encode CMN notation without using measure elements; that is, staff-by-staff organization may be used and the ends of measures marked using barLine elements.

-

In certain circumstances, this approach may be preferable for reproduction of the visual layout of the music. However, the simultaneous use of the measure and barLine elements may lead to confusion and should be avoided.

-

Typically, MEI follows the order of sections as they appear in the document being encoded. When performance requires a different order, for instance in the case of D.C. and D.S. directives, the following element may be used to define the performance order.

-

- - - -

-

In the following example, expansion is used to indicate how the notated sections should be ordered in a "through-composed" rendition, for example for machine performance or analysis. The plist attribute contains an ordered list of identifiers of descendant section, ending, lem, or rdg elements. The sequence of values in the plist attribute indicates that the section labelled 'A' comes first, then the section labelled 'B', followed by the 'A' section again. This mechanism must be specified independently of any textual directives, such as "Da capo" or "D.S. al Fine", that may be present in the document.

-

-

- - <music> - <body> - <mdiv> - <score> - <section> - <expansion plist="#shared.A #shared.B #shared.A"/> - <section xml:id="shared.A"> - <!-- "A" section --> - </section> - <section xml:id="shared.B"> - <!-- "B" section --> - </section> - </section> - </score> - </mdiv> - </body> -</music> - -
-

-
-
-
- Document Layout Elements -

This section introduces the elements that can be used to represent document layout features in MEI, be it for the sake of capturing an original source's layout when transcribing or setting up layout features in so called ‘born digital’ documents.

-

- - - - -

-

The pb element can be used to mark page beginnings. When transcribing an existing document the n attribute should be used to record the page number displayed in the source. It need not be an integer, e.g., 'iv', or 'p17-3'. The logical page number can be calculated by counting previous pb ancestor elements. When used in a score context, a page beginning implies an accompanying system beginning. This element is modelled on an element in the Text Encoding Initiative (TEI) standard.

-

- - - -

-

Additional information can be provided on page beginnings. Ranging from a prose description of the page layout in pgDesc to defined headers and footers.

-

- - - - - -

-

"Forme work" is the name for running elements (page headers and footers). Both pgHead and pgFoot have a func attribute that allows encoders to specify to which page(s) the forme work element applies. This includes alternating patterns.

-

Columned layout can be captured with the following elements:

-

- - - - - -

-

In order to force a system break in the musical text sb can be used.

-

- - - -

-

Critical editions and collections of works often contain extensive text, such as a title page, table of contents, an introductory essay, commentary, biographical sketch, index, etc. These textual items may appear in either the front or back elements. The front and back elements, available only when the MEI.text module is activated, are described more fully in chapter .

-

- - - - -

-
-
- General Text Structure Elements -

The MEI.shared module provides basic text structure elements.

-

- - - - - - - -

-

A detailed description of their use and of other elements from the MEI.text module can be found in the corresponding chapter .

-
-
-
- General Music Elements -

This section lists the elements defined in the shared module that are available within the music element.

-
- Score and Parts -

The following elements are provided for the capture of scores and parts:

-

- - - - - - - - - - - - - - - -

-

The character of elements specifying one or more score or staff parameters, such as meter and key signature, clefs, etc., is that of a milestone; that is, they affect all subsequent material until a following redefinition. A scoreDef element, which may affect more than just one staff, is allowed only within score, part and section elements, whereas staffDef is allowed only within staffGrp, staff and layer. A staffDef nested inside a staff must bear the same value for its n attribute as its parent staff and may thus not affect other staves.

-

The actual use of these elements depends on the repertoire and historical context of the source material. For details on their use in Common Western Notation, please refer to chapter .

-
-
- Staves and Layers -

The elements below are used to capture the logical organization of musical notation:

-

- - - - -

-

The actual use of the staff and layer elements depends on the repertoire and historical context of the source material. For details on their use in Common Western Notation, please refer to chapter . For mensural notation, see chapter , and for neumatic notation, chapter .

-
-
- Basic Music Events -

The basic features of music notation are represented by the following elements:

-

- - - - - -

-

The characteristics of stems on notes and chords are indicated by means of attributes found in the att.stems class.

-

- - - -

-
-
- Other events -

Because they can occur in the context of a stream of events on the staff, some elements which are used in other contexts are also treated as events. For example, in addition to being used to define the initial clef of a staff, the clef element can also be used to indicate a clef change.

-
- Key Signatures and Clefs -

Key signatures and clefs as well as intra-staff changes to these musical parameters are treated as events.

-

- - - - - - -

-
-
- Bar Lines and Custos Signs -

Measure separators, i.e., bar lines, and custos signs are also considered to be events.

-

- - - - -

-
-
- Accidentals, Articulation Symbols, Augmentation Dots, and Custos Signs -

The following elements are regarded as events primarily because they sometimes occur independently of any associated notes, rests, or chords, especially in mensural and neume repertoires.

-

- - - - - -

-

-

- - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Alignment of editorial accidentals</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>Editorial accidentals are aligned on the centre of the notehead.</annot> - </notesStmt> - </fileDesc> - <encodingDesc /> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef n="1"> - <staffGrp> - <staffDef n="1" lines="5" clef.shape="G" clef.line="2" /> - </staffGrp> - </scoreDef> - <section> - <measure right="end" n="1"> - <staff n="1"> - <?edit-start?> - <layer n="1"> - <note dur="1" oct="5" pname="f"> - <accid accid="s" func="edit" /> - </note> - <note dur="1" oct="5" pname="f"> - <accid accid="f" func="edit" /> - </note> - <note dur="1" oct="5" pname="f"> - <accid accid="n" func="edit" /> - </note> - <note dur="1" oct="5" pname="f"> - <accid accid="x" func="edit" /> - </note> - <note dur="1" oct="5" pname="f"> - <accid accid="ff" func="edit" /> - </note> - </layer> - <?edit-end?> - </staff> - </measure> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-
-
- Lyric Syllables -

The syl element is used to mark a word or portion of a word that is to be vocally performed. A fuller description of its use is provided in chapter .

-

- - - -

-
-
- Event Spacing -

The following elements provide control over the horizontal spacing of notational events, such as notes, chords, rests, etc.:

-

- - - -

-

In this context, the term ‘space’ is used to mean whitespace that is required to meaningfully align multiple voices in a multi-voice texture. In DARMS these were referred to as ‘push codes’. The space element is most often used when a new voice appears on a staff mid-measure.

-

The space element may also be used to align material that crosses staves.

-

‘Space’ can be thought of as another kind of event. In fact, some refer to this concept as an ‘invisible rest’.

-

While ‘space’ is meaningful, ‘padding’ is non-essential whitespace that is used to shift the position of the events which follow.

-

- - - -

-

The pad element is provided in order to capture software-dependent placement information when it is desirable to do so. Unless the MEI file will be used as an intermediate file format, this is usually not necessary.

-
-
-
- Expression Marks -

Expression marks are instructions in the form of words, abbreviations, or symbols that convey aspects of performance that cannot be expressed purely through the musical notation.

-
- Text Directives -

All of the following elements can be considered text directives; however, MEI uses the dir element specifically for words, abbreviations, numbers, or symbols specifying or suggesting the manner of performance that are not encoded elsewhere using the more specific elements of tempo and dynam.

-

- - - -

-

Examples of directives include text strings such as 'affettuoso', fingering numbers, or music symbols such as segno and coda symbols or fermatas over a bar line. Directives can be control elements. That is, they can linked via their attributes to other events. The starting point of the directive may be indicated by either a tstamp, tstamp.ges, tstamp.real or startid attribute, while the ending point may be recorded by either a tstamp2, dur, dur.ges or endid attribute. It is a semantic error not to specify a starting point attribute.

-
-
- Tempo -

Tempo marks are indications through words, abbreviations, or specific metronome settings of the speed at which a piece of music is to be performed. Both instantaneous and continuous tempo markings may be encoded using this element.

-

- - - -

-

-

- - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Tempo example</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>Verovio supports "tempo" elements. Horizontal positioning can be specified. - By default, tempi indications are placed above the staff. The "rend" element can - be used within the text, for example for specifying metronome values.</annot> - </notesStmt> - </fileDesc> - <encodingDesc> - <appInfo> - <application version="0.9.13"> - <name>Verovio</name> - </application> - </appInfo> - </encodingDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef meter.sym="cut"> - <staffGrp> - <staffDef label="Violino" n="1" lines="5" clef.shape="G" clef.line="2" /> - </staffGrp> - </scoreDef> - <section> - <?edit-start?> - <measure n="0" type="upbeat"> - <staff n="1"> - <layer n="1"> - <beam> - <note xml:id="m0_s2_e1" dur="8" oct="5" pname="e" /> - <note xml:id="m0_s2_e2" dur="8" oct="5" pname="f" /> - </beam> - </layer> - </staff> - <tempo staff="1" tstamp="1.000000">Andante con moto <rend fontfam="smufl">&#xE1D3;</rend> = 70</tempo> - <slur startid="#m0_s2_e1" endid="#m0_s2_e2" /> - </measure> - <?edit-end?> - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dots="1" dur="4" oct="5" pname="g" /> - <note dur="8" oct="5" pname="g" /> - <note dur="4" oct="5" pname="g" /> - <beam> - <note xml:id="m1_s2_e4" dur="8" oct="5" pname="g" /> - <note xml:id="m1_s2_e5" dur="8" oct="6" pname="c" /> - </beam> - </layer> - </staff> - <slur startid="#m1_s2_e4" endid="#m1_s2_e5" /> - </measure> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-
-
- Dynamics -

Dynamics, or dynamic marks, are terms, abbreviations, and symbols that indicate the specific degrees of volume of a note, phrase, or section of music, e.g., "piano", "forte". Transitions from one volume level to another, e.g., "crescendo", "diminuendo", are also specified through dynamic marks.

-

- - - -

-
-
- Phrase Marks -

Phrase marks are curved lines placed over or under notes to delineate short sections of a work that represent a unified melodic idea, analogous to a phrase in literature.

-

- - - - -

-

MEI maintains a distinction between phrase marks and slurs, the latter being curved lines over or under a sequence of notes indicating they are to be performed using a particular playing/singing technique, notes that should be taken in a single breath by wind instruments or played by string instruments using a single stroke of the bow. Often, a slur also indicates that the affected notes should be played in a legato manner.

-

Even so, it is common for both of these concepts to be referred to generically as "slurs". Therefore, unless one is encoding music from a repertoire in which this distinction is important, the slur element should be preferred over phrase.

-
-
- Ornaments -

Ornaments are formulae of embellishment that can be realized by adding supplementary notes to one or more notes of the melody.

-

- - - -

-

MEI provides a generic element for encoding an ornament symbol that is not a mordent, turn, or trill. For those common CMN ornaments, please refer to .

-

Ornaments can be represented as textual strings (e.g., with a Unicode symbol) or with a user defined symbol (for the latter also see ).

-

Ornaments may also be encoded as so called control events (see also: ). That is, they be can linked via their attributes to other events. It is a semantic error not to specify a starting point attribute with either tstamp or startid.

-
-
-
-
- Common Attributes -

The following attributes, all of which are defined in separate attribute classes but are also provided through the att.common attribute class, are available on nearly all elements in an MEI encoding. They provide e.g., the means to identify, label, or reference elements in MEI-encoded files.

-
- Attributes from the XML-namespace -

The most general attributes that are very frequently encountered in MEI files are not even native MEI attributes but are coming from the basic definition of XML in the XML-namespace http://www.w3.org/XML/1998/namespace. MEI redefines some of them in the att.basic class.

-

- - - -

-

The value of the xml:id attribute serves as an identifier for an element and its content. Its value must be unique in the context of the current document and must conform to the definition of an XML Name provided by the W3C Recommendation at http://www.w3.org/TR/xml/#NT-Name. Suggestions for constructing an xml:id value can be found at http://www.w3.org/TR/xml/#sec-suggested-names.

-

The xml:id attribute may take values similar to the following:

-

-

- - <!-- The following are all valid IDs. --> -<note xml:id="n1"/> -<note xml:id="_n1"/> -<note xml:id="thisIsMyFavoriteNote"/> -<note xml:id="shared.thisIsMyFavoriteNote"/> -
-

-

This is an example of an incorrectly-formulated xml:id value:

-

-

- - <!-- xml:id not valid as IDs are not allowed to start with a number. --><note xml:id="1"/> - -
-

-

- - - -

-

At many locations in an MEI file one can reference internal or external references. E.g. the following example defines a graphic and references an external image (entity) by means of the target attribute:

-

-

- - <graphic target="myImage.jpg"/> - -
-

-

When a reference to an external entity is not a complete URI it is resolved against the current base URI; if not defined by other means this would be the location of the current document. The above example consequently would mean, that the file `myImage.jpg` referenced from graphic resides at the same location (in the same folder) as the MEI-file.

-

The xml:base attribute may be used “to specify a base URI other than the base URI of the document or external entity.” (Marsch, Jonathan; Tobin, Richard: XML Base (Second Edition). W3C Recommendation 28 January 2009. online at: http://www.w3.org/TR/2009/REC-xmlbase-20090128/).

-

-

- - <graphic target="myImage.jpg" xml:base="http://www.mySite.org/images/"/> - -
-

-

The value of xml:base can be inherited from an ancestor. This is relevant for resolving relative links or URIs within the document. A comprehensible use case can be illustrated by the following example: the values of the graphic elements' target attribute can be completed by the xml:base value specified for the ancestor facsimile element:

-

-

- - <facsimile xml:base="http://www.mySite.org/images/"> - <surface> - <graphic target="myImage.jpg"/> - <graphic target="myImage.tif"/> - </surface> -</facsimile> - -
-

-

In order to determine an absolute URI, the base URIs of the element and all its ancestors (including the document node) have to be taken into account. In the above case the relative URIs of graphic/@target would consequently resolve to:

-

``` http://www.mySite.org/images/myImage.jpg http://www.mySite.org/images/myImage.tif ```

-

For more information on xml:base see: https://www.w3.org/TR/xmlbase/ -

-

The xml:id and xml:base attributes are especially important when it comes to linking document fragments to each other or to external entities. Many of the linking attributes are globally available in MEI through the att.common attribute class.

-

Yet there are other attributes from the XML-Namespace encountered in MEI files.

-

- - - - -

-

While xml:lang attribute may be used to encode the language of an element's contents, the xml:space attribute lets you define the handling of whitespace, i.e., whitespace being important content (preserve) or negligible (default). With the latter also being the default value if no xml:space attribute is present.

-
-
- Label Attributes -

- - - - - -

-

The label and n attributes both serve a labeling function; however, they differ in the values they allow. The n attribute must be a single token, while label may contain a string value that includes spaces. This makes label useful for the capture of free-text labels, but a name or number specified with n may be easier to process.

-

-

- - <!-- Example of a @label containing whitespace: --> -<mdiv label="Allegro moderato"> - <!-- … --> -</mdiv> -<!-- Example of a processable @n attribute: --> -<measure n="42"> - <!-- … --> -</measure> -
-

-
-
- Classification Attributes -

- - - - -

-
-
- Responsibility Attributes -

- - - -

-
-
- Linking Attributes -

- - - -

-

For a detailed description of linking mechanisms used in MEI also see the section on .

-
-
-
- User-defined Symbols -

This chapter describes the elements, model classes, and attribute classes that are part of the MEI.usersymbols module.

-
- Overview of the Usersymbols Module -

The module described in this chapter makes available the following components:

-
- Elements -

- - - - - - - - -

-
-
- Attribute Classes -

No attribute classes are defined in this module.

-
-
- Model Classes -

The usersymbols module defines the following model classes:

-

- model.graphicPrimitiveLike - model.symbolTableLike -

-
-
-
- Uses of the Usersymbols Module -

The elements provided by the usersymbols module may be used in two ways:

- - For defining lines, curves and text elements that cannot be represented by a more specific element. - For defining reusable symbols and special graphical renditions. - -

For this purpose, it provides three elements as graphic primitives, line, curve and anchoredText. Anywhere these elements are allowed, the symbol element can be used as well. The symbol element facilitates the re-use of symbols that were defined by symbolDef elements.

-
- Defining Reusable Symbols -

The symbolDef element uses SVG markup or the aforementioned graphic primitives to describe a symbol. A symbol definition may also use symbols defined by other symbolDef elements by employing the symbol element.

-

The following code snippet shows a definition of a triangle percussion symbol using graphic primitives:

- Definition of a triangle percussion symbol using graphic primitives - <symbolDef xml:id="userSymbols.triangleSymbol3"> - <line x="0" x2="2.55" y="0" y2="4.25"/> - <line x="2.55" x2="5.1" y="4.25" y2="0"/> - <line x="5.1" x2="0.85" y="0" y2="0"/> -</symbolDef> - -
-
- Rendition of the triangle defined above - -
-

-

The following snippet encodes a symbol composed of the symbol defined above and additional graphics primitives:

- Symbol composed of the symbol defined above and additional graphics primitives - <symbolDef xml:id="userSymbols.triangleSymbolWithStick"> - <symbol ref="#userSymbols.triangleSymbol3"/> - <line x="2.55" x2="5.95" y="1.25" y2="3.4"/> -</symbolDef> - -
-
- Rendition of the composite triangle symbol - -
-

-
-
- Elements Without Semantic Implications -

The graphics primitives and symbols can be used directly in the music to describe text and lines on a purely graphical level, without implying a specific logical meaning. If possible, however, more meaningful elements should be used. This means for example, "a tempo" or "da capo" should in general not be put inside anchoredText. Instead, tempo and dir should be used. Likewise, slurs and ties should be encoded using their respective elements, not using curve, and for glissandi, gliss should be used instead of line.

-

An example usage for line is the visualization of voice leading, which is not covered by a specific MEI element.

-

-

- Voice leading visualization as found in an Edition Peters print of Album für die Jugend by Schumann, No. 35 (Mignon), measure 6. (Unknown date, plate number is 10478.) - -
-

-

The following code snippet shows the encoding of the above example:

- Encoding of the Schumann example - <measure n="6"> - <staff n="1"> - <layer n="1"> - <rest dur="4" xml:id="userSymbols.r1"/> - <beam> - <note dur="8" oct="4" pname="c" xml:id="userSymbols.n1"/> - <note dur="8" oct="4" pname="e" xml:id="userSymbols.n2"/> - </beam> - <beam> - <note dur="8" oct="4" pname="g" xml:id="userSymbols.n3"/> - <note dur="8" oct="4" pname="e" xml:id="userSymbols.n4"/> - <note dur="8" oct="4" pname="b" xml:id="userSymbols.n5"/> - <note dur="8" oct="4" pname="g" xml:id="userSymbols.n6"/> - </beam> - <slur curvedir="above" endid="#userSymbols.n6" startid="#userSymbols.n1"/> - </layer> - <layer n="2"> - <rest dur="4"/> - <note dur="2" - next="#userSymbols.n9" - oct="4" - pname="c" - stem.dir="down" - xml:id="userSymbols.n7"/> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <note dots="1" dur="2" oct="2" pname="g" xml:id="userSymbols.n8"/> - <note dur="4" - oct="3" - pname="b" - prev="#userSymbols.n7 #userSymbols.n8" - xml:id="userSymbols.n9"/> - <slur curvedir="above" endid="#userSymbols.n9" startid="#userSymbols.n8"/> - </layer> - </staff> - <line endid="#userSymbols.n9" rend="dotted" startid="#userSymbols.n7"/> -</measure> - -
-

-
-
- Defining a Specific Graphical Rendition for a Semantic Element -

Usersymbols can define the rendition of different elements in two ways. Some elements, for example dir and tempo, can have user symbol elements as content. In the following example, the content of dir is used to provide pictograms of percussion instruments.

-

-

- Indicating percussion instruments using pictograms - -
-

-

The corresponding encoding would be as follows:

- Encoding of above example - <section> - <scoreDef meter.count="4" meter.unit="4"> - <symbolTable> - <symbolDef xml:id="userSymbols.triangleSymbol1"> - <line x="0" x2="2.55" y="0" y2="4.25"/> - <line x="2.55" x2="5.1" y="4.25" y2="0"/> - <line x="5.1" x2="0.85" y="0" y2="0"/> - <line x="2.55" x2="5.95" y="1.25" y2="3.4"/> - </symbolDef> - <symbolDef xml:id="userSymbols.cowbellSymbol"> - <line x="1" x2="1.8" y="0" y2="4"/> - <line x="1.8" x2="4.2" y="4" y2="4"/> - <line x="4.2" x2="5" y="4" y2="0"/> - <line x="5" x2="1" y="0" y2="0"/> - <curve bezier="0 1.5 0 1.5" - endho="3" - endvo="4" - startho="1" - startvo="4"/> - </symbolDef> - </symbolTable> - <staffGrp> - <staffDef clef.line="2" clef.shape="G" n="1"/> - </staffGrp> - </scoreDef> - <measure n="1"> - <staffDef n="1"> - <instrDef midi.instrname="Open_Triangle"/> - </staffDef> - <staff n="1"> - <layer> - <dir tstamp="1"> - <symbol ref="#userSymbols.triangleSymbol2"/> - </dir> - <note dur="1"/> - </layer> - </staff> - </measure> - <measure n="2"> - <staffDef n="1"> - <instrDef midi.instrname="Cowbell"/> - </staffDef> - <staff n="1"> - <layer> - <dir tstamp="1"> - <symbol ref="#userSymbols.cowbellSymbol"/> - </dir> - <note dur="4"/> - <note dur="4"/> - <note dur="4"/> - <note dur="4"/> - </layer> - </staff> - </measure> -</section> - -
-

-

A number of elements can point to an internally-defined symbol for rendering using the altsym attribute.

-

-

- Different treble clef renditions as written by Charpentier (source: Journal of Seventeenth-Century Music, Volume 12, No. 1 (2006), figure 3) http://www.sscm-jscm.org/v12/no1/gosine.html - -
-

-

-

- Defining two staffs, each using its own treble clef shape - <scoreDef> - <symbolTable> - <symbolDef xml:id="userSymbols.clefA"> - <curve bezier="-1.2 0.1 -0.9 -0.8" - endho="1.1" - endvo="6.6" - startho="1.2" - startvo="4"/> - <curve bezier="1 0.9 0.1 1.6" - endho="3" - endvo="5.3" - startho="1.1" - startvo="6.6"/> - <curve bezier="-0.1 -2.6 0 2.3" - endho="0.6" - endvo="-0.1" - startho="3" - startvo=" 5.3"/> - <curve bezier="0.07 -1.3 -0.2 -1.63" - endho="2.4" - endvo="0.23" - startho="0.6" - startvo="-0.1"/> - <curve bezier="0.2 1.3 0.5 0.62" - endho="0.8" - endvo="0.81" - startho="2.4" - startvo="0.23"/> - </symbolDef> - <symbolDef xml:id="userSymbols.clefB"> - <curve bezier="-0.7 0.1 0.3 0.92" - endho="0.7" - endvo="-0.2" - startho="2.5" - startvo=" 1.3 "/> - <curve bezier="-0.27 -0.76 -1.25 -1.26" - endho="2" - endvo="-0.74" - startho="0.7" - startvo="-0.2"/> - <curve bezier="1.4 1.8 0.4 -1" - endho="1.6" - endvo="4.36" - startho="2" - startvo="-0.74"/> - <curve bezier="-0.89 2.2 -1.1 1.6" - endho="3.5" - endvo="6.06" - startho="1.6" - startvo="4.36"/> - <curve bezier="0.8 -1.2 0 0" - endho="3.7" - endvo="2.66" - startho="3.5" - startvo="6.06"/> - </symbolDef> - </symbolTable> - <staffGrp> - <staffDef n="1"> - <clef altsym="#userSymbols.clefA" line="2" shape="G"/> - </staffDef> - <staffDef n="2"> - <clef altsym="#userSymbols.clefB" line="2" shape="G"/> - </staffDef> - </staffGrp> -</scoreDef> - -
-

-

Externally-defined symbols may be referenced using a glyph.name or glyph.num attribute from the att.extSym attribute class. Both attributes refer to Standard Music Font Layout (SMuFL) characters, if not specified differently by the glyph.auth and glyph.uri attributes.

-

-

- Use of glyph.auth and glyph.name and glyph.num attributes to refer to a SMuFL symbol - <ornam tstamp="1"> - <symbol glyph.auth="smufl" - glyph.num="#xE5C0" - glyph.name="ornamentPrecompDoubleCadenceLowerPrefix"/> -</ornam> - -
-

-

-

- Use of glyph.name and glyph.num attributes - <meterSig count="2" - form="norm" - glyph.name="timeSigCutCommon" - glyph.num="U+E08B" - sym="cut" - unit="4"/> - -
-

-
-
-
- Positioning and Coordinates -
- Axis Orientation -

MEI uses the classic axis directions where the x-axis points from left to right and the y-axis points from bottom up. (This is compatible with PostScript's axis orientation, while SVG's y-axis points in the opposite direction.)

-
-
- Units -

There are two types of units used by MEI: Staff units and units of the output coordinate system. Units of the output coordinate system can be translated to physical real world distances by means of the vu.height and page.scale of a scoreDef element. Real world units are multiplied by the value of page.scale to get the corresponding value in output coordinate units.

-

If an element is scaled using the scale attribute, the actual size of the units changes accordingly.

-
-
- Positioning -

An element may be positioned using either absolute or relative coordinates. If absolute start point coordinates are specified using x/y coordinates (or their relatives x2/y2 for endpoints) they take precedence over relative positions specified by ho/vo/to (or startho/startvo/startto). Analogously, x2/y2 override endho/endvo/endto.

-

If to/startto/endto attributes are used, the start or end point is x-aligned with the indicated timestamp.

-

If relative start coordinates (ho/vo or startho/startvo) are used, the origin of the coordinate system to be used for the start point is the first one found by the following search schema:

- - If startid is present, the origin of the referenced element; - If the element is inside running text (e.g., inside tempo), the end of the preceding text or element; - Otherwise, the origin of the containing element. - -

The start point is offset from this origin by the value of the start coordinates (ho/vo or startho/startvo), using staff units.

-

Analogously, the endpoint is determined using end coordinates (endho/endvo). If endid is specified, it takes precedence over startid.

-

Examples of origins are:

- - - staff and layer: The horizontal origin is the starting point of the measure, the vertical one is the bottom staff line; - - note: The horizontal origin is the left end of the notehead, the vertical one is the center of the notehead; - - clef: The horizontal origin is the left end of the clef, the vertical one the line specified by clef/line (or clef.line); - For elements containing text: The left end of the baseline; - - symbolDef: As symbol definitions aren't rendered directly, their coordinate system and origin are considered virtual. - -

When they are referenced by symbol or altsym, the origin of the context, i.e., the referencing symbol, is used. If neither absolute nor relative coordinates are specified, determining visually suitable start and end points for line and curve attributes is left to the rendering application. A value of 0 is not always assumed for absent relative coordinates. A typical example where a rendering application may not choose the origins of absent relative start and end coordinates to be the start point as well is the line connecting two notes in the above Schumann example.

-
-
- Curve Shape -

If neither a bezier nor bulge attribute is present, the renderer determines a suitable shape. However, if curvedir is present, the curve must respect the curvature direction specified there.

-

The attributes bezier and bulge define the shape of a curve in two different ways. If both are present, a rendering application may choose either one. They override curvedir.

-

- bezier defines the inner control points of a cubic Bézier curve, i.e., a Bézier curve with two inner control points. The coordinates are given by a space separated list, first x and y offsets for the first control point, then x and y offsets for the second one. The x and y offsets are given in staff units (or inside the context of symbolDef in abstract units). The offsets for the first inner control point are relative to the start point, the ones for the second inner control point are relative to the end point.

-

The bulge attribute allows specification of the curve shape by a number of interpolation points. The interpolation points are given by their distance from the line connecting the start and end point. The distance values are stored as a space separated list.

-

The interpolation points are calculated as follows: If bulge provides n distance values, the connection line is divided into n+1 subsegments of equal length. The interpolation points are found by drawing a perpendicular line of the respective length at each subsegment joint. Positive distance values are drawn to the left of the connection line (left when traveling from start to end), negative ones to the right.

-

-

- Rendering a bulge attribute with value "-2 1" - -
-

-

The interpolation algorithm used by the rendering application is implementation dependent.

-
-
-
- Line Rendition -

The form attribute of the line element may take the following values:

- - dashed - dotted - solid - wavy - -

These attribute values are only qualitative. Actual dash length and dot and dash spacing are implementation dependent.

-

The width attribute may take the following values:

- - narrow - medium - wide - -

These values are also qualitative, however, they are also relative. That is, 'narrow' is the default value, 'medium' is twice as wide as 'narrow', and 'wide' is twice as wide as 'medium'.

-

In addition to textual values, the width attribute may contain a numeric value and an optional unit, e.g., 2mm. If the unit value is not provided, MEI virtual units are presumed.

-

The same applies for curve elements with the lform and lwidth attributes from the att.lineRend.base class.

-

The startsym and endsym attributes name the symbol that may start and/or end a line, while startsymsize and endsymsize indicate the relative size of the symbol using a numeric value in the range from 1 to 9.

-
-
- Limitations -

The usersymbols module does not currently support continuous composite lines or filled areas. As mentioned above, the rendition of lines is highly implementation dependent. Coordinate system transforms are restricted to scaling using scale.

-
-
-
-
- Metadata in MEI -
- Introduction -

Metadata means "data about data", i.e., information about various aspects of an encoding at hand. There are many different types of metadata, which MEI tries to order according to their respective scope or perspective, as described in . MEI’s approach to metadata is heavily influenced by other existing standards and models, such as TEI, MARC, and FRBR. It attempts to reflect both current library practice and common scholarly methods, for example in the field of source descriptions (see chapter ).

-

This chapter thus addresses the description of an encoded item so that the musical text, as well as its sources, encoding, and revisions are all thoroughly documented. Such documentation is necessary for scholars using the texts, for software processing them, and for catalogers in libraries and archives. Together these descriptions and declarations provide an electronic analog to the title page attached to a printed work. They also constitute an equivalent for the content of the code books or introductory manuals customarily accompanying electronic data sets.

-
-
- Structure of the MEI Header -

Every MEI-conformant text not embedded in another XML carrier that provides for capturing metadata, such as TEI or METS, must carry a set of descriptions, prefixed to it and encoded as described in this chapter. This set is known as the MEI header, tagged meiHead.

-

The metadata encoded inside meiHead covers a number of different use cases. Some child elements like titleStmt may appear in various places (see ), so it is important to understand the roles of the different areas of the MEI header. These areas are described following their order of appearance within the meiHead element:

- - Zero or more alternative identifiers, tagged with altId, each of which provides an identifying name or number associated with the file. This is just a simple element that helps to preserve other external identifiers for a file, such as database keys. - A file description, tagged fileDesc, containing a full bibliographic description of the computer file itself. From the information contained here, a user of the encoding should be able to derive a proper bibliographic citation, and a librarian or archivist could use it for creating a catalog entry recording its presence within a library or archive. A titleStmt within fileDesc captures the title of the file, which may be different than the title of the encoded work, or the title given on any of the sources used to generate the file. The term computer file here is to be understood as referring to the whole intellectual entity or document described by the header, even when this is stored in multiple physical operating system files. The file description also includes information about the source or sources from which the electronic document was derived (not to be confused with sources that represent or witness the encoded work in a more general sense; these may be described within the manifestationList element). - The MEI elements used to encode the file description are described in section . - An optional encoding description, tagged encodingDesc, which describes the relationship between an electronic text and its source or sources. It allows for detailed description of whether (or how) the text was normalized during transcription, how the encoder resolved ambiguities in the source, what levels of encoding or analysis were applied, and similar matters. - The MEI elements used to encode the encoding description are described in section . - An optional work description or list of the works encoded or described in the file, tagged workList, containing classification and contextual information about the work(s), such as its subject matter, the situation in which it was produced, the individuals described by or participating in producing it, and so forth. Such a work profile is of particular use in highly structured composite texts such as corpora or language collections, where it is often highly desirable to enforce a controlled descriptive vocabulary or to perform retrievals from a body of text in terms of text type or origin. The work description may however be of use in any form of automatic text processing. - The MEI elements used to encode the work description are described in section . - An optional list of manifestations of the work, tagged manifestationList, containing descriptions of sources ("manifestations" in terms) that represent or witness the encoded work in some way, regardless of whether the encoding is based on these sources or not; for instance, it is useful for listing all known sources to a particular work in a cataloging project or a critical edition. - The MEI elements used to encode the source description are described in section . - Zero or more elements tagged extMeta, containing non-MEI metadata. - This concept is covered in section . - A revision history, tagged revisionDesc, which allows the encoder to provide a history of changes made during the development of the electronic text. The revision history is important for version control and for resolving questions about the history of a file. The MEI elements used to encode the revision description are described in section . - -
-
- Common Metadata Concepts -

This chapter introduces data models and markup available in various locations of the MEI header.

-
- Title Statement -

The titleStmt element is to capture the title of an MEI file (within a fileDesc element) and the title of any of the relevant manifestations (sources) of the encoded work.

-

- - - -

-

The title statement contains the title given to the electronic work, together with one or more optional statements of responsibility which identify the encoder, editor, author, compiler, or other parties responsible for it:

-

- - - - - - - - - - - - - -

-

The title element contains the chief name of the electronic work. Its content takes the form considered appropriate by its creator. The element may be repeated, if the work has more than one title (perhaps in different languages). Where the electronic work is derived from an existing source text, it is strongly recommended that the title for the former should be derived from the latter, but clearly distinguishable from it, for example by the addition of a phrase such as ‘: an electronic transcription’ or ‘a digital edition’. This will distinguish the electronic work from the source text in citations and in catalogs, which contain descriptions of both types of material.

-

-

- - <titleStmt xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <title>Lieder-Album für die Jugend</title> - <title type="subtitle">für Singstimme(n) und Klavier, - <identifier>op. 79</identifier> - </title> - <title type="subtitle">an electronic transcription</title> -</titleStmt> - -
-

-

Other alternative titles or subtitles may be encoded in additional title elements with values in the type attribute that distinguish them from the chief title. Sample values for the type attribute include: main (main title), subordinate (subtitle, title of part), abbreviated (abbreviated form of title), alternative (alternate title by which the work is also known), translated (translated form of title), uniform (collective title).

-

The type attribute is provided for convenience in analyzing titles and processing them according to their type; where such specialized processing is not necessary, there is no need for such analysis, and the entire title, including subtitles and any parallel titles, may be enclosed within a single title element, as in the following example:

-

-

- - <title>Symphony No. 5 in C Minor : an electronic transcription</title> - -
-

-

The electronic work will also have an external name (its ‘filename’ or ‘data set name’) or reference number on the computer system where it resides at any time. This name is likely to change frequently, as new copies of the file are made on the computer system. Its form is entirely dependent on the particular computer system in use and thus cannot always easily be transferred from one system to another. Moreover, a given work may be composed of many files. For these reasons, these Guidelines strongly recommend that such names should not be used as the title for any electronic work.

-

Helpful guidance on the formulation of useful descriptive titles in difficult cases may be found in the Anglo-American Cataloguing Rules (Gorman and Winkler, 1978, chapter 25) or in equivalent national-level bibliographical documentation.

-

It is important to keep in mind that the titleStmt element provides structured metadata. Preserving the exact rendition of a title page is possible using the titlePage element (see ).

-

The title of a work is given by using the title element directly, as many other child elements of titleStmt are available on work directly.

-
-
- Responsibility Attribution -

In scholarly work, attribution of responsibility is crucial. For this purpose, MEI offers the respStmt element, which is available in the following contexts:

-

- - - - - - - - - - - - - - -

-

At a minimum, the creator of the musical text and the creator of the file should be identified. If the bibliographic description is for a corpus, identify the creator of the corpus. Optionally also include the names of others involved in the transcription or elaboration of the text, sponsors, and funding agencies. The name of the person responsible for physical data input need not normally be recorded, unless that person is also intellectually responsible for some aspect of the creation of the file.

-

In traditional bibliographic practice, those with primary creative responsibility are given special prominence. MEI accommodates this approach by providing responsibility-role elements. For example:

-

-

- - <titleStmt> - <title>Auf dem Hügel sitz ich spähend : an electronic transcription</title> - <composer>Ludwig van Beethoven</composer> - <lyricist>Aloys Jeitteles</lyricist> -</titleStmt> - -
-

-

Secondary intellectual responsibility in this case is encoded using respStmt. The respStmt element has two subcomponents: a name element identifying a responsible individual or organization, and a resp element indicating the nature of the responsibility. All names should be stated in the form in which the persons or bodies wish to be publicly cited. This will usually be the fullest form of the name, including first names. No specific recommendations are made at this time as to appropriate content for resp. However, it should make clear the nature of the responsibility.

-

-

- - <titleStmt> - <title>Auf dem Hügel sitz ich spähend : an electronic transcription</title> - <composer>Ludwig van Beethoven</composer> - <lyricist>Aloys Jeitteles</lyricist> - <respStmt> - <resp>Encoded by</resp> - <name>Maja Hartwig</name> - <name>Kristina Richts</name> - </respStmt> -</titleStmt> - -
-

-

This method of encoding facilitates exchange of bibliographic data with library catalogs and bibliographic databases as well as applications whose handling of bibliographic data is restricted to traditional responsibility roles. Additional information regarding these responsibility-role elements can be found in chapter .

-

When the MEI.namesdates module is enabled, two additional elements are also permitted within respStmt:

-

- - - - -

-

These elements allow for more precise identification of the entity associated with the name than is permitted by the simpler name element. The following example shows how a precise date range can be associated with a personal or corporate name.

-

-

- - <respStmt> - <resp>Machine-readable transcription by:</resp> - <persName enddate="1940-11-06" startdate="1860-01-01">John Doe</persName> -</respStmt> - -
-

-

For additional information about corporate and personal names, see chapter .

-

In addition to, or instead of the resp element, the role attribute on name, persName, and corpName may be used to capture the nature of responsibility. While resp accommodates capturing the wide variety of text that may occur in responsibility statements, use of the role attribute provides the possibility of recording a controlled value independently of the textual content of resp.

-

-

- - <respStmt> - <resp>Encoded by</resp> - <corpName role="encoder">Members of the Local Symphony Orchestra</corpName> -</respStmt> - -
-

-

Values from the MARC relator code list (http://www.loc.gov/marc/relators/relacode.html) or term list (http://www.loc.gov/marc/relators/relaterm.html) are recommended for role, where applicable.

-

Where it is necessary to group responsibilities and names, multiple responsibility statements may be used. For example:

-

-

- - <titleStmt> - <title>Symphony No. 5 in C Minor : an electronic transcription</title> - <respStmt> - <resp>Encoded by</resp> - <persName role="encoder">Joe Encoder</persName> - <persName role="encoder">Jane Decoder</persName> - </respStmt> - <respStmt> - <resp>Images scanned by</resp> - <persName>Ludwig van Ludwig</persName> - </respStmt> -</titleStmt> - -
-

-

It is often desirable to mix primary and secondary intellectual responsibility information. Treating all intellectual roles the same way can allow literal transcription of existing responsibility statements and simplify programmatic processing. The following example demonstrates how a responsibility statement may be transcribed using interleaved resp and persName elements:

-

-

- - <titleStmt> - <title>Symphony No. 5 in C Minor : an electronic transcription</title> - <respStmt> - <resp>Composed by:</resp> - <persName role="composer">Ludwig van Beethoven</persName> - <persName role="encoder">Johannes Jones:</persName> - <resp>Machine-readable transcription</resp> - </respStmt> -</titleStmt> - -
-

-

However, eliminating explanatory text and relying on standardized values for role, as in the following example, allows data creation and processing tools of the greatest simplicity.

-

-

- - <titleStmt> - <title>Symphony No. 5 in C Minor : an electronic transcription</title> - <respStmt> - <persName role="composer">Ludwig van Beethoven</persName> - <persName role="editor">Johannes Jones</persName> - </respStmt> -</titleStmt> - -
-

-
-
-
- Information about an MEI file -
- File Description -

The structure of the bibliographic description of a machine-readable or digital musical text resembles that of a book, an article, or other kinds of textual objects. The file description element of the MEI header has therefore been closely modelled on existing standards in library cataloging; it should thus provide enough information to allow users to give standard bibliographic references to the electronic text, and to allow catalogers to catalog it. Bibliographic citations occurring elsewhere in the header, and in the text itself, are derived from the same model.

-

The bibliographic description of an electronic musical text should be supplied by the mandatory fileDesc element:

-

- - - -

-

The fileDesc element contains two mandatory and six optional elements, each of which is described in more detail below. These elements are listed below in the order in which they must occur within the fileDesc element.

-

- - - - - - - - - -

-

A complete file description will resemble the following example:

-

-

- - <fileDesc> - <titleStmt> - <!-- title of the resource --> - </titleStmt> - <editionStmt> - <!-- information about the edition of the resource --> - </editionStmt> - <extent> - <!-- description of the size of the resource --> - </extent> - <pubStmt> - <!-- information about the publication and distribution of the resource --> - </pubStmt> - <seriesStmt> - <!-- information about any series to which the resource belongs --> - </seriesStmt> - <notesStmt> - <!-- notes on other aspects of the resource --> - </notesStmt> - <sourceDesc> - <!-- information about the source(s) from which the resource was derived --> - </sourceDesc> -</fileDesc> - -
-

-
- Edition Statement -

The editionStmt element is the second component of the fileDesc element, following the mandatory titleStmt. It is optional but recommended when applicable.

-

- - - -

-

It contains elements for identifying the edition and those responsible for it:

-

- - - - -

-

For printed texts, the term ‘edition’ applies to the set of all the identical copies of an item produced from one master copy and issued by a particular publishing agency or a group of such agencies. A change in the identity of the distributing body or bodies does not normally constitute a change of edition, while a change in the master copy does.

-

For electronic texts, the notion of a master copy is not entirely appropriate, since they are far more easily copied and modified than printed ones; nonetheless, the term edition may be used for a particular state of a machine-readable text at which substantive changes are made and fixed. Synonymous terms used in these Guidelines are version, level, and release. The words revision and update, by contrast, are used for minor changes to a file which do not amount to a new edition.

-

No simple rule can specify how substantive changes have to be before they are regarded as producing a new edition, rather than a simple update. The general principle proposed here is that the production of a new edition entails a significant change in the intellectual content of the file, rather than its encoding or appearance. The addition of analytic coding to a text would thus constitute a new edition, while automatic conversion from one coded representation to another would not. Changes relating to the character code or physical storage details, corrections of misspellings, simple changes in the arrangement of the contents and changes in the output format do not normally constitute a new edition, whereas the addition of new information (e.g., annotations, sound or images, links to external data) almost always does.

-

Clearly, there will always be borderline cases and the matter is somewhat arbitrary. The simplest rule is: if you think that your file is a new edition, then call it such. An edition statement is optional for the first release of a computer file; it is mandatory for each later release, though this requirement cannot be enforced.

-

Note that all changes in a file, whether or not they are regarded as constituting a new edition or simply a revision, should be independently noted in the revision description section of the file header (see section ).

-

The edition element should contain phrases describing the edition or version, including the word 'edition', 'version', or an equivalent term, together with a number or date, or terms indicating difference from other editions such as 'new edition', 'revised edition', etc. Any dates that occur within the edition statement should be marked with the date element. The n attribute of the edition element may be used as elsewhere to supply any formal identification (such as a version number) for the edition.

-

One or more respStmt elements may also be used to supply statements of responsibility for the edition in question. These may refer to individuals or corporate bodies and can indicate functions such as that of a reviser, or can name the person or body responsible for the provision of supplementary matter, of appendices, etc., in a new edition.

-

Some examples follow:

-

-

- - <editionStmt> - <edition n="Draft2">Second draft, substantially extended, revised, and corrected.</edition> -</editionStmt> - -
-
- - <editionStmt> - <edition>Student's edition, - <date>June 1987</date> - </edition> - <respStmt> - <resp>New annotations by</resp> - <name>George Brown</name> - </respStmt> -</editionStmt> - -
-

-
-
- Extent of the File -

The third component of the fileDesc is a description of the physical qualities of the file. The extent element is provided for this purpose.

-

- - - -

-

The extent element describes the approximate size of a text as stored on some carrier medium, whether digital or non-digital, specified in any convenient units.

-

For printed books, information about the carrier, such as the kind of medium used and its size, are of great importance in cataloging procedures. The print-oriented rules for bibliographic description of an item’s medium and extent need some re-interpretation when applied to electronic media. An electronic file exists as a distinct entity quite independently of its carrier and remains the same intellectual object whether it is stored as file on a hard disc drive, a CD-ROM, a set of USB devices, or in the internet. Since, moreover, these Guidelines are specifically aimed at facilitating transparent document storage and interchange, any purely machine-dependent information should be irrelevant as far as the file header is concerned.

-

This is particularly true of information about file-type although library-oriented rules for cataloging often distinguish two types of computer file: ‘data’ and ‘programs’. This distinction is quite difficult to draw in some cases, for example, hypermedia or texts with built-in search and retrieval software.

-

Although it is equally system-dependent, some measure of the size of the computer file may be of use for cataloging and other practical purposes. Because the measurement and expression of file size is fraught with difficulties, only very general recommendations are possible; the element extent should contain a phrase indicating the size or approximate size of the computer file in one of the following ways:

- - in bytes of a specified length (e.g., ‘4000 bytes’) - as falling within a range of values, for example: - less than 1 Mb - between 1 Mb and 5 Mb - between 6 Mb and 10 Mb - over 10 Mb - in terms of any convenient logical units (for example, words or sentences, citations, paragraphs) - in terms of any convenient physical units (for example, compact discs, removable hard drives, DVDs) - -

The use of standard abbreviations for units of quantity is recommended where applicable, here as elsewhere (see http://physics.nist.gov/cuu/Units/binary.html).

-

-

- - <extent>between 1 MB and 2 MB</extent> -<!-- or --> -<extent>4.2 MiB</extent> -<!-- or --> -<extent>4532 Mbytes</extent> -<!-- or --> -<extent>3200 sentences</extent> -<!-- or --> -<extent>5 90-mm high density diskettes</extent> -
-

-

For ease of processability, the use of the unit attribute is recommended whenever possible, as in the following example:

-

-

- - <extent unit="byte">65535</extent> - -
-

-

The unit attribute is restricted to certain values: byte (Byte), char (Character), cm (Centimeter), deg (Degree), in (Inch), issue (Serial issue), ft (Foot), m (Meter), mm (Millimeter), page (Page), pc (Pica), pt (Point), px (Pixel), rad (Radian), record (Record), vol (Serial volume), and vu (MEI virtual unit).

-

A virtual unit (vu) in MEI is a measure of distance. It is determined by half the distance between adjacent staff lines where the interline space is measured from the middle of a staff line. Unless otherwise specified, the MEI virtual unit is set as the default unit.

-
-
- Publication, Distribution, etc. -

The pubStmt element is the fourth component of the fileDesc element and is mandatory.

-

- - - -

-

It may contain either a single unpub element, indicating that the file has yet to be published, or in the case of published material, one or more elements from the model.pubStmtPart class. The following elements may be used to provide details regarding the file’s publication and distribution:

-

- - - - - - - - - - -

-

The publisher is the person or institution by whose authority a given edition of the file is made public. The distributor is the person or institution from whom copies of the text may be obtained. Use respStmt to identify other responsible persons or corporate bodies.

-

The sub-elements of availability should be used to provide detailed information regarding access to the MEI file.

-

- - - - - - - -

-

-

- - <pubStmt xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <publisher> - <corpName>Musikwissenschaftliches Seminar &lt;Detmold&gt;</corpName> - </publisher> - <address> - <addrLine>Gartenstrasse 20</addrLine> - <addrLine>32756 - <geogName>Detmold</geogName> - </addrLine> - <addrLine> - <geogName>Germany</geogName> - </addrLine> - </address> - <date>2011</date> - <availability> - <useRestrict>© 2004, MEI Consortium</useRestrict> - </availability> -</pubStmt> - -
-
- - <pubStmt xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <publisher> - <corpName>Segno Press Inc.</corpName> - </publisher> - <distributor> - <corpName>University of Virginia</corpName> - <address> - <addrLine>221 B LowWater Street,</addrLine> - <addrLine>Charlottesville, Virginia</addrLine> - <addrLine>22901</addrLine> - </address> - </distributor> - <date>2010</date> - <identifier>1234</identifier> - <availability> - <useRestrict>Available for purposes of academic research and teaching only.</useRestrict> - </availability> -</pubStmt> - -
-

-

Give any other useful information (e.g., dates of collection of data) in an annotation within the notes statement, which is described below.

-

Here, as in the description of intellectual responsibility described above, the respStmt element may be used to contain all statements of responsibility regarding publication and distribution when uniformity is desired regardless of the role of participants in the publication process:

-

-

- - <respStmt xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <corpName role="publisher">MEI Project</corpName> - <corpName auth.uri="http://d-nb.info/gnd" - auth="GND" - codedval="2007744-0" - role="funder">German Research Foundation</corpName> - <corpName auth.uri="http://d-nb.info/gnd/18183-3" - auth="Deutsche Nationalbibliothek" - codedval="18183-3" - role="funder">National Endowment for the Humanities</corpName> -</respStmt> - -
-

-
-
- Series Statement -

The seriesStmt element is the fifth component of the fileDesc element and is optional.

-

- - - -

-

A series may be defined in one of the following ways:

- - A group of separate items related to one another by the fact that each item bears, in addition to its own title proper, a collective title applying to the group as a whole. The individual items may or may not be numbered. - Each of two or more volumes of essays, lectures, articles, or other items, similar in character and issued in sequence. - A separately numbered sequence of volumes within a series or serial. - -

The seriesStmt element may contain one or more of the following more specific elements:

-

- - - - - - - - -

-

The title, editor and identifier elements have the same function described above: identification of the item, in this case the series, and the individuals or groups responsible for its creation. The title element is required within seriesStmt.

-

-

- - <seriesStmt> - <title>MEI Sample Collection</title> -</seriesStmt> - -
-

-

The identifier element may be used to supply any identifying number associated with the series, including both standard numbers such as an ISSN and particular issue numbers. Its type attribute is used to categorize the number further, taking the value 'ISSN' for an ISSN, for example.

-

-

- - <seriesStmt> - <title level="s">Studies in Ornamentation</title> - <editor>Jacques Composeur</editor> - <identifier type="ISSN">0-345-6789</identifier> -</seriesStmt> - -
-

-

The contents of the series may be enumerated using the contents element. Use of this element should be determined by the complexity of the resource and whether or not the information is readily available. The contents element may consist of a single paragraph when unstructured information is sufficient.

-

-

- - <contents> - <p>On Wenlock Edge -- From Far, From Eve and Morning -- Is My Team Ploughing? -- Oh, - When I Was In Love With You -- Bredon Hill -- Clun - </p> -</contents> - -
-

-

Alternatively, contentItem elements may be used to provide structure for the content description.

-

-

- - <contents> - <head>Contents</head> - <contentItem>On Wenlock Edge</contentItem> - <contentItem>From Far, From Eve and Morning</contentItem> - <contentItem>Is My Team Ploughing?</contentItem> - <contentItem>Oh, When I Was In Love With You</contentItem> - <contentItem>Bredon Hill</contentItem> - <contentItem>Clun</contentItem> -</contents> - -
-

-

Finally, using the target attribute, a link to an external table of contents may be supplied in lieu of or in addition to the child elements of contents.

-

-

- - <contents target="http://www.series.content/12345"/> - -
-

-

The seriesStmt element is allowed to nest within itself in order to accommodate a series within a series.

-
-
- Notes Statement -

The notesStmt element is the sixth component of the fileDesc element and is optional. If used, it contains one or more annot elements, each containing a single piece of descriptive information of the kind treated as ‘general notes’ in traditional bibliographic descriptions.

-

- - - -

-

Some information found in the notes area in conventional bibliography has been assigned specific elements in these Guidelines; in particular the following items should be tagged as indicated, rather than as general notes:

- - the nature, scope, artistic form, or purpose of the work; also the genre or other intellectual category to which it may belong. These should be formally described within the workList element (section ). - bibliographic details relating to the source or sources of an electronic text: e.g., ‘Transcribed from a facsimile of the 1743 publication’. These should be formally described in the sourceDesc element (section ). - further information relating to publication, distribution, or release of the text, including sources from which the text may be obtained, any restrictions on its use or formal terms on its availability. These should be placed in the appropriate division of the pubStmt element (section ). - publicly documented numbers associated with the file should be placed in an altId element within the meiHead element. International Standard Serial Numbers (ISSN), International Standard Book Numbers (ISBN), and other internationally agreed upon standard numbers that uniquely identify an item, should be treated in the same way, rather than as specialized bibliographic notes. As described elsewhere, identifiers for sources of the file should be recorded within the sourceDesc. - -

Nevertheless, the notesStmt element may be used to record potentially significant details about the file and its features, for example:

- - dates, when they are relevant to the content or condition of the computer file: e.g., ‘manual dated 2010’, ‘file validated Apr 2011’ - names of persons or bodies connected with the technical production, administration, or consulting functions of the effort which produced the file, if these are not named in statements of responsibility in the title or edition statements of the file description: e.g., ‘Historical commentary provided by members of the Big Symphony Orchestra’ - availability of the file in an additional medium or information not already recorded about the availability of documentation: e.g., ‘User manual is loose-leaf in eleven paginated sections’ - language of work and abstract, if not encoded in the langUsage element, e.g., ‘Text in English with stage directions in French and German’ - -

Each such item of information may be tagged using the general-purpose annot element. Groups of annotations are contained within the notesStmt element, as in the following example:

-

-

- - <notesStmt> - <annot>Historical commentary provided by John Smith.</annot> - <annot>OCR scanning performed at University of Virginia.</annot> -</notesStmt> - -
-

-

There are advantages, however, to encoding such information with more precise elements elsewhere in the MEI header, when such elements are available. For example, the notes above might be encoded as follows:

-

-

- - <titleStmt> - <title>…</title> - <respStmt> - <persName>John Smith</persName> - <resp>historical commentary</resp> - </respStmt> - <respStmt> - <corpName>University of Virginia</corpName> - <resp>OCR scanning</resp> - </respStmt> -</titleStmt> - -
-

-
-
- Source Description -

The sourceDesc element is the seventh and final component of the fileDesc element. In MEI, sourceDesc is a grouping element containing one or more source elements, each of which records details of a source from which the computer file is derived. This might be a printed text or manuscript, another computer file, an audio or video recording, or a combination of these. An electronic file may also have no source, if what is being cataloged is an original text created in electronic form.

-

- - - - -

-

The source element may contain

-

- - - - - - - -

-
- Associating Metadata and Data -

In the MEI header, the data attribute may be used to associate metadata with related notational elements.

-

Similarly, in the body of the MEI document, the decls attribute may be used to associate parts of the encoded text with related metadata.

-

The most useful associations of this type are between the bibliographic description of a source and the material taken from it.

-
-
-
-
- Encoding Description -

The encodingDesc element is the second major subdivision of the MEI header. It specifies the methods and editorial principles which governed the transcription or encoding of the source material. Though not formally required, its use is highly recommended.

-

- - - -

-

The encoding description may contain elements taken from the model.encodingPart class. By default, this class makes available the following elements:

-

- - - - - - - - - -

-

Each of these elements is further described in the appropriate section below.

-
- Application Information -

It is sometimes convenient to store information relating to the processing of an encoded resource within its header. Typical uses for such information might be:

- - to allow an application to discover that it has previously opened or edited a file, and what version of itself was used to do that; - to show (through a date) which application last edited the file to allow for diagnosis of any problems that might have been caused by that application; - to allow users to discover information about an application used to edit the file - to allow the application to declare an interest in elements of the file which it has edited, so that other applications or human editors may be more wary of making changes to those sections of the file. - -

- - - - -

-

Each application element identifies the current state of one software application with regard to the current file. This element is a member of the att.datable class, which provides a variety of attributes for associating this state with a date and time, or a temporal range. The xml:id and version attributes should be used to uniquely identify the application and its major version number (for example, 'Music Markup Tool 1.5'). It is not intended that a software application should add a new application element each time it touches the file.

-

The following example shows how these elements might be used to record the fact that version 1.5 of an application called ‘Music Markup Tool’ has an interest in two parts of a document. The parts concerned are accessible at the URLs given as targets of the two ptr elements. When used on application, the date attribute specifies when the application was employed, in this case June 6, 2011. Version information for the application should be placed in version.

-

-

- - <appInfo> - <application isodate="2011-06-06" version="1.5" xml:id="header.MusicMarkupTool"> - <name>Music Markup Tool</name> - <ptr target="#header.P1"/> - <ptr target="#header.P2"/> - </application> -</appInfo> - -
-

-
-
- Declaration of Editorial Principles -

The editorialDecl element is used to provide details of the editorial practices applied during the encoding of a musical text.

-

It may contain a prose description only, or one or more of a set of specialized elements; that is, members of the MEI model.editorialDeclPart class.

-

Some of these policy elements carry attributes to support automated processing of certain well-defined editorial decisions; all of them contain a prose description of the editorial principles adopted with respect to the particular feature concerned. Examples of the kinds of questions which these descriptions are intended to answer are given in the list below.

- - - States how and under what circumstances corrections have been made in the text. corrlevel indicates the degree of correction applied to the text. method indicates the method employed to mark corrections and normalizations. Was the text corrected during or after data capture? If so, were corrections made silently or are they marked using the tags described in chapter ? What principles have been adopted with respect to omissions, truncations, dubious corrections, alternate readings, false starts, repetitions, etc.? - - Describes the scope of any analytic or interpretive information added to the transcription of the music. Has any analytic or ‘interpretive’ information been provided — that is, information which is felt to be non-obvious, or potentially contentious? If so, how was it generated? How was it encoded? - - Indicates the extent of normalization or regularization of the original source carried out in converting it to electronic form. method indicates the method employed to mark corrections and normalizations. Was the text normalized, for example by regularizing any non-standard enharmonic spellings, etc.? If so, were normalizations performed silently or are they marked using the tags described in chapter ? What authority was used for the regularization? Also, what principles were used when normalizing numbers to provide the standard values for the value attribute described in sections – and what format is used for them? - - Describes the principles according to which the musical text has been segmented, for example into movements, sections, etc. How is the musical text segmented? If mdiv and/or section elements have been used to partition the music for analysis, how are they marked and how was the segmentation arrived at? - - Specifies the format used when standardized date or number values are supplied. In most cases, attributes bearing standardized values should conform to a defined datatype. In cases where this is not appropriate, this element may be used to describe the standardization methods underlying the values supplied. - -

Experience shows that a full record should be kept of decisions relating to editorial principles and encoding practice, both for future users of the text and for the project which produced the text in the first instance. Any information about the editorial principles applied not falling under one of the above headings may be recorded as additional prose following the special-use elements.

-

-

- - <editorialDecl> - <segmentation> - <p>Separate mdiv elements have been created for each movement of the work.</p> - </segmentation> - <interpretation> - <p>The harmonic analysis applied throughout movement 1 was added by hand and has not - been checked. - </p> - </interpretation> - <correction> - <p>Errors in transcription controlled by using the Finale editor.</p> - </correction> - <normalization> - <p>All sung text converted to Modern American spelling following Webster’s 9th Collegiate - dictionary. - </p> - </normalization> - <p> - <!-- Other editorial practices described here. --> - </p> -</editorialDecl> - -
-

-

An editorial practices declaration which applies to more than one text or division of a text need not be repeated in the header of each text or division. Instead, the decls attribute of each text (or subdivision of the text) to which it applies may be used to supply a cross-reference to a single declaration encoded in the header.

-
-
- Project Description -

- - - -

-

The projectDesc element may be used to describe, in prose, the purpose for which a digital resource was created, together with any other relevant information concerning the process by which it was assembled or collected. This is of particular importance for corpora or miscellaneous collections, but may be of use for any text, for example to explain why one kind of encoding practice has been followed rather than another.

-

For example:

-

-

- - <encodingDesc> - <projectDesc> - <p>Texts collected for use in the MEI Summer Workshop, Aug. 2012.</p> - </projectDesc> -</encodingDesc> - -
-

-
-
- Sampling Declaration -

The samplingDecl element holds a prose description of the rationale and methods used in selecting texts, or parts of text, for inclusion in the resource.

-

- - - -

-

The samplingDecl element should include information about such matters as:

- - the size of individual samples - the method or methods by which they were selected - the underlying population being sampled - the object of the sampling procedure used but is not restricted to these. - -

-

- - <samplingDecl> - <p>Encoding contains 40 randomly-selected measures.</p> -</samplingDecl> - -
-

-

It may also include a simple description of any parts of the source text included or excluded:

-

-

- - <samplingDecl> - <p>Only the songs have been transcribed. Advertisements have been silently omitted. All - mathematical expressions have been omitted, and their place marked with a - <gi scheme="MEI">gap</gi>element. - </p> -</samplingDecl> - -
-
- - <samplingDecl> - <p>Only the first 6 measures of movement 1 are encoded.</p> -</samplingDecl> - -
-

-

A sampling declaration which applies to more than one text or division of a text need not be repeated in the header of each such text. Instead, the decls attribute of each text (or subdivision of the text) to which the sampling declaration applies may be used to supply a cross-reference to it, as further described in section .

-
-
- Class Declarations -

The classDecls element allows the declaration of generic taxonomies for the classification of entities according to one or both of the following two methods:

- - by reference to a recognized international classification scheme such as the Dewey Decimal Classification, the Universal Decimal Classification, the Colon Classification, the Library of Congress Classification, or any other system widely used in library and documentation work - by providing a set of keywords, as provided, for example, by British Library or Library of Congress Cataloguing in Publication data, or as defined by the encoder. - -

- - - -

-

Each taxonomy may have a heading and may declare any number of categories using the category element. Categories may be declared by reference to existing vocabularies or simply explained by a descriptive text.

-

-

- - <classDecls> - <taxonomy> - <head>Subject categories</head> - <category xml:id="header.LoC_lcco"> - <desc>Library of Congress subject headings. Prepared by the Cataloging - Policy and Support Office, Collections Services. Washington, D.C.: - Library of Congress, Cataloging Distribution Service, 1993- . </desc> - </category> - </taxonomy> -</classDecls> - -
-

-

The category element may or may not include a bibliographic citation and/or a URI at which the classification scheme or information about it may be found.

-

-

- - <taxonomy> - <category auth.uri="http://www.loc.gov" - auth="Library of Congress" - xml:id="header.LCSH"/> - <category auth.uri="http://www.loc.gov/aba/cataloging/classification/lcco/lcco_m.pdf" - xml:id="header.LoC_lcco"> - <desc>Library of Congress subject headings. Prepared by the Cataloging Policy and Support - Office, Collections Services. Washington, D.C.: Library of Congress, Cataloging Distribution - Service, 1993- .</desc> - </category> -</taxonomy> - -
-

-

The categories declared in the taxonomies may then be referenced to within classification by means of the class attribute as described in the section.

-
-
-
- Revision Description -

The final sub-element of the MEI header, the revisionDesc element, provides a detailed change log in which each change made to a text may be recorded. Its use is optional but highly recommended. It provides essential information for the administration of large numbers of files which are being updated, corrected, or otherwise modified as well as extremely useful documentation for files being passed from researcher to researcher or system to system. Without change logs, it is easy to confuse different versions of a file, or to remain unaware of small but important changes made in the file by some earlier link in the chain of distribution. No change should be made in any MEI-conformant file without corresponding entries being made in the change log.

-

- - - - -

-

The main purpose of the revision description is to record changes in the text to which a header is prefixed. However, it is recommended practice to include entries also for significant changes in the header itself (other than the revision description itself, of course). At the very least, an entry should be supplied indicating the date of creation of the header.

-

The log consists of a list of change elements, each of which contains a detailed description of the changes made. If a number is to be associated with one or more changes (for example, a revision number), the n attribute may be used to indicate it. The person responsible for the change and the date of the change may be indicated by the respStmt and date elements. The description of the change itself is contained within the changeDesc element, which can hold one or more paragraphs.

-

It is recommended to give changes in reverse chronological order, most recent first.

-

For example:

-

-

- - <revisionDesc> - <change n="4"> - <respStmt> - <persName>KR</persName> - </respStmt> - <changeDesc> - <p>Cleaned up MEI file automatically using Header.xsl.</p> - </changeDesc> - <date isodate="2011-12-01"/> - </change> - <change n="3"> - <respStmt> - <persName>KR</persName> - </respStmt> - <changeDesc> - <p>Cleaned up MEI file automatically using ppq.xsl.</p> - </changeDesc> - <date isodate="2011-10-21"/> - </change> -</revisionDesc> - -
-

-

A slightly shorter form for recording changes is also available when a the date of the change can be described by a single date in a standard ISO form and when the name of the agent(s) responsible for the change, encoded elsewhere in the header, can be referred to by one or more URIs given in the resp attribute. For example:

-

-

- - <change isodate="2011-10-21" n="3" resp="#KR #MH"> - <changeDesc> - <p>Cleaned up MEI file automatically using ppq.xsl.</p> - </changeDesc> -</change> - -
-

-
-
-
- Functional Requirements for Bibliographic Records (FRBR) -

MEI header information may refer to different levels of description of the encoded work: Some information may apply the work in all its various forms and realizations, e.g., the name of its composer. Other information may describe a certain version of the work, or a source such as the printed first edition, or only a single copy of that source. Core MEI limits the header information to two such levels of description: work and source, respectively.

-

However, when the FRBR module is available more detailed descriptions are possible. With certain limitations, mainly due to the musical nature of the works encoded in MEI, the FRBR module adapts the Functional Requirements for Bibliographic Records (FRBR) as recommended by the International Federation of Library Associations and Institutions (IFLA).

-

The IFLA’s FRBR model distinguishes four levels of abstraction, or entities:

- - - FRBR defines a work as a "distinct intellectual or artistic creation", an abstract entity because there is no single material object one can point to as the work. - - An expression is defined as "the intellectual or artistic realization of a work in the form of [...] notation, sound, image, object, movement, etc., or any combination of such forms". Expressions are also abstract entities. - - A manifestation is defined as "the physical embodiment of an expression of a work", including, for instance, manuscripts, books, sound recordings, films, video recordings, CD-ROMs, multimedia kits, etc. The manifestation represents all the physical objects that bear the same characteristics, with respect to both intellectual content and physical form. - - A single exemplar of a manifestation is called an item, e.g., a specific copy of a printed score. With manuscripts, item and manifestation levels are nearly identical. A manuscript may be regarded as a manifestation having only one item. - -
- FRBR Entities in MEI -

With the FRBR module, MEI offers four elements corresponding to the FRBR "Group 1" entities:

-

- - - - - - -

-

The names of the MEI entities follow those of FRBR: the work element is a container for description at the FRBR "work" level, expression is for description at the FRBR "expression" level, manifestation contains "manifestation" level description, and item holds FRBR "item" level description. Please note: Until MEI 3.0.0, the source element in sourceDesc was used for manifestation-level descriptions.

-

The work element has an optional child element to hold the expression elements:

-

- - - -

-

As expressionList is a container element for descriptions of different expressions of the same work, it may contain only

-

- expression elements.

-

The content model of expression is similar to that of work. It does not, however, permit expressionList and audience elements. But it adds elements that aid identification and description of specific versions of a work:

-

- - - - -

-

Since expressions, like works, are abstractions, their titles are often nebulous. Usually, however, the title of an expression is the same as the work it represents. When the relationship between a work and an expression is encoded hierarchically, the expression’s title element may be omitted with the assumption that it will be inherited from the work. If no title is provided for an expression, distinguishing characteristics must be provided in other elements, such as perfMedium, as in the following example:

-

-

- - <work xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <title>Pavane pour une infante défunte</title> - <expressionList> - <expression> - <title/> - <perfMedium> - <perfResList> - <perfRes>piano</perfRes> - </perfResList> - </perfMedium> - </expression> - <expression> - <title/> - <perfMedium> - <perfResList> - <perfRes>orchestra</perfRes> - </perfResList> - </perfMedium> - </expression> - </expressionList> -</work> - -
-

-

Programmatic concatenation of the work title and one or more characteristics of the expression can be used to provide identification for the expression. For example, the expressions above may be identified by "Pavane pour une infante défunte (piano)" and "Pavane pour une infante défunte (orchestra)". In some cases, it may be helpful to assign a descriptive title to the expression, as illustrated below. The carrier of the manifestation is often a good source of this kind of descriptive text.

-

-

- - <work xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <title>Pavane pour une infante défunte</title> - <expressionList> - <expression> - <title>Version for piano</title> - <perfMedium> - <perfResList> - <perfRes>piano</perfRes> - </perfResList> - </perfMedium> - </expression> - <expression> - <title>Version for orchestra</title> - <perfMedium> - <perfResList> - <perfRes>orchestra</perfRes> - </perfResList> - </perfMedium> - </expression> - </expressionList> -</work> - -
-
- - <work xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <title>Sonata No. 2</title> - <expressionList> - <expression> - <title>Live recording at Carnegie Hall</title> - </expression> - <expression> - <title>Studio recording</title> - </expression> - </expressionList> -</work> - -
-

-

The manifestationList and manifestation elements are discussed in section .

-

The itemList element provides functionality similar to that of expressionList; that is, it can be used to group descriptions of individual items (exemplars) of the parent source. Just like expressionList, which can only hold expression sub-components, itemList may only contain item elements.

-

- - - - - - -

- - <manifestation xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <titleStmt> - <title>Trois trios pour le piano-forte violon, et violoncelle</title> - </titleStmt> - <itemList> - <item label="Copy at Stanford"> - <physLoc> - <repository> - <corpName>Stanford University Library</corpName> - </repository> - </physLoc> - </item> - <item label="Copy at Dresden"> - <physLoc> - <repository> - <corpName>Dresden, Sächsische Landesbibliothek - Staats- und Universitätsbibliothek</corpName> - </repository> - </physLoc> - </item> - </itemList> -</manifestation> - -
-

-
-
- Component Parts in FRBR -

Each of the four MEI elements corresponding to FRBR entities may contain a list of constituent parts. All four entities utilize the same element:

-

- - - -

-

However, the child elements of a component group must be the same type as the group’s parent. This allows for a more detailed description than is possible using the core MEI contents element. For example, a work element’s componentList element can only contain work elements, etc. In this way, the componentList element may be employed to describe composite works, as in the example below:

-

-

- - <work xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <title>Der Ring des Nibelungen</title> - <componentList> - <work> - <title>Das Rheingold</title> - </work> - <work> - <title>Die Walküre</title> - </work> - <work> - <title>Siegfried</title> - </work> - <work> - <title>Götterdämmerung</title> - </work> - </componentList> -</work> - -
-

-

This technique can also be applied when a single intellectual source is comprised of multiple physical parts. In the following example, the choral parts were published in four physically separate "signatures":

-

-

- - <manifestation xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron" - xml:id="source.printed_choral_parts"> - <titleStmt> - <title>Printed choral parts</title> - </titleStmt> - <pubStmt> - <publisher>Horneman &amp; Erslev</publisher> - <pubPlace>Copenhagen</pubPlace> - <date isodate="1871">1871</date> - </pubStmt> - <componentList> - <manifestation> - <titleStmt> - <title>Soprani</title> - </titleStmt> - <physDesc> - <extent unit="pages">4</extent> - </physDesc> - </manifestation> - <manifestation> - <titleStmt> - <title>Alti</title> - </titleStmt> - <physDesc> - <extent unit="pages">4</extent> - </physDesc> - </manifestation> - <manifestation> - <titleStmt> - <title>Tenori</title> - </titleStmt> - <physDesc> - <extent unit="pages">6</extent> - </physDesc> - </manifestation> - <manifestation> - <titleStmt> - <title>Bassi</title> - </titleStmt> - <physDesc> - <extent unit="pages">6</extent> - </physDesc> - </manifestation> - </componentList> -</manifestation> - -
-

-
-
- FRBR Relationships -

FRBR defines a number of terms that describe how the basic entities relate to each other. MEI provides the following elements for this purpose.

-

- - - - - -

-

Each of the four FRBR entity equivalents – the work, expression, source, and item elements – allows a list of such relationship descriptions as its last child element. relationList provides a container for individual relation elements. The nature of the relationship must be specified by the rel attribute and the target of the relationship must be identified by the target attribute. The values allowed by rel follow those defined for FRBR at http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf.

-

Since relations are bidirectional, they may be defined on both entities involved, using pairs of oppositely-directed relation descriptors. The following FRBR relations are allowed in MEI as values of the relation element’s rel attribute (shown in pairs for clarity):

- - hasAbridgement / isAbridgementOf - hasAdaptation / isAdaptationOf - hasAlternate / isAlternateOf - hasArrangement / isArrangementOf - hasComplement / isComplementOf - hasEmbodiment / isEmbodimentOf - hasExemplar / isExemplarOf - hasImitation / isImitationOf - hasPart / isPartOf - hasRealization / isRealizationOf - hasReconfiguration / isReconfigurationOf - hasReproduction / isReproductionOf - hasRevision / isRevisionOf - hasSuccessor / isSuccessorOf - hasSummarization / isSummarizationOf - hasSupplement / isSupplementOf - hasTransformation / isTransformationOf - hasTranslation / isTranslationOf - -

Some of these relationships are already implicitly expressed by the MEI structural model: FRBR defines an expression entity as a realization of a work, but as this relation is implied by the expressionList element’s child relationship to its parent work element, the hasRealization/isRealizationOf relation does not need to be explicitly declared. Likewise, it is not necessary to specify by means of relation elements that an item is an exemplar of the source described by its parent source element. This resembles the FRBR model, which allows 1:n relationships both between works and expressions, and between manifestations and items.

-

However, as FRBR allows n:n relations between expressions and manifestations (in MEI: sources), a hierarchical model based on the structure of XML is clearly insufficient to express all possible expression / manifestation combinations. It is therefore required to declare these relations explicitly. In FRBR terms, a manifestation / source is an embodiment of an expression.

-

-

- - <manifestation xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <titleStmt> - <title>Score, first edition</title> - </titleStmt> - <relationList> - <relation rel="isEmbodimentOf" target="#version_for_orchestra"/> - </relationList> -</manifestation> - -
-

-

Within the componentList element, the order of child elements implicitly describes a hasSuccessor/isSuccessorOf relationship between components, i.e., it defines a certain sequence such as the movements of a work. In other cases, relation elements may be needed to explicitly encode relationships not otherwise defined by encoding order or hierarchy. For instance, the hasReproduction/isReproductionOf relationship may be used to indicate that one source is a reprint of another.

-

-

- - <manifestation xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <pubStmt> - <publisher>Horneman &amp; Erslev</publisher> - <pubPlace>Copenhagen</pubPlace> - <date isodate="1874">1874</date> - </pubStmt> - <relationList> - <relation rel="isReproductionOf" target="#source.printed_choral_parts"/> - </relationList> -</manifestation> - -
-

-

Moreover, the use of componentList implicitly defines a hasPart/isPartOf relationship between the componentList element’s parent and its child elements. Using the relationList and relation elements to define their relationship, the four component works in the "Der Ring des Nibelungen" example above could alternatively be encoded as sibling work elements to the "Ring" work element.

-

-

- - <workList xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <work xml:id="theRing"> - <title>Der Ring des Nibelungen</title> - <relationList> - <relation rel="hasPart" target="#rheingold"/> - <relation rel="hasPart" target="#walkuere"/> - <relation rel="hasPart" target="#siegfried"/> - <relation rel="hasPart" target="#goetterdaemmerung"/> - </relationList> - </work> - <work xml:id="rheingold"> - <title>Das Rheingold</title> - <relationList> - <relation rel="isPartOf" target="#theRing"/> - </relationList> - </work> - <work xml:id="walkuere"> - <title>Die Walküre</title> - <relationList> - <relation rel="isPartOf" target="#theRing"/> - </relationList> - </work> - <work xml:id="siegfried"> - <title>Siegfried</title> - <relationList> - <relation rel="isPartOf" target="#theRing"/> - </relationList> - </work> - <work xml:id="goetterdaemmerung"> - <title>Götterdämmerung</title> - <relationList> - <relation rel="isPartOf" target="#theRing"/> - </relationList> - </work> -</workList> - -
-

-

Relations may also be used to point to external resources. For instance, each of the individual component works of the "Ring" could be encoded in separate files, with relations pointing to them.

-

In the file "ring.xml":

-

-

- - <workList xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <work> - <title>Der Ring des Nibelungen</title> - <relationList> - <relation rel="hasPart" target="rheingold.xml"/> - <relation rel="hasPart" target="walkuere.xml"/> - <relation rel="hasPart" target="siegfried.xml"/> - <relation rel="hasPart" target="goetterdaemmerung.xml"/> - </relationList> - </work> -</workList> - -
-

-

In the file "rheingold.xml":

-

-

- - <workList xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <work> - <title>Das Rheingold</title> - <relationList> - <relation rel="isPartOf" target="ring.xml"/> - </relationList> - </work> -</workList> - -
-

-
-
- RelatedItem vs. FRBR -

MEI offers two related concepts for capturing relations between bibliographic items. The model of relatedItem, as described in chapter of these Guidelines, is derived from MODS v3.4 (see documentation here). Its purpose in MEI is to encode bibliographic references between mostly "secondary" material, like reviews, articles, and so on. It may be used to provide cross-references between information encoded in different places of the header.

-

However, relatedItem is less ideal for describing the relations between works, differing versions of these works, the sources in which those versions are transmitted, and where applicable the individual copies of a print. For these situations, it is strongly recommended to use the instead. This module is based on the Functional Requirements for Bibliographic Records, as specified by the IFLA. It allows a much finer description of relationships between such "primary" entities. For compatibility reasons, both models should not be confused or mixed under any circumstances.

-
-
-
- Work Description -

The workList element is the third major subdivision of the MEI Header. It is an optional element, the purpose of which is to enable the recording of information characterizing various descriptive aspects of the abstract work.

-

- - - -

-

Within workList, the work element is used to hold information for each resource being described.

-

- - - -

-

All the components of work are optional, but they must occur in the following order:

- - - identifier - - - title - - Responsibility-like elements including composer, lyricist, contributor and others - - incip - - - key - - - mensuration - - - meter - - - tempo - - - otherChar - - - history - - - langUsage - - - perfMedium - - - audience - - - contents - - - context - - - biblList - - - notesStmt - - - classification - - -
- Work Identification -

The following elements provide minimal identifying information for the intellectual work:

-

- - - - - - - - - - - - - -

-

The identifier and title values recorded here may or may not be the same as those assigned to published versions of the work. Fuller details are available in section .

-
-
- Incipits -

- - - -

-

The first few notes and/or words of a piece of music are often used for identification purposes, especially when the piece has only a generic title, such as "Sonata no. 3". They appear in catalogs of music and in tables of contents of printed music that include multiple works.

-

The following elements are provided for the inclusion of incipits:

-

- - - - - -

-

The elements incipCode and incipText are available for the inclusion of coded incipits of music notation and textual incipits, respectively. The incipText element should contain only the initial performed text of the work, while incipCode may contain both words and music, depending on the capabilities of the scheme used to encode it. When both music and text are provided in incipCode, it may be helpful to repeat the text in incipText in order to provide easier access to only the text, for example, for indexing of the text without having to extract it from the coded incipit.

-

Both incipCode and incipText allow reference to an external file location via the target attribute and specification of the internet media type of the external file via the mimetype attribute.

-

An MEI-encoded incipit may be captured in a score sub-element.

-

In addition, graphic may be used as a sub-element of incip to include an image of an incipit.

-

To facilitate the capture of metadata associated with an incipit, MEI allows the following sub-elements within incip. The order of their presentation below follows the order in which they must appear in this context.

-

- - - - - - - - - - - - -

-

Usually, the metadata captured in this manner is rendered alongside or in lieu of a coded or graphical incipit. It may or may not serve in a work identification capacity, depending on whether the incipit is intended to represent the entire work or a segment of the work. For example, if an incipit is provided for each aria in an opera, then the metadata pertains only to the aria, not the entire work.

-
-
- Key, Tempo, and Meter -

The attributes key, tempo, and meter are often helpful for identifying a musical work when it does not have a distinctive title.

-

- - - - - - -

-

The key element is used exclusively within bibliographic descriptions. Do not confuse this element with keySig, which is used within the body of an MEI file to record this data for musical notation. Likewise, meter should not be confused with the attributes used by staffDef and scoreDef to record meter-related data for notated music. The tempo element can be used here as well as in the body of an MEI document; however, its attributes other than xml:id, label, n, base, and lang are meaningless in the MEI header context, and therefore should be avoided within a work description. The mensuration element is available for the description of works in the mensural repertoire. When a work uses meter and mensural signs, both mensuration and meter elements may be used.

-
-
- Other Identifying Characteristics -

Additional information that aids the identification of the work may be encoded using otherChar.

-

- - - -

-

The following components provide detailed information about the work’s context, including the circumstances of its creation, the languages used within it, high-level musical attributes, performing forces, etc.

-
-
- Work History -

The following elements are provided to capture the history of a musical work:

-

- - - - - - -

-

The creation element is intended to contain a brief, machine-processable statement of the circumstances of the work’s creation. Its content is limited to text and the date and geogName elements.

-

The history element is a container for additional non-bibliographic details relating to a work. It may use the eventList element to provide a list of key events in the creation and performance history of the work. The eventList element is comprised of event elements containing a brief description of the associated event, including dates and locations where the event took place. An event list may use the type attribute to distinguish between multiple event lists with different functions, such as a list of events in the compositional process and a list of performance dates.

-

Event lists and other text components, such as paragraphs, tables, lists, and text divisions (div) may be interleaved when an 'essay-like' work history is desired.

-

The event element permits either a text-centric or a data-centric model. The text-centric model is provided for prose descriptions, while the data-centric model accommodates event descriptions that consist of a collection of descriptive phrases. In the text-centric model, paragraphs, tables, and lists may be used. In the data-centric model, however, only certain phrase-level elements, may appear.

-
-
- Language Usage -

The langUsage element is used within the workList element to describe the languages, sublanguages, dialects, etc. represented within a work. It contains one or more language elements, each of which provides information about a single language.

-

- - - - -

-

A language element may be supplied for each different language used in a document. If used, its xml:id attribute should specify an appropriate language identifier. This is particularly important if extended language identifiers have been used as the value of xml:lang attributes elsewhere in the document.

-

Here is an example of the use of this element:

-

-

- - <langUsage> - <language xml:id="fr-CA">Québecois</language> - <language xml:id="en-CA">Canadian English</language> - <language xml:id="en-GB">British English</language> -</langUsage> -<!-- Later in the document --> -<verse n="1" xml:lang="fr-CA"></verse> -<verse n="2" xml:lang="en-CA"></verse> -<verse n="3" xml:lang="en-GB"></verse> -
-

-
-
- Performance Medium -

The following elements are available for description of a composition’s performing forces:

-

- - - - - -

-

The perfMedium element provides the possibility of describing a work in terms of its medium of performance; that is, the performing forces required. In the case of a dramatic work, the dramatis personae and associated voice qualities may be enumerated using castList. The perfResList element describes the necessary instrumental and vocal resources.

-
- Cast Lists -

A cast list is a specialized form of list, conventionally found at the start or end of a dramatic work, usually listing all the speaking/singing and non-speaking/singing roles in the play, often with additional description (‘Cataplasma, a maker of Periwigges and Attires’) or the name of an actor or actress (‘Old Lady Squeamish. Mrs Rutter’).

-

- - - - - -

-

Cast lists often function as identifying metadata and for this reason are permitted within the description of a work.

-

Because the format and internal structure of cast lists are unpredictable, a castList may contain any combination of castItem and castGrp elements.

-

A castItem element may contain any mixture of text and the following elements:

-

- - - - - -

-

In the following example, role provides the name of the dramatic character and roleDesc contains a brief description of the role. The perfRes element is used to describe the voice range of the role.

-

-

- - <castList xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <castItem> - <role>Ursula</role> - <roleDesc>Queen of the Britons</roleDesc> - <perfRes>Soprano</perfRes> - </castItem> - <castItem> - <role>Dersagrena</role> - <roleDesc>Handmaiden to Ursula</roleDesc> - <perfRes>Mezzo-Soprano</perfRes> - </castItem> - <castItem> - <role>Fingal</role> - <roleDesc>King of the Britons</roleDesc> - <perfRes>Baritone</perfRes> - </castItem> -</castList> - -
-

-

The vocal qualities and associated roles for Beethoven’s opera Fidelio may be encoded as:

-

-

- - <perfMedium> - <castList> - <castItem> - <perfRes>Tenor</perfRes> - <role>Florestan</role> - </castItem> - <castItem> - <perfRes>Soprano</perfRes> - <role>Leonore</role>, - <roleDesc>his wife</roleDesc> - </castItem> - <castItem> - <perfRes>Bass</perfRes> - <role>Rocco</role>, - <roleDesc>gaoler</roleDesc> - </castItem> - <castItem> - <perfRes>Soprano</perfRes> - <role>Marzelline</role>, - <roleDesc>his daughter</roleDesc> - </castItem> - <castItem> - <perfRes>Tenor</perfRes> - <role>Jaquino</role>, - <roleDesc>assistant to Rocco</roleDesc> - </castItem> - <castItem> - <perfRes>Bass-baritone</perfRes> - <role>Don Pizarro</role>, - <roleDesc>governor of the prison</roleDesc> - </castItem> - <castItem> - <perfRes>Bass</perfRes> - <role>Don Fernando</role>, - <roleDesc>King's minister</roleDesc> - </castItem> - </castList> -</perfMedium> - -
-

-

The castItem element may also contain:

-

- - - -

-

However, this element is unlikely to be useful in the context of a work description. It may be used here, however, for the very rare occasion when a work was conceived for and is only performable by a single person or group, as for certain "performance art" works.

-

It is common to find some roles presented in groups or sublists. Roles are also often grouped together by their function. To accommodate these situations, the castGrp element is provided as a component of castList. It may contain any combination of castItem, castGrp, and roleDesc elements.

-
-
- Instrumentation -

The perfResList element is used to capture the solo and ensemble instrumental and vocal resources of a composition. For example, a work for a standard ensemble may be indicated thus:

-

-

- - <perfMedium> - <perfResList> - <perfRes>Orchestra</perfRes> - </perfResList> -</perfMedium> - -
-

-

The detailed make-up of standard and non-standard ensembles may also be enumerated:

-

-

- - <perfMedium> - <perfResList> - <head>Orchestration</head> - <perfRes>Flute</perfRes> - <perfRes>Oboe</perfRes> - <perfRes>English Horn</perfRes> - <perfRes>2 Horns in D</perfRes> - <perfRes>Strings</perfRes> - </perfResList> -</perfMedium> - -
-

-

Where multiple instruments of the same kind are used, the count attribute on perfRes may be used to encode the exact number of players called for.

-

-

- - <perfMedium> - <perfResList> - <!-- concert band --> - <perfRes count="2">Piccolo</perfRes> - <perfRes count="2">Flute</perfRes> - <perfRes count="3">1st Clarinet</perfRes> - <perfRes count="3">2nd Clarinet</perfRes> - <perfRes count="3">3rd Clarinet</perfRes> - <!-- and so on --> - </perfResList> -</perfMedium> - -
-

-

Instrument or voice specifications may be grouped using the perfResList element and a label assigned to the group with

-

- head. For example:

- - <perfMedium> - <perfResList> - <!-- concert band --> - <perfResList> - <head>Woodwinds</head> - <perfRes count="2">Piccolo</perfRes> - <perfRes count="2">Flute</perfRes> - <perfRes count="3">1st Clarinet</perfRes> - <perfRes count="3">2nd Clarinet</perfRes> - <perfRes count="3">3rd Clarinet</perfRes> - <!-- etc. --> - </perfResList> - <perfResList> - <head>Brass</head> - <perfRes count="3">1st Trumpet</perfRes> - <perfRes count="3">2nd Trumpet</perfRes> - <perfRes count="3">3rd Trumpet</perfRes> - <!-- etc. --> - </perfResList> - <!-- and so on --> - </perfResList> -</perfMedium> - -
-
- - <perfMedium xmlns="http://www.music-encoding.org/ns/mei" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron"> - <perfResList> - <perfResList> - <head>Woodwinds</head> - <perfRes codedval="wa" count="2">2 Flutes - <perfRes codedval="wz">(2. piccolo)</perfRes> - </perfRes> - <perfRes codedval="wc" count="1">1 Oboe</perfRes> - <!-- ... --> - </perfResList> - <perfResList> - <head>Strings (8-6-4-4-2)</head> - <perfRes count="8">Violin 1</perfRes> - <perfRes count="6">Violin 2</perfRes> - <perfRes count="4">Viola</perfRes> - <perfRes count="4">Violoncello</perfRes> - <perfRes count="2">Double Bass</perfRes> - </perfResList> - </perfResList> -</perfMedium> - -
-

-

The preceding example also demonstrates how instrumental doublings can be accommodate through the use of nested perfRes elements. Only the outer-most perfRes element should use the count attribute. Its value should reflect the total number of performers, not the number of instruments played.

-

The perfRes element provides the codedval attribute, which can be used to record a coded value that represents the string value stored as the element’s content. It is recommended that coded values be taken from a standardized list, such as the International Association of Music Libraries' Medium of Performance Codes List or the MARC Instruments and Voices Code List.

-

-

- - <perfMedium> - <perfResList> - <!-- @codedval contains values from the MARC Instruments and Voices Code List --> - <perfRes codedval="ba">Horn</perfRes> - <perfRes codedval="bb">Trumpet</perfRes> - <perfRes codedval="bd">Trombone</perfRes> - </perfResList> -</perfMedium> - -
-

-

Solo parts may be marked with the solo attribute of perfRes, like so:

-

-

- - <perfResList> - <perfRes solo="true">Violin</perfRes> - <perfRes>Violin</perfRes> - <perfRes>Violin</perfRes> - <perfRes>Viola</perfRes> - <perfRes>Violoncello</perfRes> -</perfResList> - -
-

-

Music for a single player does not have to be marked as solo with the solo attribute.

-

An ad libitum part, i.e., not essential for the performance of the work, may be marked with the adlib attribute.

-

-

- - <perfResList> - <perfRes>Soprano</perfRes> - <perfRes>Alto</perfRes> - <perfRes>Tenor</perfRes> - <perfRes>Bass</perfRes> - <perfRes adlib="true">Organ</perfRes> -</perfResList> - -
-

-
-
-
- Audience and Context -

- - - - -

-

The intended audience for the work and additional information about context for the work that is not captured in more specific elements elsewhere, such as history and its sub-components, may be recorded in the audience and context elements.

-
-
- Work Contents -

- - - - -

-

Often, it is helpful to identify an entity by listing its constituent parts. A simple description of the work’s content, such as may be found in a bibliographic record, can be given in single paragraph element:

-

-

- - <contents> - <p>A suitable tone ; Left hand colouring ; Rhythm and accent ; Tempo ; Flexibility ; - Ornaments - </p> -</contents> - -
-

-

Alternatively, a structured list of contents may be constructed using the contentItem element:

-

-

- - <contents> - <contentItem>Sonata in D major, op. V, no. 1 / Corelli</contentItem> - <contentItem>Sonata in G minor / Purcell (with Robert Donington, gamba)</contentItem> - <contentItem>Forlane from Concert royal no. 3 / Couperin</contentItem> -</contents> - -
-

-

Each contentItem element may be preceded by an optional label:

-

-

- - <contents> - <label>1</label> - <contentItem>Sonata in D major, op. V, no. 1 / Corelli</contentItem> - <label>2</label> - <contentItem>Sonata in G minor / Purcell (with Robert Donington, gamba)</contentItem> - <label>3</label> - <contentItem>Forlane from Concert royal no. 3 / Couperin</contentItem> -</contents> - -
-

-

To reference a contents list in an external location, use the target attribute:

-

-

- - <contents target="http://www.contentProvider.org/toc/toc01.html"/> - -
-

-

To facilitate the creation of music catalogs based on MEI header information, contents may contain a heading:

-

-

- - <contents> - <head>Contents of this Work:</head> - <contentItem>Sonata No. 1</contentItem> - <contentItem>Sonata No. 2</contentItem> - <contentItem>Sonata No. 3</contentItem> -</contents> - -
-

-
-
- Bibliographic Evidence -

- - - -

-

The biblList element allows citation of bibliographic evidence supporting assertions made within other sub-components of the work description.

-
-
- Notes Statement -

The notesStmt element may be used within the description of the musical work to capture information not accounted for by the other elements of the description.

-
-
- Classification -

Within work, the classification element is used to classify the work according to some classification scheme. More generally, classification may be used to classifiy any FRBR entity (work, expression, manifestation, or item). The following elements are provided for this purpose:

-

- - - - -

-

The termList element categorizes the parent entity by supplying a set of terms which may describe its topic or subject matter, its physical or intellectual form, date, etc. Each term is indicated by a term element. In some schemes, the order of items in the list is significant, for example, from major topic to minor; in others, the list has an organized substructure of its own. No recommendations are made here as to which method is to be preferred. Wherever possible, such terms should be taken from a recognized source. In its simplest form, the term element just contains a descriptive keyword.

-

-

- - <termList> - <term>motet</term> -</termList> - -
-

-

The class attribute may be used on each term element to make reference to a classification scheme (declared in the classDecls element) from which it is drawn.

-

-

- - <classification> - <termList> - <term class="#header.LCSH">Guitar music (Rock)</term> - <term class="#header.LCSH">Rock music 1971-1980.</term> - <term class="#header.LoC_lcco">M1630.18.Z26 O6 2011</term> - </termList> -</classification> - -
-

-

Alternatively, class may be used on termList when all the contained terms come from the same source.

-

-

- - <classification> - <termList class="#header.LCSH"> - <term>Guitar music (Rock)</term> - <term>Rock music 1971-1980.</term> - </termList> - <termList class="#header.LoC_lcco"> - <term>M1630.18.Z26 O6 2011</term> - </termList> -</classification> - -
-

-
-
- Work Relationships -

When the FRBR (Functional Requirements for Bibliographic Records) module is available, the following elements may be used within work to describe relationships between the work being described and other works or between the work and expressions of it:

-

- - - - - -

-

For more information about FRBR and the use of these elements, see chapter .

-
-
-
- Encoding Sources in MEI -

The manifestation and item elements allow detailed description of various types of sources, for instance, a printed text or manuscript, another computer file, an audio or video recording, or a combination of these. Both manifestation and item are part of the implementation in MEI. Please note: in MEI 3.0.0, the source element was used to capture this type of information. The manifestation element may contain the following elements:

-

- - - - - - - - - - - - - - - - - - - - - - - -

-

The content of the item element is quite similar to the manifestation element. The item element is used to describe a single item. This information can differ from the description at the manifestation level or can be additional information. The following elements may be used:

-

- - - - - - - - - - - - - -

-

Many of these elements are already described in chapter , especially in .

-

The manifestationList is available to create lists of physical sources representing a work, for instance for use in a thematic catalog or a critical edition. The manifestation child element corresponds to the level of the same name, that is, it describes embodiments of certain expressions of a work. The list below reflects the order in which the optional components of manifestation must occur. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
- Manuscripts and Prints -
- Condition and Statement of Production -

- - - - -

-

- - - -

-

The element condition may contain either plain text or elements that can be used to structure the description (e.g., for linking) in order to describe the state or condition of a source.

-

The highest hierarchical level to describe the condition, in general, is at physDesc. For a detailed description of special interest, the element condition can also be used on lower hierarchical levels (see section “contained by” in the element definition).

-

The condition element as a direct child of physDesc should be used to describe the condition of a source. To describe the condition of parts of a source (e.g., the binding) the condition element can also be used for a detailed description of that aspect (e.g., within binding ). The detail provided, and the structure of these descriptions, depend on your own encoding guidelines.

-

- -

-

A colophon is an inscription at the end of a text, similar to the modern practice of providing an imprint at the beginning of a book. Providing a colophon was a common practice in medieval manuscripts and early prints, and often contains information about the place and year of publication, and sometimes about the printer or printing workshop. It may also contain information about the author or notes from the author to the reader.

-
-
- Title Pages -

A specialized element is furnished for the capture of title page information.

-

- - - -

-

The titlePage element, modelled after a similar element in the Encoded Archival Description (EAD), may occur within the textual matter preceding or following the musical content of the encoding. Since a diplomatic transcription of the title page is often necessary to accurately identify musical material contained within a source, the titlePage element may also be used within the metadata header as a child of the physDesc element.

-

Detailed analysis of the title page and other preliminaries of older printed books and manuscripts is of major importance in descriptive bibliography and the cataloging of printed books. The following elements are suggested as a means of encoding the major features of most title pages for faithful rendition:

-

- - - - - - - - -

-

The following example shows the encoding of the title page of Vaughan Williams' On Wenlock Edge. Note the use of the lb element to mark the line breaks present in the original.

-

-

- - <titlePage> - <p>ON WENLOCK EDGE</p> - <p>A CYCLE OF SIX SONGS<lb/> - FOR TENOR VOICE ___ WITH ACCOMPANIMENT OF<lb/> - Pianoforte and String Quartet (ad lib)<lb/> - THE WORDS BY A. E. HOUSMAN<lb/> - (FROM "A SHROPSHIRE LAD") - </p> - <p> - <fig/> - </p> - <p>MUSIC BY<lb/> - R. VAUGHAN<lb/> - WILLIAMS - </p> - <list> - <li>PRICE $3.75</li> - <li>(COMPLETE WITH SET OF STRING PARTS $5.00</li> - <li>STRING PARTS SEPARATELY $1.00</li> - </list> - <p>Boosey &amp; Hawkes, Inc.</p> - <p>New York, U.S.A.</p> - <p>London · Toronto · Sydney · Capetown</p> -</titlePage> - -
-

-

The physical appearance of title page information is often of considerable importance. One approach to capturing the appearance is to use the rend element, described in chapter to specify the placement of each of the components of the title page. Another would be to employ a CSS stylesheet. Finally, a module customized for the description of typographic entities such as pages, lines, rules, etc., bearing special-purpose attributes to describe line-height, leading, degree of kerning, font, etc. could be employed.

-
-
- Physical Properties -

The physical properties of a manifestation can be described using the following elements:

-

- - - - - - - - - -

-

Encoding the extent and dimensions of a source:

-

- -

-

The element extent is used to express size in units such as ‘number of pages’, ‘number of folios’, ‘records’, ‘bytes’, ‘physical components’, etc. For specifying the physical dimensions of the material—for example, height and width—the use of the dimensions element is recommended.

-

-

- - <physDesc> - <extent>4 pages</extent> - <!-- or more machine readable --> - <extent unit="page" quantity="4"/> -</physDesc> - -
-

-

- -

-

The dimensions contain information about the physical size of a source. Usually the dimensions are represented by numerical data. The elements height, width, depth, and dim are available for circumstances that require the capture of individual dimensions. To indicate the quantity of the described materials, please refer to the extent element.

-

-

- - <physDesc> - <dimensions unit="mm"> - <height>333</height> - <width>290</width> - </dimensions> -</physDesc> - -
-

-

- -

-

Another way of encoding dimensional information about a source is to use the element dim, which can be used to represent any dimensional specification in a generic way. The attribute form is required. With regard to structured metadata, the use of the height, width, and depth elements as the content of dim is advisable.

-

-

- - <physDesc> - <dimensions> - <dim form="height" unit="mm">333</dim> - <dim form="width" unit="mm">290</dim> - </dimensions> -</physDesc> - -
-

-

- -

-

The element watermark can be used to describe watermarks or similar devices of filigranology. It is important to distinguish whether the watermark to be described consists of only one sign or is composed of main and countermarks. The completeness of the watermark, its positioning on the page, and the time period of the paper's production and use also play a role.

-

It is recommended to use at least the elements title, date, annot and locus in the description:

-

-

- - <watermark> - <title>Welhartiz</title> - <date label="usage" startdate="1815" enddate="1816">1815–1816</date> - <annot>Wappenschild mit Schrägbalken, darüber Lilie, darunter Beizeichen IAA (J sieht aus wie I!), Gegenmarke Schriftzug: „WELHARTIZ”.</annot> - <locus>[position on the page, where you found the watermark]</locus> -</watermark> - -
-

-

For a more detailed description or encoding of a watermark, fig can be used, which on the one hand allows reference to an existing image (graphic) of the watermark, and on the other increases the depth of the description. To mark up different components of a watermark, several heraldry elements can be used in a figDesc and related to each other by means of relation. -

-

-

- - <fig> - <graphic mimetype="images/jpeg" target="../"/> - <figDesc> - <heraldry type="main" xml:id="watermark_ID_01-01"> - <annot> - <p>Wappenschild mit Schrägbalken, darüber Lilie, darunter Beizeichen IAA (J sieht aus wie I!)</p> - </annot> - <relation rel="hasCountermark" target="#watermark_ID_01-02"/> - </heraldry> - <heraldry type="countermark" xml:id="watermark_ID_01-02"> - <annot> - <p>Gegenmarke Schriftzug: „WELHARTIZ”</p> - </annot> - <relation rel="isCountermarkOf" target="#watermark_ID_01-01"/> - </heraldry> - </figDesc> -</fig> - -
-

-

To ensure that the description of the pictorial signs conforms to international standards and that the individual components of the watermark are correctly represented, the multilingual description catalogue of the Bernstein project or the IPH standard should be consulted. To refer to already existing databases with watermarks, see . -

-

- -

-

Stamps can appear in many forms in manuscripts and prints, for example as library stamps, library signatures, postmarks, ownership marks, address stamps or legal notices. The description of the stamp therefore depends on individual, project-specific requirements. However, it is helpful to first consider whether it is sufficient to merely name the occurring stamps, or wether it is also desirable to detail their form and textual elements, or even refer to a graphic that shows a facsimile of the stamp.

-

-

- - <stamp>* The * Library * of * Congress *</stamp> -or -<stamp> - SUPPL. <heraldry>[Austrian coat of arms with double-headed eagle]</heraldry> MUS. <lb/><identifier label="shelfmark">No. 3177</identifier> ❋ -</stamp> -or -<stamp> - <ptr target="../berlin_SPKB_stamp.jpg"/> -</stamp> - -
-

-

In any case, for a better structuring of the information as well as for better machine readability, it is recommended to identify within the description of the stamp the implicitly or explicitly mentioned persons or institutions by means of persName or corpName and to describe by locus where the stamp is positioned on the page.

-

-

- - <stamp> - <locus>Fol. 1, 2, 3 each recto in lower left corner.</locus> - <corpName auth="GND" auth.uri="https://d-nb.info/gnd/" codedval="35626-8">Library of Congress</corpName> - <ptr target="../loc_stamp.jpg"/> -</stamp> - -
-

-

A higher level of distinction is also recommended for address stamps:

-

-

- - <stamp> - <address> - <addrLine><persName>Arnold Schönberg</persName></addrLine> - <addrLine><geogName>Wien</geogName></addrLine> - <addrLine><street>IX. Liechtensteinstraße 68/70</street></addrLine> - </address> -</stamp> - -
-

-

- -

-

The scoreFormat element is a form of classification. This element is part of physDesc because within the MARC21 standard, the format of the music (score, piano score, etc.) is defined as a physical property.

-

For describing the scoreFormat a standard value list can be used, e.g., MARC21 (see “20 - Format of music (006/03)”, https://www.loc.gov/marc/bibliographic/bd008m.html) or RDA (see https://www.rdaregistry.info/termList/formatNoteMus/). The values can be kept using the attributes authority and authURI.

-

-

- - <scoreFormat auth="RDA" auth.uri="http://www.rdaregistry.info/termList/formatNoteMus/#" codedval="1001">choir book</scoreFormat> -
-

-

If those value lists are not sufficient, however, it is recommended to design your own classification (see classification).

-

scoreFormat can similarly be used for classification in expression.

- -
-
- Binding Description -

- - - - -

-
-
- Description of Folia -

While many other elements within physDesc describe specific features of manuscripts and prints in prose, foliaDesc is intended to provide a structured description. It provides information about the collation of the manuscript; that is, how the individual leaves are bound and related to each other, and how the groups of bound leaves ("quires" or "gatherings") are related. Typically this uses these elements:

-

- - - - - -

-

The nesting of bifolium and folium elements reflects the nesting of paper sheets that make up the text block of the source. For instance, if a manuscript consists of two folded sheets of paper, with a single, unfolded sheet in the middle, this would be encoded with two nested bifolium elements, where the inner one has an additional folium element:

-

-

- - <foliaDesc> - <bifolium><!-- outer sheet --> - <bifolium><!-- inner sheet --> - <folium/> - <!-- single leaf in the middle --> - </bifolium> - </bifolium> -</foliaDesc> - -
-

-

-

- Nesting of two bifolia and one folium - -
-

-

Multiple signatures (groups of nested pages, also known as "gatherings" or "quires") bound together can be reflected by encoding a sequence of bifolium elements (with their respective contents). If the binding of a source is unknown, but foliaDesc is needed for other reasons, it is recommended to use a sequence of folium elements only, with no indication of nesting at all.

-
- Linking surface elements -

The surface element and it's children are used to relate musical content with digitizations and specific image zones on them (see ). surface elements are always encoded in sequence within facsimile, and thus lack the expressiveness of foliaDesc. However, it is possible to relate these two concepts.

-

- folium offers two specific attributes:

-

- - - - -

-

These attributes are used to point to the xml:id of a surface element.

-

-

- Positional attributes on folium and bifolium - -
-

-

On bifolium, the corresponding attributes are:

-

- - - - - - -

-

With those attributes, page numbers can be derived from foliaDesc, alongside the information where the content on a given surface is placed on a (bi)folium. Coming back to the example above this might look like so:

-

-

- - <foliaDesc> - <bifolium outer.recto="#surface-p1" - inner.verso="#surface-p2" - inner.recto="#surface-p9" - outer.verso="#surface-p10"> - <bifolium outer.recto="#surface-p3" - inner.verso="#surface-p4" - inner.recto="#surface-p7" - outer.verso="#surface-p8"> - <folium recto="#surface-p5" verso="#surface-p6"/> - </bifolium> - </bifolium> -</foliaDesc> - -
-

-
-
- Specifying page dimensions -

Within surface, each graphic element may specify its dimensions using the following attributes:

-

- - - - -

-

The values of those attributes, however, specify the height and width of the digital resource, the scan of the source, and they are typically given in pixels (see ). In contrast, folium and bifolium may provide the dimensions of the original source in physical units, such as centimetres or inches. This makes it possible to combine separate parts of a manuscripts stored in different libraries, which are scanned at different resolutions. In case of bifolium elements, these dimensions apply to the folded sheet.

-

Some printed scholarly editions like the Neue Bach-Ausgabe provide very detailed information about the sizes and binding of individual leaves of a manuscript. With foliaDesc and its children it is possible to capture that information, even without providing digitizations of the sources via surface.

-
-
- Patches -

Sometimes, manuscripts (but also prints) are subject to modifications that do not change the textual content, but the actual physical item. Typical examples for this are patches glued on a page, or cutouts. Both these situations can be encoded inside foliaDesc.

-

A patch is an additional writing surface attached to one of the sides of a folium or bifolium:

-

- - - -

-

The patch element is placed inside the folium or bifolium to which it is attached. To which side of this parent it is attached is specified using the (required) attached.to attribute:

-

- - - -

-

Depending on the parent, allowed values for attached.to are either recto and verso (in case of folium) or outer.recto, inner.verso, inner.recto and outer.verso (in case of bifolium).

-

The exact position of the patch on the underlying surface may be specified using the optional x and y attributes, which are used to specify the distance from the upper left corner of the patch from the upper left corner of the surface it is attached to. At this point, it is not possible to specify rotation.

-

The (optional) attached.by attribute specifies by which means the patch is attached. Suggested values are: glue (patch is glued on surface beneath), thread (patch is sewn on surface beneath), needle (patch is pinned to the surface beneath), tape (patch is taped on surface beneath using an adhesive strip) and staple (patch is attached on surface beneath using a staple), but other values may be used as necessary.

-

While the patch element provides information about the attachment of a patch, the actual patch is encoded as a folium or bifolium child of patch.

-

-

- - <bifolium> - <patch attached.to="inner.verso" x="1cm" y="12cm" attached.by="glue"> - <folium width="8cm" height="2cm"/> - </patch> -</bifolium> - -
-

-

-

- Positioning and sizing of a patch - -
-

-

The example above describes a bifolium where a patch is glued to the inner right side.

-
-
- Cutouts -

- - - -

-

Cutouts are treated almost similarly as . The most relevant attributes are:

-

- - - - -

-

The dimensions (width, height) of the parent element (e.g., folium) indicate the size of the bounding box of the remaining part of the page. That is, if the complete lower half of a page has been cut, the width and height attributes describe the remaining upper half. If, in contrast, only the lower right quarter of the page has been cut, these attributes still indicate the size of the full page (assuming that the removed section was a regular rectangle).The dimensions (width, heigh) on cutout itself are only to be used when there is a "gap" in the manuscript that allows to specify the dimensions of that missing part. In this case, the bounding box dimensions are given, together with x and y to indicate the upper left point on the original page. If, however, the removed section is available by itself, then a corresponding folium (or bifolium) should be placed inside the cutout element, and should provide it's own dimensions using width and height there. In this case, width and height on cutout is expendable.

-

The genetic aspect of applying patches or cutting out parts of a page is described in .

-
-
-
- Description of Layout and Support -

- - - - -

-
-
- Description of Script -

- - - -

-
-
- Additional Elements for Source Description -
- Printed Sources -

- - - - -

-

The dating of printed sources can help establish a history of the source, its provenance, and edition. In the absence of bibliographical information, e.g., on the edition or the year of origin, plate numbers can be an essential aid to dating. Plate numbers are designations assigned to a resource by a music publisher, and have no specific structure so may contain letters, numbers, punctuation, or other marks. When present, they are typically printed at the bottom of each page, and sometimes appear on the title page as well. In MEI plate numbers can be encoded within the plateNum element as plain text, similar to:

-

-

- - <plateNum>A &amp; P. No. 6412</plateNum> -
-

-

For captureMode see .

-
-
- Handwriting, Additions, Accompaning -

- - - - - -

-

In documents (handwritten or printed) there can be various kinds of entries, additions, corrections, marginalia and revisions; all these interventions in the “original” manuscript can be documented under addDesc. However, it is important to understand that these are not additions to the musical text directly. These additions to the document can come from the composer himself, copyists, typesetters, publishers, previous owners, or librarians. These entries are usually indicated in the continuous text with an indication of the location within the document as well as the means of writing used. E.g. “Auf fol. 109v links mit Bleistift von Schindler „NB (Sch.) Hier fehlen 8 Takte (auch im Chor). jedoch die eine spätere […]“” (see facsimile). -

-

This entry could be encoded as follows:

-

-

- - <addDesc> - Auf fol. 109v links mit Bleistift von Schindler „NB (Sch.) Hier fehlen 8 Takte (auch im Chor). jedoch die eine spätere […]“ -</addDesc> - -
-

-

A slightly more structured form would be:

-

-

- - <addDesc> - <annot> - <p>Auf fol. 109v links mit Bleistift von Schindler „NB (Sch.) Hier fehlen 8 Takte (auch im Chor). jedoch die eine spätere […]“</p> - </annot> -</addDesc> - -
-

-

These transcriptions – as in the musical text – can also be marked by means of add, del, (see module MEI.edittrans) etc. (see ) and assigned to a specific scribe by hand (see handList):

-

-

- - <addDesc> - <annot> - <p>Auf <locus>fol. 109v</locus> links mit Bleistift von Schindler „<add hand="#Sch">NB (Sch.) Hier fehlen 8 Takte (auch im Chor). jedoch die eine spätere <unclear>[…]</unclear></add>“</p> - </annot> -</addDesc> - -
-

-

For structuring purposes, it may sometimes be useful to separate entries made by a composer in the manuscript from those made by others:

-

-

- - <addDesc> - <annot type="autograph"> - <p>[autograph entries]</p> - </annot> - <annot type="foreign"> - <p>[foreign entries]</p> - </annot> -</addDesc> - -
-

-

Under certain circumstances, stamp elements can also be encoded under addDesc. -

-
-
- Seals and Decorations -

- - - - - - -

-
-
- Describing particular objects within the manuscript -

- - - - - - -

-
-
-
-
- Describing Audio Sources or Other Media -

- - - - - - - - - - -

-
-
- Additional Elements for Historical Account -

- - - - - - - - -

-

- - - - -

-

The acquisition element is a container for recording the process of the acquisition of an item by the holding institution. In comparison, provenance deals with the history of ownership or custodianship of an item. Both elements allow for the choice of either text or more structured information when formulating the specific encoding. It is recommended to make use of p elements when a text-centred encoding is favored and to use the eventList element for a more structured encoding. It is up to the encoder to decide where the information is most appropriate for the particular project or encoding purposes.

-

- - - -

-

The exhibHist element contains descriptions of one or more public exhibitions of a bibliographic item. Often exhibitions include an additional description in the form of a tag for the public that accompanies the item on display. These descriptions may even be printed in a published exhibition catalogue, so the encoding may also include information about why the object was shown or what was significant about the exhibition. When formulating the encoding, it is at the discretion of the encoder whether to opt for text or more structured information. Text-centred encoding is made possible by p elements in exhibHist, among others. For more structured encodings, it is recommended to use the eventList element contained in exhibHist. In FRBR-based cataloging (see ), exhibHist is conceptually bound to the item-level. As an element it is not permitted at the work or expression level and only permitted at the manifestation level if the manifestation is a manifestation singleton.

-

- - - -

-

The physLoc element encodes information related to, or associated with, the physical location of a bibliographic item. This includes, but is not limited to, the name of the holding institution, name or number of the building or room, or any shelfmarks, used for the purpose of retrieval. The level of detail or machine readability of the encoding is generally at the discretion of the encoder and may vary depending on the information available. The physLoc element may contain the following MEI elements:

-

- - - - - - -

-

The repository element contains a description of the institution or individual currently holding the bibliographic item. Its content is either prose or structured markup. The history element, on the other hand, is a container for additional non-bibliographic details regarding the physical location of an item. It may contain the elements acquisition, exhibHist or provenance, among others, to describe any events that coincided with a change of location, such as exhibitions, or change of custody.

-

The following example demonstrates how to structure detailed information about a repository (including the use of identifier):

-

-

- - <physLoc> - <repository auth="ISIL" auth.uri="http://ld.zdb-services.de/resource/organisations/" codedval="DE-1"> - <identifier auth="RISM">D-B</identifier> - <corpName xml:id="SBB-PK" role="holding institution"> - <name type="organization">Staatsbibliothek zu Berlin – Preußischer Kulturbesitz</name> - <name type="organization-site">Haus Unter den Linden</name> - <name type="department">Musikabteilung</name> - </corpName> - <address> - <addrLine>Unter den Linden 8</addrLine> - <addrLine> - <postCode>10117</postCode> - <geogName auth="geonames" auth.uri="http://www.geonames.org/" codedval="2950159">Berlin</geogName> - </addrLine> - </address> - </repository> - <identifier type="shelfmark">Mus.ms. Bach P 175</identifier> - </physLoc> -
-

-

- - - -

-

Conservation activities are often necessary to ensure the long-term preservation and integrity of manuscripts or printed sources. These conservation activities might include interventions such as re-binding, restoration, or modifying paper chemistry. In MEI the treatHist element records any treatment history an item has undergone, and may even specify details of the individual treatment process. The treatHist element allows either text or structured information when formulating the specific encoding. It is recommended to make use of p elements when a text-centred encoding is favored and to use the eventList element for a more structured encoding. Like exhibHist, treatHist is conceptually bound to the item-level in FRBR-based encodings. The element is not permitted at the work or expression level and only permitted at the manifestation level, if the manifestation is a manifestation singleton.

-

- - - -

-

Similar to the MEI treatHist element, the treatSched element is intended to hold records of conservation activities or treatments in regard to a bibliographic item. However, in contrast to treatHist, treatSched allows records of any anticipated activities, rather than simply a historical account of previous treatments. This might include any description indicating the quantity and frequency of the treatments. treatSched furthermore may also be used to indicate that no additions or treatments are to be expected. To that end, treatSched allows the option for either text or more structured information when formulating a specific encoding. It is at the discretion of the encoder to decide which specifics of the encoding are most appropriate.

-
-
-
- Typical Use Cases -

This chapter introduces common use cases for MEI metadata.

-
- Independent Headers -

Many libraries, repositories, research sites and related institutions collect bibliographic and documentary information about machine readable music documents without necessarily collecting the music documents themselves. Such institutions may thus want access to the header of an MEI document without its attached text in order to build catalogs, indexes and databases that can be used to locate relevant texts at remote locations, obtain full documentation about those texts, and learn how to obtain them. This section describes a set of practices by which the metadata headers of MEI documents can be encoded separately from those documents and exchanged as freestanding MEI documents. Headers exchanged independently of the documents they describe are called independent headers.

-
- Independent MEI Headers -

An independent header is an MEI metadata header that can be exchanged as an independent document between libraries, archives, collections, projects, and individuals.

-

The structure of an independent header is exactly the same as that of an header attached to a document. This means that an meiHead can be extracted from an MEI document and sent to a receiving institution with little or no change.

-

When deciding which information to include in the independent header, and the format or structure of that information, the following should be kept in mind:

- - The independent header should provide full bibliographic information about the encoded text, its sources, where the text can be located, and any restrictions governing its use. - The independent header should contain useful information about the encoding of the text itself. In this regard, it is highly recommended that the encoding description be as complete as possible. The Guidelines do not require that the encoding description be included in the header (since some simple transcriptions of small items may not require it), but in practice the use of a header without an encoding description would be severely limited. - The independent header should be amenable to automatic processing, particularly for loading into databases and for the creation of publications, indexes, and finding aids, without undue editorial intervention on the part of the receiving institution. For this reason, two recommendations are made regarding the format or structure of the header: first, where there is a choice between a prose content model and one that contains a formal series of specialized elements, wherever possible and appropriate the specialized elements should be preferred to unstructured prose. Second, with respect to corpora, information about each of the texts within a corpus should be included in the overall corpus-level meiHead. That is, source information, editorial practices, encoding descriptions, and the like should be included in the relevant sections of the corpus meiHead, with pointers to them from the headers of the individual texts included in the corpus. There are three reasons for this recommendation: first, the corpus-level header will contain the full array of bibliographic and documentary information for each of the texts in a corpus, and thus be of great benefit to remote users, who may have access only to the independent header; second, such a layout is easier for the coder to maintain than searching for information throughout a text; and third, generally speaking, this practice results in greater overall consistency, especially with respect to bibliographic citations. - -
-
-
- Including non-MEI Metadata in MEI files -

The following element is provided to accommodate non-MEI metadata:

-

- - - -

-

The extMeta element may be contained by expression, item, manifestation, work and meiHead elements. It may include text and any number of well-formed XML fragments, XML comments, and CDATA sections, except for MEI markup, which is prohibited. The document element of each fragment must explicitly declare its namespace.

-

-

- - <extMeta> - <!-- MARC (Machine-Readable Cataloging) title info --> - <datafield xmlns="http://www.loc.gov/MARC21/slim" ind1="1" ind2="0" tag="245"> - <subfield code="a">Simple dreams :</subfield> - <subfield code="b">a musical memoir /</subfield> - <subfield code="c">Linda Ronstadt.</subfield> - </datafield> -</extMeta> - -
-

-

An MEI processor is not required to validate or otherwise process any markup within the extMeta element. Therefore, the extMeta element itself is the lowest level at which an association can be created between ‘foreign’ metadata and other MEI elements as described in section .

-
-
- Minimal and Recommended Header Information -

The MEI header allows for the provision of a very large amount of information concerning the text itself, its source, its encodings, and revisions of it, as well as a wealth of descriptive information, such as the languages it uses and the situation(s) in which it was produced, together with the setting and identity of participants within it. This diversity and richness reflects the diversity of uses to which it is envisaged that electronic texts conforming to these Guidelines will be put. It is emphatically not intended that all of the elements described above should be present in every MEI Header.

-

The amount of encoding in a header will depend both on the nature and the intended use of the text. At one extreme, an encoder may expect that the header will be needed only to provide a bibliographic identification of the text adequate to local needs. At the other, wishing to ensure that their texts can be used for the widest range of applications, encoders will want to document as explicitly as possible both bibliographic and descriptive information, in such a way that no prior or ancillary knowledge about the text is needed in order to process it. The header in such a case will be very full, approximating the kind of documentation often supplied in the form of a manual. Most texts will lie somewhere between these extremes; textual corpora in particular will tend more to the latter extreme. In the remainder of this section we demonstrate first the minimal, and then a commonly recommended, level of encoding for the bibliographic information held by the MEI header.

-

Supplying only the level of encoding required, the MEI header of a single text will look like the following example:

-

-

- - <meiHead> - <fileDesc> - <titleStmt> - <title>Fughette (in Gottes Namen Fahren wir - Dies sind die heil'gen zehn Gebote) for Brass - Quintett : an electronic transcription - </title> - </titleStmt> - <pubStmt> - <respStmt> - <corpName auth.uri="http://d-nb.info/gnd" auth="GND" codedval="5115204-6">Musikwissenschaftliches Seminar &lt;Detmold&gt;</corpName> - </respStmt> - </pubStmt> - </fileDesc> -</meiHead> - -
-

-

The only mandatory component of the MEI Header is the fileDesc element. Within this element, titleStmt and pubStmt are required constituents. Within the title statement, a title is required. Within the pubStmt, a publisher, distributor, or other agency responsible for the file is required.

-

While not formally required, additional information is recommended for a minimally effective header. For example, it is recommended that the person or corporate entity responsible for the creation of the encoding should be specified using respStmt within the titleStmt element. It is also recommended that information about the source, or sources, of the encoding be included. Each source element should contain at the least a loosely structured bibliographic citation that identifies the source used to construct the MEI file.

-

Furthermore, If the electronic transcription is a member of a series of publications, the series title and publisher should be included using the seriesStmt element. It is also common for cataloging records to include genre and/or form information, here represented by the MEI classification element.

-

We now present the same example header, expanded to include additionally recommended information, adequate for most bibliographic purposes, in particular to allow for the creation of an AACR2-conformant bibliographic record.

-

-

- - <meiHead> - <fileDesc> - <titleStmt> - <title>Fughette (in Gottes Namen Fahren wir - Dies sind die heil'gen zehn Gebote) for Brass - Quintett : an electronic transcription - </title> - <respStmt> - <resp>Encoded by:</resp> - <persName xml:id="header.MH">Maja Hartwig</persName> - <persName xml:id="header.KR">Kristina Richts</persName> - </respStmt> - </titleStmt> - <pubStmt> - <respStmt> - <corpName>Musikwissenschaftliches Seminar &lt;Detmold&gt;</corpName> - </respStmt> - <date>2011</date> - </pubStmt> - <seriesStmt> - <title>MEI Sample Collection</title> - <respStmt> - <corpName role="publisher">MEI Project</corpName> - </respStmt> - </seriesStmt> - <sourceDesc> - <source> - <bibl> - <title>Fughette (in Gottes Namen Fahren wir - Dies sind die heil'gen zehn Gebote) for Brass Quintett</title> - </bibl> - </source> - </sourceDesc> - </fileDesc> - <encodingDesc> - <classDecls> - <taxonomy> - <category auth.uri="http://www.oclc.org/dewey/resources/summaries/default.htm#700" - auth="OCLC" - xml:id="header.OCLC_DDC"/> - </taxonomy> - </classDecls> - </encodingDesc> - <manifestationList> - <manifestation> - <titleStmt> - <title>Fughette (in Gottes Namen Fahren wir - Dies sind die heil'gen zehn Gebote) for Brass - Quintett - </title> - <respStmt> - <persName role="composer">Johann Christoph Bach</persName> - <persName role="arranger">Michel Rondeau</persName> - </respStmt> - </titleStmt> - <pubStmt> - <identifier type="URI">http://icking-music-archive.org/scores/j.chr.bach/JCBIN-xml.zip</identifier> - <date isodate="2011-10-13"/> - <respStmt> - <name>Werner Icking Music Archive</name> - </respStmt> - <availability> - <useRestrict>© 2010 - Gatineau,Qc.Ca.</useRestrict> - </availability> - </pubStmt> - <classification> - <termList> - <term class="#header.OCLC_DDC">785.15</term> - </termList> - </classification> - </manifestation> - </manifestationList> -</meiHead> - -
-

-
-
- Header Elements and their Relationship to Other Bibliographic Standards -

Mapping elements from the MEI metadata header to another descriptive system may help a repository harvest selected data from the MEI file to build a basic catalog record. For this purpose, the following attribute is provided on most elements occurring within meiHead:

-

- - - -

-

The encoding system to which fields are mapped must be specified in analog. When possible, subfields as well as fields should be specified, e.g., subfields within MARC fields.

-
-
- Musical Corpora -

The term corpus may refer to any collection of musical data, although it is often reserved for collections which have been organized or collected with a particular end in view, generally to illustrate a particular characteristic of, or to demonstrate the variety found in, a group of related texts. The principal distinguishing characteristic of a corpus is that its components have been selected or structured according to some conscious set of design criteria.

-

In MEI, a corpus is regarded as a composite text because, although each discrete document in a corpus clearly has a claim to be considered as a text in its own right, it is also regarded as a subdivision of some larger object, if only for convenience of analysis. In corpora, the component samples are clearly distinct texts, but the systematic collection, standardized preparation, and common markup of the corpus often make it useful to treat the entire corpus as a unit, too. Corpora share a number of characteristics with other types of composite texts, including anthologies and collections. Most notably, different components of composite texts may exhibit different structural properties, thus potentially requiring elements from different MEI modules.

-

Aside from these high-level structural differences, and possibly differences of scale, the encoding of language corpora and the encoding of individual texts present identical sets of problems. Therefore, any of the encoding techniques and elements presented in other chapters of these Guidelines may therefore prove relevant to some aspect of corpus encoding and may be used in corpora.

-
- Corpus Module Overview -

The meiCorpus module defines a single element:

-

- - - -

-

The meiCorpus element is intended for the encoding of corpora, though it may also be useful in encoding any collection of disparate materials. The individual samples in the corpus are encoded as separate mei elements, and the entire corpus is enclosed in an meiCorpus element. Each sample has the usual structure for a mei document, comprising an meiHead followed by a music element. The corpus, too, has a corpus-level meiHead element, in which the corpus as a whole, and encoding practices common to multiple samples may be described. The overall structure of an MEI-conformant corpus is thus:

-

-

- - <meiCorpus> - <meiHead type="corpus"> - <!-- metadata for the corpus --> - </meiHead> - <mei> - <meiHead type="text"> - <!-- metadata for sample 1 --> - </meiHead> - <music> - <!-- the encoding of sample 1 --> - </music> - </mei> - <mei> - <meiHead type="text"> - <!-- metadata for sample 2 --> - </meiHead> - <music> - <!-- the encoding of sample 2 --> - </music> - </mei> -</meiCorpus> - -
-

-

This two-level structure allows for metadata to be specified at the corpus level, at the individual text level, or at both. However, metadata which relates to the whole corpus rather than to its individual components should be removed from the individual component metadata and included only in the meiHead element prefixed to the whole.

-

In some cases, the design of a corpus is reflected in its internal structure. For example, a corpus of musical incipits might be arranged to combine all compositions of one type (symphonies, songs, chamber music, etc.) into some higher-level grouping, possibly with sub-groups for date of publication, instrumentation, key, etc. The meiCorpus element provides no support for reflecting such internal structure in the markup: it treats the corpus as an undifferentiated series of components, each tagged with an mei element.

-

If it is essential to reflect the organization of a corpus into sub-components, then the members of the corpus should be encoded as composite texts instead, using the group element described section . The mechanisms for corpus characterization described in this chapter, however, are designed to reduce the need to do this. Useful groupings of components may easily be expressed using the classification and identification elements described in section , and those for associating declarations with corpus components described in section . These mechanisms also allow several different methods of text grouping to co-exist, each to be used as needed at different times. This helps minimize the danger of cross-classification and mis-classification of samples, and helps improve the flexibility with which parts of a corpus may be characterized for different applications.

-

All composite texts share the characteristic that their different component texts may be of structurally similar or dissimilar types. If all component texts may all be encoded using the same module, then no problem arises. If however they require different modules, then the various modules must all be included in the schema.

-
-
- Combining Corpus and Text Headers -

An MEI-conformant document may have more than one header only in the case of a TEI corpus, which must have a header in its own right, as well as the obligatory header for each text. Every element specified in a corpus-header is understood as if it appeared within every text header in the corpus. An element specified in a text header but not in the corpus header supplements the specification for that text alone. If any element is specified in both corpus and text headers, the corpus header element is over-ridden for that text alone.

-

The titleStmt for a corpus text is understood to be prefixed by the titleStmt given in the corpus header. All other optional elements of the fileDesc should be omitted from an individual corpus text header unless they differ from those specified in the corpus header. All other header elements behave identically, in the manner documented in chapter . This makes it possible to state information which is common to the whole of the corpus in the corpus header, while still allowing for individual texts to vary from this common metadata.

-

For example, the following markup shows the structure of a corpus consisting of three texts, the first and last of which share the same encoding description. The second one has its own encoding description.

-

-

- - <meiCorpus> - <meiHead> - <fileDesc> - <!-- corpus file description--> - </fileDesc> - <encodingDesc> - <!-- default encoding description --> - </encodingDesc> - <revisionDesc> - <!-- corpus revision description --> - </revisionDesc> - </meiHead> - <mei> - <meiHead> - <fileDesc> - <!-- file description for this corpus text --> - </fileDesc> - </meiHead> - <music> - <!-- first corpus text --> - </music> - </mei> - <mei> - <meiHead> - <fileDesc> - <!-- file description for this corpus text --> - </fileDesc> - <encodingDesc> - <!-- encoding description for this corpus text, over-riding the default --> - </encodingDesc> - </meiHead> - <music> - <!-- second corpus text --> - </music> - </mei> - <mei> - <meiHead> - <fileDesc> - <!-- file description for third corpus text --> - </fileDesc> - </meiHead> - <music> - <!-- third corpus text --> - </music> - </mei> -</meiCorpus> - -
-

-
-
- Recommendations for the Encoding of Large Corpora -

These Guidelines include proposals for the identification and encoding of a far greater variety of textual features and characteristics than is likely to be either feasible or desirable in any one corpus, however large and ambitious. For most large-scale corpus projects, it will therefore be necessary to determine a subset of recommended elements appropriate to the anticipated needs of the project; these mechanisms include the ability to exclude selected element types, add new element types, and change the names of existing elements.

-

Because of the high cost of identifying and encoding many textual features, and the difficulty in ensuring consistent practice across very large corpora, encoders may find it convenient to divide the set of elements to be encoded into the following four categories:

- - - texts included within the corpus will always encode textual features in this category, should they exist in the text - - textual features in this category will be encoded wherever economically and practically feasible; where present but not encoded, a note in the header should be made. - - textual features in this category may or may not be encoded; no conclusion about the absence of such features can be inferred from the absence of the corresponding element in a given text. - - textual features in this category are deliberately not encoded; they may be transcribed as unmarked up text, or represented as gap elements, or silently omitted, as appropriate. - -
-
-
-
-
- Repertoire: Common Music Notation -

The module described in this chapter offers the means to describe music in so-called ‘Common Music Notation’ (CMN, sometimes referred to as ‘Common Western Music Notation’). For this purpose, it provides a number of special elements and adds several attribute classes to elements from the module.

-
- Introduction -

This chapter is supposed to frame the repertoire target by the module, i.e., what is Common Music Notation?

-
-
- Basic Elements of CMN -

This section describes the use of basic features of MEI important for encoding CMN material. Most of the elements discussed here are defined in chapter of these Guidelines, but are used in music from the CMN repertoire in specialized ways.

-
- The Role of the Measure Element -

Arguably, the most important element of the CMN module is the measure element. It is used as a structural unit inside section elements and acts as a container for ‘events’ from the model.eventLike class, such as notes, chords and rests as well as ‘control events’ from the model.controlEventLike class, such as slurs and indications of dynamics.

-

The following example demonstrates the use of the measure element:

-

-

- - <section> - <measure n="1"> - <staff n="1"> - <layer> - <chord dur="1"> - <note oct="5" pname="c"/> - <note oct="4" pname="g"/> - <note oct="4" pname="e"/> - </chord> - </layer> - </staff> - <staff n="2"> - <layer> - <note dur="1" oct="3" pname="c"/> - </layer> - </staff> - </measure> -</section> - -
-

-

A measure slices the flow of a score or part into chunks that normally comply with a duration determined by the meter defined within a preceding scoreDef or staffDef element. Each staff in the source material is represented by a staff element. As the order of the staff elements in the file does not have to reflect their order in the original document, to eliminate confusion they should always refer to a staffDef element, using either an n or def attribute. Whereas the def attribute uses the xs:anyURI datatype, the n value refers to the closest preceding staffDef or layerDef with the same value in its n attribute.

-

-

- - <staffDef n="3" xml:id="cmn_staffDef1" /> -<!-- later in the file: --> -<staff def="#cmn_staffDef1"> -<!-- @def refers to staffDef with this identifier --> -<!-- staff content --> -</staff> -<!-- or: --> -<staff n="3"> -<!-- @n refers to staffDef with this numeric label --> -<!-- staff content --> -</staff> - -
-

-

Each staff may hold a number of layer elements to reflect multiple ‘voices’. Just as with staff, the order of the layer elements in the file does not have to reflect their original order in the document, so they also possess n and def attributes for association with the appropriate layer definition.

-

-

- - <staffDef> - <layerDef n="1" xml:id="cmn_layerDef1"/> -</staffDef> - -
-

-

Later in the file:

-

-

- - <section xml:id="cmn_staffDef1"> - <staff def="#cmn_staffDef1"> - <layer def="#cmn_layerDef1"> - <!-- layer content --> - </layer> - </staff> - <!-- OR: --> - <staff n="3"> - <layer n="1"> - <!-- layer content --> - </layer> - </staff> -</section> - -
-

-
-
- Defining Score Parameters for CMN -

When encoding a score in CMN, MEI relies on the following elements from the module:

-

- - - - - - -

-

A scoreDef element is used to specify the common parameters of a score, e.g., key and meter. The most important attributes for this purpose are:

-

- - - - - -

-

The following example describes a score in common time with 3 flats:

-

-

- - <scoreDef keysig="3f" meter.count="4" meter.sym="common" meter.unit="4"/> - -
-

-

For encoding more complex time signatures, simple mathematical symbols such as asterisks and plus signs are allowed in meter.count.

-

Non-standard key signatures have to be encoded with a keySig element.

-

Other attributes allow the description of default page and system margins and fonts for text and music:

-

- - - - - - - -

-

There are other attributes that allow the specification of many further details of a score. These are available from the element definitions accessible at scoreDef, staffDef, staffGrp and layerDef.

-

When content is provided for scoreDef, it must contain a staffGrp element. This element is used to gather individual staves and other staff groups. This is useful for collecting instrumental or vocal groups in a large score, such as woodwinds, brasses, etc., and for assigning a shared label to the group, using the label and labelAbbr subelements. The staffGrp element is also used for the two staves of a grand staff. The bar.thru attribute on staffGrp allows one to specify whether bar lines are drawn across the space between staves of that group or only on the staves themselves.

-

A staffDef element is used to describe an individual staff of a score or performer part. It bears most of the attributes described above. The label and labelAbbr subelements may be used for providing staff labels for the first and subsequent systems.

-

Every staffDef must have an n attribute with an integer as its value. The first occurrence of a staffDef with a given number must also indicate the number of staff lines via the lines attribute.

-

The order of staffDef elements within scoreDef follows the order of staves in the source document or planned rendering. The individual staff elements within a measure refer to these staffDef declarations using their own n attribute values. Therefore, the encoding order of staves within a measure does not have to mimic the order of the staffDef elements with scoreDef.

-

In addition to the parameters inherited from scoreDef, the following attributes are important for staffDef elements:

-

- - - -

-

A staff with a tenor clef is encoded as in the following example:

-

-

- - <staffDef clef.dis="8" - clef.dis.place="below" - clef.line="2" - clef.shape="G"/> - -
-

-

In the case of transposing instruments, the key-related attributes described above may be used to override the written key expressed in the scoreDef element. As a basic principle, MEI always captures written pitches, so the trans.diat and trans.semi attributes may be used to indicate the number of diatonic steps and semitones to calculate sounded pitch from written pitch. The piccolo and E♭ clarinet staves in the example below utilize these attributes:

-

-

- - <scoreDef meter.count="6" meter.unit="8"> - <staffGrp> - <!-- Piccolo sounds 12 semitones higher than written (and encoded in MEI). --> - <staffDef clef.line="2" - clef.shape="G" - key.mode="major" - keysig="4f" - label="Piccolo" - label.abbr="Picc." - lines="5" - n="1" - trans.diat="0" - trans.semi="12" - xml:id="cmn.P1"/> - <staffDef clef.line="2" - clef.shape="G" - key.mode="major" - keysig="4f" - label="Flute" - label.abbr="Fl." - lines="5" - n="2" - xml:id="cmn.P2"/> - <staffDef clef.line="2" - clef.shape="G" - key.mode="major" - keysig="4f" - label="Oboe" - label.abbr="Ob." - lines="5" - n="3" - xml:id="cmn.P3"/> - <staffDef clef.line="4" - clef.shape="F" - key.mode="major" - keysig="4f" - label="Bassoon" - label.abbr="Bsn." - lines="5" - n="4" - xml:id="cmn.P4"/> - <!-- Clarinet sounds a minor third (two diatonic steps or three semitones) higher than written. --> - <staffDef clef.line="2" - clef.shape="G" - key.mode="major" - keysig="1f" - label="Clarinet in E♭" - label.abbr="E♭ Cl." - lines="5" - n="5" - trans.diat="2" - trans.semi="3" - xml:id="cmn.P5"/> - </staffGrp> -</scoreDef> - -
-

-

There are a number of additional elements that can be used as children of staffDef in order to describe additional features of the staff, such as the color of a clef or a key signature added in a different hand. These elements include:

-

- - - - - - - - - -

-

With the exception of label, these elements may also occur within the flow of musical events captured in a layer, since they are members of model.eventLike. In the layer context they function as milestones and affect all following content assigned to the layer (even in subsequent measures) until their information is again overridden either by the same element bearing different information or a staffDef or scoreDef. In this context, it is also possible to combine them with the elements described in chapters and of these Guidelines.

-

Such flexibility as this may require close inspection of an encoding to retrieve the correct definitions for a given staff. As a general rule, the closest preceding and most specific element provides this information: For example, a keySig in the preceding measure is more relevant than a staffDef at the beginning of the section, which is more relevant than a scoreDef at the beginning of the score. However, a section-specific scoreDef that provides only information about the meter does not override the more specific information about key signature gathered from a staffDef for a transposing instrument.

-

Every staffDef may contain a number of layerDef elements, which may be used to establish default values for the distinct layers sharing one staff. MEI does not use the term ‘voice’ to describe these ‘musical threads’ because that term implies continuity across measure boundaries. Given the sometimes arbitrary relationships between these threads from measure to measure as well as across staves, MEI uses the more neutral term ‘layer’.

-
-
- Special cases in staff definitions -

Usually clef, key, and meterSig apply to a whole staff.

-

In some rare cases one can find different meters in different layers, as seen in Maurice Ravel’s Oiseaux tristes.

-

-

- Different meters in different layers on the upper staff - -
-

-

In these cases it is necessary to encode each meterSig for the staff as child of the corresponding layerDef:

-

-

- - <staffGrp bar.thru="true"> - <staffDef n="1"> - <layerDef n="1"> - <meterSig count="4" unit="4" sym="common" /> - </layerDef> - <layerDef n="2"> - <meterSig count="12" unit="8" /> - </layerDef> - </staffDef> - <staffDef n="2" lines="5"> - <layerDef n="1"> - <meterSig count="4" unit="4" sym="common" /> - </layerDef> - </staffDef> -</staffGrp> -
-

-
-
- Re-definition of Score Parameters -

Sometimes it is necessary to re-define the parameters of a score or a staff. For example, a score may change keys, the number of staves, or use different layout settings. Likewise, a staff may change its clef, change the number of layers, or become invisible. To accommodate these changes, staffDef is allowed to occur in the following locations:

- - within the description of staff groups; that is, in staffGrp, - within the content of a measure, - between measures; that is, directly within section and ending elements, and - between sections and endings; that is, directly within a score or part element. - -

In addition, scoreDef is allowed to occur:

- - within sections and endings; that is, inside section and ending elements; and - between sections and endings; that is, directly within a score or part. - -

It is also possible to include scoreDef and staffDef in staves and layers when the MEI All schema is in use; however, this practice is not recommended for the CMN repertoire.

-

The following example shows how to change the key and meter signatures within a score. The keysig.cancelaccid attribute may be used to control the position of the cancellation accidentals of the key signature change, while the keysig.visible can be used to hide the key signature entirely.

-

-

- - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Key changes example</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>Example taken from the Verovio Test Suite</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <?edit-start?> - <scoreDef keysig="4f" meter.sym="common"> - <staffGrp> - <staffDef n="1" lines="5" clef.shape="G" clef.line="2" /> - </staffGrp> - </scoreDef> - <section> - <measure right="dbl" n="1"> - <staff n="1"> - <layer n="1"> - <chord dur="1"> - <note oct="4" pname="a" accid.ges="f" /> - <note oct="5" pname="c" accid.ges="f" /> - <note oct="5" pname="e" accid.ges="f" /> - </chord> - </layer> - </staff> - </measure> - <scoreDef keysig="0" keysig.cancelaccid="none" /> - <measure right="dbl" n="4"> - <staff n="1"> - <layer n="1"> - <chord dur="1"> - <note oct="4" pname="a" /> - <note oct="5" pname="c" /> - <note oct="5" pname="e" /> - </chord> - </layer> - </staff> - </measure> - <scoreDef keysig="2s" keysig.cancelaccid="before" meter.sym="cut" /> - <measure n="2"> - <staff n="1"> - <layer n="1"> - <chord dur="1"> - <note oct="4" pname="b" /> - <note oct="5" pname="d" /> - <note oct="5" pname="f" accid.ges="s" /> - </chord> - </layer> - </staff> - </measure> - <measure right="dbl" n="3"> - <staff n="1"> - <layer n="1"> - <multiRest num="3" /> - </layer> - </staff> - </measure> - <scoreDef keysig.visible="false" keysig="5f" meter.count="4" meter.unit="4" /> - <measure right="dbl" n="5"> - <staff n="1"> - <layer n="1"> - <chord dur="1"> - <note oct="4" pname="g" /> - <note oct="4" pname="b" accid.ges="f" /> - <note oct="5" pname="d" /> - </chord> - </layer> - </staff> - </measure> - <scoreDef keysig="2s" keysig.cancelaccid="before-bar" /> - <measure right="end" n="2"> - <staff n="1"> - <layer n="1"> - <chord dur="1"> - <note oct="4" pname="b" /> - <note oct="5" pname="d" /> - <note oct="5" pname="f" accid.ges="s" /> - </chord> - </layer> - </staff> - </measure> - </section> - <?edit-end?> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-
-
- Notes, Chords and Rests in CMN -
- Notes -

Undoubtedly, the most important element for any music notation representation is the note element, which is defined in section . This section describes the usage of note in the CMN repertoire as well as CMN-specific additions to the basic definition in the shared module.

-
- Basic Usage of Notes in CMN -

In CMN, notes are determined by three basic parameters:

- - pitch name (using pname) - octave (using oct) - duration (using dur) - -

A single note, in this case a quarter note C4, is therefore encoded as:

- - <note dur="4" oct="4" pname="c"/> - -
-

-

The default values for pname and oct conform to the Scientific Pitch Notation (SPN) (also known as American Standard Pitch Notation); that is, the letters A–G indicate the musical note name of a pitch, and the numbers 0–9 indicate the octave range to which a note belongs. pname values differ from this convention only by using lower case values for pitches (a–g instead of A-G). The value for oct changes between B and C, that is, octave ranges go from C, D, …, G, A, to B. For example, middle C or c' (the C in the middle, i.e., fourth C key from left, on a standard 88-key piano keyboard) is represented on the first ledger line in G clef notation and labelled as C4, in the naming convention of SPN. The note one semitone below would be labelled B3, and A4 would refer to the first A above C4.

-

The usual CMN-specific values for dur are:

- - - whole note - - half note - - quarter note - - eighth note - - sixteenth note - - - - 2048th note - -

Additionally, the following two values borrowed from mensural notation are allowed, as they sometimes also appear in CMN:

- - - double whole - - quadruple whole - -

Please note that their mensural counterparts bear different names in order to clearly distinguish between repertoires.

-

Dotted durational values are accommodated by the dots attribute, which records the number of written augmentation dots. Thus, a dotted quarter note is represented as in the following example:

-

-

- - <note dots="1" dur="4" oct="4" pname="c"/> - -
-

-
-
- Grace Notes -

The CMN module adds two optional attributes, grace and grace.time, to note and chord. The presence of the grace attribute indicates a grace note or chord.

-

-

- Grace notes - -
-

-

The encoding of the left-most example would look like this:

-

-

- - <beam> - <note dur="8" oct="5" pname="d" stem.dir="down"/> - <note dur="8" - oct="5" - pname="e" - stem.dir="up" - grace="unacc" - stem.mod="1slash"/> - <note dur="8" oct="5" pname="d" stem.dir="down"/> - <note accid="s" - dur="8" - oct="5" - pname="c" - stem.dir="up" - grace="unacc" - stem.mod="1slash"/> - <note dur="8" oct="5" pname="d" stem.dir="down"/> - <note dur="8" oct="4" pname="b" stem.dir="down"/> -</beam> - -
-

-

Grace notes are not counted when determining the measure’s conformance to the current time signature. Therefore, the dur attribute records only the written rhythmic value of the grace note. The time necessary for the performance of grace notes can be unspecified, calculated based on taking time from other non-grace notes, or specified precisely using the dur.ges attribute.

-

The values of grace indicate from which note time is ‘borrowed’ to perform the grace note: The preceding note, in which case the value unacc (unaccented) is used, or the following note, when the value acc (accented) is appropriate. Technically, this value determines if the note following the grace will keep its original onset time or will be slightly delayed to allow the grace note itself to be accented. Sometimes it is not clear how to perform a grace; in these situations the value unknown allows one to indicate a grace note while unambiguously stating that its performed duration remains unknown.

-

The grace.time attribute is only to be used in combination with the grace attribute. It records the amount of time (as a percentage of the written duration) that the grace note should ‘steal’ from the preceding note (when grace="unacc") or the following note (when grace="acc").

-

Grace notes can be placed within a graceGrp element, which itself allows all values for grace as explained above. The optional attach attribute is used to record whether the grace note group is attached to the following event or to the preceding one. The graceGrp element can be used with single or multiple grace notes.

-

More information about grace notes in the context of other CMN ornaments is available in chapter .

-
-
-
- Chords -

Often we find multiple notes that are not sounding in succession but sounding simultaneously. These chords in MEI are basically defined as a container of notes that are stemmed together.

-
- Chords in CMN -

A chord is any set of pitches consisting of multiple notes that are to be played simultaneously and are usually grouped together visually with a single stem. In MEI the chord element functions as a container for all participating notes. Also it features many attributes that are allowed for notes, e.g., usually all notes in a chord have a common duration, so it can be applied to the whole chord within it’s dur attribute.

-

Some notational features like articulations or lyrics are connected to a whole chord instead of a single note. Therefore elements like artic or verse are also allowed as children of chord elements. In the following example from Sergei Rachmaninoff’s Prelude in C-sharp minor, Op. 3, No. 2 all chords carry an accent.

-

-

- Chords in Rachmaninoff’s Prelude in C-sharp minor, Op. 3, No. 2 - -
-
- - <layer> - <chord xml:id="ex-1877520550" dur="2" stem.dir="up"> - <artic artic="acc" place="above"/> - <note oct="3" pname="c" accid.ges="s"/> - <note oct="3" pname="e"/> - <note oct="3" pname="g" accid.ges="s"/> - <note oct="4" pname="c" accid.ges="s"/> - </chord> - <chord xml:id="ex-1072408883" dur="4" stem.dir="up"> - <artic artic="acc" place="above"/> - <note oct="3" pname="a"> - <accid accid="n"/> - </note> - <note oct="4" pname="a"> - <accid accid="n"/> - </note> - </chord> - <chord xml:id="ex-0929208104" dur="4" stem.dir="up"> - <artic artic="acc" place="above"/> - <note oct="3" pname="g" accid.ges="s"/> - <note oct="4" pname="g" accid.ges="s"/> - </chord> -</layer> - -
-

-
-
- Stem Modifications -

The stem.mod attribute accommodates various stem modifiers found in the CMN repertoire. These symbols are placed on a note or chord’s stem and generally indicate different types of tremolo and Sprechstimme. The following values are allowed:

- - - 1 slash through stem - - 2 slashes through stem - - 3 slashes through stem - - 4 slashes through stem - - 5 slashes through stem - - 6 slashes through stem - - X placed on stem - - Z placed on stem - -

The stem.mod attibute is normally used in accordance with practices described in section .

-

The CMN module makes the att.stems.cmn attribute class available, which adds the optional stem.with attribute to note and chord. The attribute stem.with allows for the indication of a stem that joins notes on adjacent staves.

-

-

- Cross-staff chord - -
-

-

The following code demonstrates one method of encoding the first chord in the last measure in the image above. The stem.with attribute must occur on all the notes or chords attached to the cross-staff stem.

-

-

- - <measure> - <staff n="1"> - <layer n="1"> - <note dur="2" oct="4" pname="d" stem.with="below"/> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <chord dur="2" stem.with="above"> - <note accid="n" oct="3" pname="b"/> - <note oct="3" pname="f"/> - </chord> - </layer> - </staff> -</measure> - -
-

-

Alternatively, the encoder may choose to treat the notes in the lower staff as logically belonging to the top staff and to ‘displace’ them using the staff attribute on note. Some use cases, however, may require filling the time that those notes would normally occupy using the space element described in section . Using this mechanism, the example above could also be encoded like so:

-

-

- - <measure> - <staff n="1"> - <layer n="1"> - <chord dur="2"> - <note oct="4" pname="d"/> - <note accid="n" oct="3" pname="b" staff="2"/> - <note oct="3" pname="f" staff="2"/> - </chord> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <!-- the time used by the notes on staff 2 filled with non-sounding "space" --> - <space dur="2"/> - </layer> - </staff> -</measure> - -
-

-

The choice between these two methods of representing material that crosses staves is often software-dependent.

-

Whereas stem.with can be used to define stems that connect notes across different staves (cross-staff chords) stem.sameas is meant for describing a stem that connects two notes pertaining to different layers within the same staff.

-

The typical scenario for stem.sameas is orchestral scores where two wind instruments are notated on one single staff. Normally, the notes have individual stems pointing in opposite directions. However, it is common engraving practice that notes of the same duration are often stemmed together between the parts encoded in separate layers. The following example demonstrates this practice in the wind instruments (bassoons and trumpets in meas. 1 - 3, horns in meas. 3)

-

-

- Shared stems - -
-

-

The following code represents an encoding of shared stems in the bassoon and trumpet staff using stem.sameas.

-

-

- - <score> - <measure n="1"> - <!-- ... --> - <staff label="Fagotti" n="3"> - <layer n="1" xml:id="L08"> - <note accid.ges="f" - dur="2" - oct="4" - pname="e" - tstamp="1" - xml:id="note_2754"/> - <note accid.ges="f" - dots="2" - dur="4" - oct="4" - pname="e" - tstamp="2" - xml:id="note_2757"/> - <note accid.ges="f" - dur="16" - oct="4" - pname="e" - tstamp="2.875" - xml:id="note_2760"/> - </layer> - <layer n="2" xml:id="L10"> - <note accid.ges="f" - dur="2" - oct="3" - pname="e" - stem.sameas="#note_2754" - tstamp="1" - xml:id="note_2766"/> - <note accid.ges="f" - dots="2" - dur="4" - oct="3" - pname="e" - stem.sameas="#note_2757" - tstamp="2" - xml:id="note_2769"/> - <note accid.ges="f" - dur="16" - oct="3" - pname="e" - stem.sameas="#note_2760" - tstamp="2.875" - xml:id="note_2772"/> - </layer> - </staff> - <!-- ... --> - <staff label="Clarini" n="5"> - <layer n="1" xml:id="L15"> - <note dur="2" oct="5" pname="c" tstamp="1" xml:id="note_2808"/> - <note dots="2" - dur="4" - oct="5" - pname="c" - tstamp="2" - xml:id="note_2811"/> - <note dur="16" - oct="5" - pname="c" - tstamp="2.875" - xml:id="note_2814"/> - </layer> - <layer n="2" xml:id="L17"> - <note dur="2" - oct="4" - pname="c" - stem.sameas="#note_2808" - tstamp="1" - xml:id="note_2820"/> - <note dots="2" - dur="4" - oct="4" - pname="c" - stem.sameas="#note_2811" - tstamp="2" - xml:id="note_2823"/> - <note dur="16" - oct="4" - pname="c" - stem.sameas="#note_2814" - tstamp="2.875" - xml:id="note_2826"/> - </layer> - </staff> - <!-- ... --> - </measure> -</score> - -
-

-
-
-
- Rests -

The dur attribute on rest captures the written duration of the rest and allows the same values as on note and chord. The CMN module also makes three more elements available for special forms of rest:

-

- - - - - -

-
- Measure Rests -

The mRest (measure rest) element is used to indicate a complete measure rest, independent from the meter of the current

-

- measure.

-

The cutout attribute provides for the description of the rendition of the mRest. If cutout is set to ‘cutout’ (the only value allowed), then the complete staff including the staff lines will not be rendered for this measure.

-

-

- - <staff> - <layer> - <mRest cutout="cutout"/> - </layer> -</staff> - -
-

-

It is a semantic error to mix an mRest with other events in the same layer. However, other ‘control events’, such as fermata, may be used at the same time as mRest.

-
-
- Multiple-Measure Rests -

The multiRest (multiple measure rest) element is used to encode multiple measures of rest. It is commonly used in performer parts, but due to the problem of synchronicity with other staves, it is never found in scores. A numeric value, stored in the num attribute, indicates the number of resting measures. The older visual forms displayed below (often called Kirchenpausen) are not captured by multiRest, but may be created by rendering software. You may force modern block rests by using the block attribute.

-

-

- Forms of multiple measure rests - -
-
- - <staff> - <layer> - <multiRest num="9"/> - </layer> -</staff> - -
-

-
-
- Empty Measures -

The mSpace (measure space) element is closely related to the space and mRest elements. It is used to explicitly indicate that a layer has no content but that no information is missing from the encoding.

-

-

- Empty measure - -
-
- - <measure n="2"> - <staff> - <layer> - <mSpace/> - </layer> - </staff> -</measure> - -
-

-
-
-
-
- Timestamps and Durations -

MEI offers multiple ways of defining onsets and offsets of timed musical events such as notes and slurs. The most common and most musician-friendly approach to this is through the use of a combination of the attributes tstamp and dur, which are made available by the attribute classes att.timestamp.log (inherited by att.controlEvent) and att.timestamp2.log, both from the shared module.

-

The timestamp (tstamp) of a musical event is calculated in relation to the meter of the current measure and resembles the so-called ‘beat’ position. In a common time measure with four quarter notes, the timestamp of each quarter equals its beat position in the measure: The first quarter has a timestamp of 1, the second has a timestamp of 2, and so on. MEI defines the value of tstamp as a real number; the second eighth note position in a measure would thus be represented by the value of "1.5". The range of possible values is defined as starting with zero and ending with the number of metrical units in a measure (the ‘numerator’ in a time signature) + 1. This allows the capture of all graphical positions starting from the left bar line ('0') and ending with the right bar line of the measure ('5', in the case of 4/4 time).

-

For expressing durations, MEI offers the dur attribute. This attribute is described in section .

-

For ‘spanning’ elements like slurs, which are members of the model.controlEventLike class, it is often more intuitive to record two timestamps – one for the onset of the event and one for its termination. Because the termination of the event may be in a succeeding measure, the second timestamp (tstamp2) has a slightly different datatype than the one marking the initiation of the event. Its datatype is constrained to values following the formula "xm + y", where x is the number of full measures that this particular feature lasts (or the number of bar lines crossed) and y is the timestamp in the target measure where the feature ends. The timestamp is expressed using the same logic as described above. For example, a value of "0m+3" in 4/4 time indicates that the element bearing this attribute, a slur for example, ends on beat 3 of the same measure where it started. A value of "1m+1.5" would indicate an end on the second eighth note of the following measure. In 6/8 time, the value "2m+3" means that the feature ends two measures later on the third eighth note.

-
-
-
- Advanced CMN Features -

Over time, in addition to the basic features of note, chord, and rest, many other symbols have been added to CMN. The following section describes some of these symbols and introduces their handling in MEI.

-
- Beams -

A very common feature of music from the CMN repertoire is the beaming of eighth or shorter notes. MEI provides two elements for the explicit encoding of features joined by beams.

-

- - - - -

-

Use of the beam element is straightforward. The beamed notes, rests, or chords are simply enclosed by the beam element:

-

-

- - <layer> - <beam> - <note dur="8"/> - <note dur="8"/> - </beam> -</layer> - -
-

-

Whereas in music notation every note value shorter than an eighth adds another beam (sometimes referred to as ‘secondary beams’), in MEI only one beam element is used, no matter the durations of the contained notes. The visual rendition of a set of beamed notes is presumed to be handled by rendering processes.

-

-

- - <layer> - <!-- … --> - <beam> - <note dur="16"/> - <note dur="32"/> - <note dur="32"/> - <note dots="1" dur="16"/> - <note dur="32"/> - </beam> - <!-- … --> -</layer> - -
-

-

From the 19th century onwards, it became quite common to break secondary beams to increase readability of longer beamed passages. The optional breaksec attribute on notes and chords under the beam may be used to encode the breaking of secondary beams after the note or chord bearing the attribute. The value of breaksec indicates the number of continuous beams. For example:

-

-

- Primary and secondary beams - -
-
- - <layer> - <beam> - <note dots="1" dur="8"/> - <note dur="16"/> - </beam> - <beam> - <note dur="32"/> - <note dur="32"/> - <note breaksec="1" dur="16"/> - <note dur="32"/> - <note dur="32"/> - <note dur="32"/> - <note dur="32"/> - </beam> -</layer> - -
-

-

In the music of the second half of the 20th century, it is quite common to indicate acceleration or deceleration using converging (feathered) beams as in the image below:

-

The encoding of such a beam is accomplished using the form attribute of the beam, which allows the following values:

- - - Beams gradually diverge. - - Beams gradually converge (into one). - - Beams diverge and converge arbitrarily. - - The beam is rendered as usual (default). - -

-

- - <layer> - <!-- … --> - <beam form="acc"> - <note dur="8"/> - <note/> - <note/> - <note/> - <note/> - <note dur="32"/> - </beam> - <!-- … --> -</layer> - -
-

-

The duration of notes, rests, or chords under a beam which carries the form attribute with a value of ‘acc’, ‘rit’, or ‘mixed’ must be treated specially. The first and last contained elements must specify a duration which matches the number of beams displayed at the point of these events. In the case of a ‘mixed’ beam, each event at the point of change in the number of secondary beams must carry a dur attribute. Beams like this may be encoded thusly:

-

-

- Feathered beaming - -
-
- - <layer> - <!-- … --> - <beam form="mixed"> - <note dur="8"/> - <note dur="8"/> - <note/> - <note/> - <note/> - <note dur="32"/> - </beam> - <beam form="mixed"> - <note dur="32"/> - <note/> - <note/> - <note/> - <note/> - <note dur="8"/> - <note dur="8"/> - </beam> - <!-- … --> -</layer> - -
-

-

-

- Two measures from No. 4 of Moszkowski’s 12 Pianoforte Studies for the left hand - -
-

-

Beams that connect events on different staves may be encoded in two different ways. First, a single-layer approach may be taken that treats the events lying under the beam as logically belonging to the same layer as the initial event but visually ‘displaced’ to an adjacent staff. In the example above from Moritz Moszkowski’s - 12 Pianoforte Studies for the left hand, Op. 92, MoszWV 117 this method makes even from a semantic perspective perfect sense. It can be achieved with an additional staff attribute value that contradicts the ‘normal’ staff placement indicated by the n attribute of their ancestor staff.

-

-

- - <staff n="2"> - <layer> - <!-- … --> - <beam place="mixed"> - <note dur="16" oct="3" pname="f" accid.ges="s"/> - <note dur="16" oct="3" pname="b"/> - <note dur="16" oct="4" pname="d" accid="s" staff="1"/> - <note dur="16" oct="4" pname="f" accid.ges="s" staff="1"/> - </beam> - <!-- … --> - </layer> -</staff> - -
-

-

In other contexts however, a staff-by-staff methodology may be employed in which the notes are encoded according to the staff on which they appear. This encoding style requires that each beam element account for the total time encompassed by the beam; that is, each beam must use one or more space elements to account for the time occupied by notes on the opposing staff. For example, the time used by the first two notes of the beam must be represented on staff number 1 and the time taken by the last two notes of the beam must be filled on staff number 2.

-

-

- - <measure> - <staff n="1"> - <layer> - <beam beam.with="below"> - <space dur="8"/> - <note oct="4" pname="d"/> - <note pname="f"/> - </beam> - </layer> - </staff> - <staff n="2"> - <layer> - <beam beam.with="above"> - <note dur="16" oct="3" pname="g"/> - <note pname="b"/> - <space dur="8"/> - </beam> - </layer> - </staff> -</measure> - -
-

-

Downstream processing needs are the determining factor in the choice between the two alternative encoding methods.

-

Due to the potential problem of overlapping hierarchies, the beam element only allows the encoding of beams that do not cross bar lines. When beams cross bar lines, the use of the beamSpan element is required. Unlike beam, the beamSpan element does not contain the beamed notes as its children. Instead, it references the xml:id values of all affected notes in its plist attribute and denotes the initial and terminal notes of the beam using startid and endid attributes. This configuration allows beams to cross measure boundaries. The following example from Erwin Schulhoff’s - Violin Sonata demonstrates a typical example of such hierarchy-crossing beams:

-

-

- Cross-measure beam in the third movement of Schulhoff’s Sonata - -
-
- - <beamSpan startid="#note1" endid="#note4" plist="#note1 #note2 #note3 #note4"/> - -
-

-

In addition to the explicit encoding of beams accommodated by the beam and beamSpan elements and the beam attribute, MEI allows for specification of default beaming behavior using the following attributes on scoreDef, staffDef, and layerDef:

- - - Provides an example of how automated beaming (including secondary beams) is to be performed. - - Indicates whether automatically-drawn beams should include rests shorter than a quarter note duration. - -

The beam.group attribute can be used to set a default beaming pattern to be used when no beaming is indicated at the layer level. It must contain a comma-separated list of time values that add up to a measure in the current meter, e.g., 4,4,4,4 in 4/4 time indicates that each quarter note worth of shorter notes should be beamed together. Parentheses can be used to indicate sub-groupings of secondary beams. For example, (4.,4.,4.) in 9/8 meter indicates one primary beam per measure with secondary beams broken at each dotted quarter duration, while (4,4),(4,4) in 4/4 will result in a measure of 16th notes being rendered with a primary beam covering all the notes and secondary beams for each group of four 16th notes.

-

The beam.group attribute is available on scoreDef, staffDef, and layerDef elements, making it possible to set different beaming patterns for each of these. Also, the beaming pattern can be changed anywhere score parameters may be changed, for example, at the start of sections. This beaming "directive" can be overridden by using beam, beamSpan, or beam attributes as described above. If none of these beaming specifications is used, then no beaming is implied. Default beaming can be explicitly ‘turned off’ by setting beam.group to an empty string.

-
-
- Ties, Slurs and Phrase Marks -

One of the most specific features of CMN is the use of ‘curved lines’ which connect notes. These lines are used to indicate various musical features, depending on their context.

-

A tie is a curved line connecting two notes of the same pitch. The purpose of a tie is to join the durations of both notes, so that the first note sounds for the combined duration. In other words, there is only one onset for both notes.

-

In MEI, ties can be encoded in different ways, depending on the level of detail that the encoder wants to preserve. The simplest solution is to use the tie attribute found on note and chord.

- - <layer> - <note dur="2" oct="4" pname="f" tie="i"/> - <note dots="1" dur="4" oct="4" pname="f" tie="t"/> -</layer> - -
-

-

This attribute allows three values:

- - - Marks the start of a tie - - Marks a participant in a tie other than the first or last - - Marks the end of a tie - -

The scope of the tie attribute is the musical layer; that is, a tie started in one layer may only be ended by a subsequent musical event with a tie attribute with an m or t value in the same layer. The tie-terminating event may lie in the following measure.

-

-

- Ties across bar lines - -
-
- - <measure n="1"> -<!-- staff 1 omitted --> - <staff n="2"> - <layer n="1"> - <chord dur="16"> - <note oct="2" pname="f" /> - <note oct="1" pname="f" /> - </chord> - <beam> - <note oct="2" pname="f" tie="i" /> - <note oct="2" pname="a" tie="i" /> - <note oct="3" pname="c" tie="i" /> - </beam> - <chord dur="4"> - <note oct="3" pname="f" tie="i" /> - <note oct="3" pname="c" tie="m" /> - <note oct="2" pname="a" tie="m" /> - <note oct="2" pname="f" tie="m" /> - </chord> - </layer> - </staff> -</measure> -<measure n="2"> -<!-- staff 1 omitted --> - <staff n="2"> - <layer n="1"> - <chord dur="16"> - <note oct="3" pname="f" tie="t" /> - <note oct="3" pname="c" tie="t" /> - <note oct="2" pname="a" tie="t" /> - <note oct="2" pname="f" tie="t" /> - </chord> - <!-- … --> - </layer> - </staff> -</measure> -<!-- measures 3 and 4 omitted --> - -
-

-

When tie is used on chords, it functions as a shorthand indication for multiple tie markings; that is, a separate tie is drawn for every pitch in the chord that remains unchanged in the succeeding chord.

-

-

- - <staff> - <layer> - <chord dur="4" tie="i"> - <note pname="f"/> - <note pname="c"/> - <note pname="a"/> - </chord> - <chord dur="4" tie="t"> - <note pname="f"/> - <note pname="c"/> - <note pname="a"/> - </chord> - </layer> -</staff> - -
-

-

This is equivalent to the following, more verbose version:

-

-

- - <staff> - <layer> - <chord dur="4"> - <note pname="f" tie="i"/> - <note pname="c" tie="i"/> - <note pname="a" tie="i"/> - </chord> - <chord dur="4"> - <note pname="f" tie="t"/> - <note pname="c" tie="t"/> - <note pname="a" tie="t"/> - </chord> - </layer> -</staff> - -
-

-

A slur is a curved line that connects a group of notes of different pitch. It normally indicates that an instrument-specific performance technique should be applied to the affected notes. For example, in notation for winds, the notes should be played in one breath, while a single bow is indicated for string instruments.

-

-

- Slurs - -
-

-

In MEI, slurs may be encoded in a similar way to ties: note and chord bear a slur attribute that allows the commencement or ending of a slur at this element. The allowed values, however, are slightly different: The i, m or t are followed by a single digit in the range 1 to 6, as in the following example:

-

-

- - <layer> - <note accid="s" dur="4" oct="4" pname="f" slur="i1"/> - <note dur="4" oct="4" pname="g" slur="m1"/> - <note dur="4" oct="4" pname="a" slur="t1"/> -</layer> - -
-

-

The reason for this difference is that slurs, unlike ties, may overlap, so that a second slur may start while the first slur is still ongoing. The digit indicates the level of nesting of slurs on the note; ‘1’ indicates no nesting, while ‘2’ indicates the existence of 2 slurs in which this note participates, and so on. In the example below, the second and third quarter notes lie under 2 slurs. The second note is covered by the slur that begins on the preceding note and by the one that it starts. The third note is affected by the slur that begins on note one and by the one that starts on note two.

-

-

- - <staff> - <layer> - <note dur="2" oct="4" pname="g" slur="i1"/> - <note dur="8" oct="4" pname="a" slur="i2"/> - <note dur="8" oct="4" pname="g" slur="t2"/> - <note accid="s" dur="4" oct="4" pname="f" slur="t1"/> - </layer> - <layer> - <note dots="1" dur="2" oct="3" pname="b" slur="i1"/> - <note dur="4" oct="4" pname="d" slur="t1"/> - </layer> -</staff> - -
-

-

To support analytical operations, slur may take on more than one value. For example, the example above may be more explicitly encoded as:

-

-

- - <staff> - <layer> - <note dur="2" oct="4" pname="g" slur="i1"/> - <note dur="8" oct="4" pname="a" slur="m1 i2"/> - <note dur="8" oct="4" pname="g" slur="m1 t2"/> - <note accid="s" dur="4" oct="4" pname="f" slur="t1"/> - </layer> - <layer> - <note dots="1" dur="2" oct="3" pname="b" slur="i1"/> - <note dur="4" oct="4" pname="d" slur="t1"/> - </layer> -</staff> - -
-

-

In this encoding, the notes in the beamed group are marked as participating in two slurs – one connecting just the beamed notes and one connecting the first and last notes of the layer. In ‘nested’ slurs like this, the function of the slurs is usually different. Here, the slur connecting the 8th notes indicates legato performance, while the longer slur functions as a phrase mark.

-

While ties are not normally allowed to cross layers or staves, slurs may. The following example demonstrates how cross-staff slurs may be encoded using the slur attribute:

-

-

- - <measure> - <staff> - <layer> - <note dur="4" oct="4" pname="g" slur="i1"/> - <note dur="8" oct="4" pname="a" slur="m1"/> - <note dur="8" oct="4" pname="g" slur="m1"/> - <note accid="s" dur="4" oct="4" pname="f" slur="m1"/> - </layer> - </staff> - <staff> - <layer> - <note dots="1" dur="2" oct="3" pname="b"/> - <note dur="4" oct="4" pname="d" slur="t1"/> - </layer> - </staff> -</measure> - -
-

-

Slurs and ties that cross system or page breaks are often split into two separate symbols for rendering. One slur or tie ends at the last bar line, another one starts at the beginning of the new system. MEI expects this to be the default rendering behavior, so that in situations like these, the regular tie or slur attributes are sufficient to describe both curved lines resulting from the split.

-

Sometimes, however, one of these two symbols is missing in the document, or the encoder wants to provide additional (often visual) information about the slur or tie. In these cases, using an attribute is not an adequate solution. Therefore, MEI offers dedicated tie and slur elements. A third element, phrase, is used to identify a unified melodic idea (in German: Phrasierungsbogen), whereas the slur element is used as a generic element for all curved lines (in German: Bogensetzung) except ties. All three elements have nearly identical models.

-

Another reason for using elements instead of attributes for ties, slurs, and phrase marks is that only elements may be combined with the functionality provided in chapters and of these Guidelines.

-

Although these elements are allowed within a layer to accommodate unmeasured notation, by convention in CMN they are normally placed inside measure, after the encoding of staves, alongside other so-called ‘control events’.

-

-

- - <measure> - <staff n="1"> - <layer> - <note dur="4" oct="5" pname="c"/> - <note dur="4" oct="4" pname="f"/> - <note dur="4" oct="4" pname="g"/> - <note dur="4" oct="4" pname="c"/> - </layer> - </staff> - <slur/> - <tempo/> - <dynam/> -</measure> - -
-

-

Obviously, to be complete the slur in the above example needs to be ‘attached’ to the notes somehow. The ‘vertical assignment’ can be indicated for the example above using the staff and layer attributes like so:

-

-

- - <slur layer="1" staff="1"/> - -
-

-

For the ‘horizontal assignment’, the encoder may choose between two different mechanisms. The first uses two timestamp attributes as described in section . The start and end points of the slur may be indicated thusly:

-

-

- - <slur layer="1" staff="1" tstamp="1" tstamp2="0m+4"/> - -
-

-

By using tstamp and tstamp2 attributes, the encoder denotes a rather loose connection – the slur (or tie) is attached to a certain position in the measure, not to a specific note or chord. If the encoder wants to specify a close connection to a particular event, the startid and endid attributes may be used instead. Here, the xml:ids of the first and last note of the slur are referenced. This mechanism also allows the crossing of layers and staves.

-

For human readability, it is recommended to encode slur, tie and phrase features in the measure where they begin; that is, in the measure that holds the element referenced by startid. On the other hand, for machine processability, it may be desirable to place slur, tie, and phrase elements in the measure where they end or even in the last measure regardless of their beginning and ending points in the music. This last option makes all references contained within these elements ‘back references’. Back references are necessary when using processing software that treats the encoded file as a stream; that is, programs that process the file without creating an in-memory representation of its contents.

-

When using the tie, slur or phrase elements, the curvature of the line may be described using the curvedir, bulge and bezier attributes. Whereas the first attribute allows only specification of the slur’s vertical placement, the others give increasingly more precise control of the curve.

-

If the encoder wishes to draw attention to the appearance of a slur or tie in a given source, the facs attribute may be used instead of (or in addition to) the curve description attributes to point to a graphic image or a zone within an image (see ).

-
-
- Dynamics in CMN -

Common Music Notation provides two different methodologies for expressing the volume of a note, phrase, section, etc. The first is a verbal instruction providing such information in human language, possibly in an abbreviated form. An example is the word piano, indicating a quiet volume, often abbreviated as p. In MEI, verbal instructions like this are encoded using the dynam element from the Shared module (see chapter ):

- - <dynam>p</dynam> - -
-

-

By convention, dynam elements, like slur and other elements belonging to the model.controlEventLike class, are encoded at the end of the measure to which they belong. This requires dynam to be assigned to a certain staff using the staff attribute, whose value refers to the target element’s n attribute. In the absence of other information, all layers within the staff are assumed to have the same dynamic marking.

-

-

- - <dynam staff="1" tstamp="1">p</dynam> - -
-

-

However, when the layers of a staff have different dynamic indications, the layer attribute may be used to associate a dynamic marking with a particular layer:

-

-

- - <measure> - <dynam layer="1" tstamp="1">p</dynam> - <dynam layer="2" tstamp="1">mf</dynam> -</measure> - -
-

-

A suitable MIDI value may be assigned to a dynamic marking using the val attribute:

-

-

- - <dynam layer="1" place="above" staff="2" tstamp="1" val="84">f</dynam> - -
-

-

The location of a dynamic marking in relation to a staff may be specified using the place attribute, which may be given as above, within, or below the staff:

-

-

- - <dynam place="above" staff="1" tstamp="1">p</dynam> - -
-

-

Dynamics must also be associated with a particular time point in a measure, using the tstamp, or with a particular event, using the startid attribute. Linking a control event with measures and events is discussed in section :

-

-

- - <measure> - <staff n="1"> - <!-- content omitted --> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="2" oct="4" pname="c" stem.mod="2slash"/> - <note dur="2" oct="4" pname="e" stem.mod="2slash"/> - </layer> - <layer n="2"> - <!-- content omitted --> - </layer> - </staff> - <dynam layer="1" place="above" staff="2" tstamp="1">p</dynam> - <dynam layer="1" place="above" staff="2" tstamp="2.5">cresc. poco a poco</dynam> -</measure> - -
-

-

Dynamics which do not have an explicit endpoint are often referred to as ‘instantaneous’. On the other hand, some dynamic directions indicate a continuous change that must have a defined end point. It is possible to specify the logical scope of continuous dynamic marks using the attributes tstamp2, dur, dur.ges, or endid. Additionally a corresponding ending value for MIDI output may be given in the val2 attribute.

-

To capture the fact that the crescendo in the example above continue until the first beat of the next measure, they may be marked:

-

-

- - <!-- using the tstamp2 attribute --><dynam place="above" staff="2" tstamp="2.5" tstamp2="1m+1">cresc. poco a poco</dynam> - -
-
- - <!-- using the endid attribute --><dynam endid="#ID_of_ending_note" place="above" staff="2" tstamp="2.5">cresc. poco a poco</dynam> - -
-

-

Any combination of tstamp, startid, tstamp2, and endid attributes may be used to define the scope of a dynamic, although the tstamp and tstamp2 or the startid and endid combinations are the most logical combinations. For example, the following alternatives are all possibilities for encoding up a crescendo. The choice of attributes is often task or processor dependent.

-

-

- - <!-- tstamp attribute indicates starting point, dur attribute marks the end --><dynam place="above" staff="2" tstamp="3" dur="1">cresc. poco a poco</dynam> - -
-
- - <!-- tstamp attribute indicates starting point, endid attribute marks the end --><dynam endid="#ID_of_last_note" place="above" staff="2" tstamp="3">cresc. poco a poco</dynam> - -
-
- - <!-- startid attribute indicates starting point, tstamp2 attribute marks the end --><dynam place="above" - staff="2" - startid="#ID_of_first_note" - tstamp2="1m+3">cresc. poco a poco</dynam> - -
-
- - <!-- startid attribute indicates starting point, endid attribute marks the end --><dynam endid="#ID_of_last_note" - place="above" - staff="2" - startid="#ID_of_first_note">cresc. poco a poco</dynam> - -
-

-

All musical elements affected by the dynam may be explicitly specified using the plist attribute, which contains xml:id attribute value references:

-

-

- - <dynam endid="#note4" - place="above" - plist="#note1 #note2 #note3 #note4" - staff="2" - startid="#note1">cresc. poco a poco</dynam> - -
-

-

It is recommended that the list of references in plist include all participants in the dynamic marking, including the first and last notes as in the preceding example, even though they are duplicated by startid and endid attributes.

-

In addition to verbal instructions, Common Music Notation uses graphical symbols to indicate ‘continuous’ dynamics. These crescendo and decrescendo (or diminuendo) symbols are encoded in MEI using the hairpin element. It also is a member of the model.controlEventLike class, which means it too is used just before the close of a measure element, following the encoding of all staves. The required attribute form specifies the direction of the symbol by taking one of two possible values: cres (growing louder) or dim (getting softer).

-

-

- - <hairpin form="cres"/> - -
-

-

Marking the logical extent of hairpins is possible using the same attributes as for dynam.

-

-

- - <hairpin form="cres" - layer="1" - place="above" - staff="2" - tstamp="2.5" - tstamp2="1m+1"/> - -
-

-

The following example from Béla Bartók’s - Mikrokosmos, Sz.107 shows a diminuendo between two staves that begins on the first beat (in the current measure) and ends on the first one in the penultimate measure. The duration is highlighted with a dashed line, which can be indicated with the extender attribute.

-

-

- A diminuendo in Bartók’s In Phrygian Mode - -
-
- - <dynam tstamp="1" - tstamp2="2m+1" - extender="true" - place="between" - staff="1 2">dim.</dynam> - -
-

-
-
- Tuplets -

Tuplets indicate a localized change of meter; that is, a given duration in the regular meter is divided between a group of notes with irregular (according to the current meter) rhythmic values. The most common tuplet is a so-called ‘triplet’, in which three notes take the time normally occupied by two.

-

The relation of the tuplet to the underlying meter is specified using the num and numbase attributes, where num specifies the number of replacing notes and numbase specifies the number of notes of the same duration to be replaced. For example, when three eighth notes replace one quarter note in common time, num takes a value of "3", whereas numbase reads "2", because a quarter note in common time is normally divided into two eighths. When three quarters replace two in the same meter, numbase also reads "2". The combination of these attributes may be read as "3 in the time of 2" in either case.

-

-

- Tuplet rhythms from Maurice Ravel’s Boléro - -
-
- - <tuplet num="3" numbase="2"> - <note dur="16"/> - <note dur="16"/> - <note dur="16"/> -</tuplet> - -
-

-

The duration of the entire tuplet may be encoded using the usual ‘power of 2’ values, e.g., 1, 2, 4, etc., in the dur attribute if necessary.

-

-

- - <layer> - <tuplet dur="2" num="3" numbase="2"> - <note dur="4" oct="4" pname="g"/> - <note accid="s" dur="4" oct="4" pname="f"/> - <note dur="4" oct="4" pname="g"/> - </tuplet> - <note dur="2" oct="4" pname="d"/> -</layer> - -
-

-

Tuplets are often highlighted using brackets above or below the affected notes. The presence and position of these brackets can be encoded using the bracket.place (above / below) and bracket.visible (true / false) attributes.

-

Usually, however, tuplets are rendered with a bracket (bracket.visible="true") and a single number (num.format="count" and num.visible="true"), as seen in the example above. However, the number-to-numbase ratio may be provided in addition to, or in some cases as a replacement for, the bracket. The num.format attribute indicates whether a plain number (the value of num) or a ratio (comprised of num and numbase, e.g., "3:2") should be displayed and num.visible indicates the general presence of such a number.

-

Further visual control comes with the num.place and bracket.place attributes, that allow specific placement of the number and the bracket above or below the staff.

-

In addition to note elements, tuplet may contain other elements, such as rest or space, to match the content of a source document or an intended rendering. In particular, the beam element is allowed so that custom beaming may be indicated, e.g., a septuplet may be divided into a group of three plus a group of four notes.

-

The tuplet element may also be used for repetition of the same pitch; that is, a single note or chord may be the only content of the tuplet. In some cases, optical music recognition software may treat these instances as bowed tremolandi due to the knowledge of the complete semantics of the notation at the time of recognition. However, marking these as tuplets is the recommended practice.

-

In some situations, a tuplet is made up of events in different measures. As this raises the issue of non-concurrent hierarchies, it is not possible to encode such situations with the tuplet element described above. Therefore, MEI offers the tupletSpan element, which is member of the model.controlEventLike class. It is nested inside of measure, following all the measure’s staff children. It uses the same attributes as tuplet to describe tuplets, but instead of nesting all affected notes inside itself, it references the xml:id values of all affected notes in its plist attribute and the initial and terminal notes of the tuplet using startid and endid attributes. This configuration allows tuplets to cross beams or measure boundaries. The following example demonstrates a typical example of such hierarchy-crossing tuplets:

-

-

- Hierarchy-crossing tuplets - -
-
- - <tupletSpan num="3" - numbase="2" - startid="#rest" - endid="#note2" - plist="#rest #note1 #note2"/> - -
-

-
-
- Articulation and Performance Instructions in CMN -

This section introduces elements and attributes which may hold CMN-specific performance instructions. The functionality described herein is related to the artic attribute and artic element introduced in . The following elements are relevant in this context:

-

- - - - - - - - - -

-
- Arpeggio and Glissando -

In CMN, the notes of a chord are sometimes performed successively rather than simultaneously. This behavior, called arpeggiation, is normally indicated using a vertical wavy line preceding the chord. MEI offers the arpeg element to describe arpeggios. This element is a member of the model.controlEventLike.cmn class and, like other members of this class, uses the staff, layer and tstamp or the startid and plist attributes to connect it to the affected chord.

-

-

- - <measure> - <staff n="1"> - <!-- content omitted --> - </staff> - <staff n="2"> - <layer> - <note dur="4"/> - <note dur="4"/> - <chord dur="4"> - <!-- notes omitted --> - </chord> - <note/> - </layer> - </staff> - <arpeg staff="2" tstamp="3"/> -</measure> - -
-

-

For arpeggios that involve chords spanning multiple staves as a continuous arpeggio (instead of two separate arpeggios), the plist attribute should be used to point to all affected chord and single note elements’ xml:id attributes. Therefore, the use of the plist attribute is sufficient in many cases, so that other attributes from above may be omitted.

-

-

- Spanning arpeggios in Liszt’s Mazeppa study - -
-
- - <arpeg xml:id="ex-0149852838" plist="#ex-0731379794 #ex-1553574041" /> -<arpeg xml:id="ex-1483377242" plist="#ex-1474174387 #ex-0553655856" /> - -
-

-

The usual direction for the performance of an arpeggio is from lowest note to highest, but this is not always the case. The customary signal of an downward arpeggio is an arrowhead added to the bottom of the wavy line. The indication of the presence of an arrowhead and the direction of the arpeggio are handled separately, however. The arrow attribute indicates the presence of an arrowhead in the arpeggiation sign, while the order attribute records the preferred sequence of notes. Béla Bartók uses a wavy line behind the chord to indicate a downward arpeggio. In such cases, the ho attribute can be used to indicate the offset from the usual position.

-

The following examples illustrate various ways in which the arrow and order attributes may be employed. The default visual rendition and performance are assumed in the absence of both attributes, while the typical downward arpeggio is indicated by the presence of both attributes. The last two possibilities occur less frequently, but are sometimes appropriate: The presence of the arrow attribute without the order attribute may be used in those cases where the arrowhead is redundant but is added to the symbol for the sake of consistency or when the direction of successive arpeggios changes frequently. The last possibility, an order attribute without an arrow attribute, is ambiguous; however, it can be used as an encoding shortcut since a downward arpeggio must have a visual indication of its direction to distinguish it from the upward arpeggio; therefore, the presence of the arrowhead can be implied.

-

-

- - <!-- default visualization and performance --><arpeg staff="2" tstamp="3"/> - -
-
- - <!-- downward arpeggio with arrow added to visual symbol --><arpeg arrow="true" order="down" staff="2" tstamp="3"/> - -
-
- - <!-- default rendition with (redundant) arrow added to the top of the visual symbol --><arpeg arrow="true" staff="2" tstamp="3"/> - -
-
- - <!-- downward arpeggio with no visual indication of order --><arpeg order="down" staff="2" tstamp="3"/> - -
-

-

A third, and somewhat counter-intuitive, value for order, nonarp, indicates that no arpeggio shall be performed. Normally rendered as a bracket instead of a wavy line, this form of arpeggio is used to indicate a non-arpeggiated chord intervening in a sequence of arpeggiated ones. This is common in music for the harp, where arpeggiation is the usual method of performing chords and deviation from the norm must be explicitly indicated.

-

Whereas an arpeggio ‘staggers’ the onset times of the notes of a chord, a glissando denotes a situation where the pitch ‘slides’ from one note to another. It makes no difference whether this slide produces distinct intermediate pitches (as on the piano) or not (as on the trombone), though the latter is sometimes referred to as portamento. The visual appearance of a glissando, which MEI encodes as gliss, is normally a line connecting two notes in the glissando.

-

-

- A simple glissando in Tárrega’s Alborada from a leading grace note - -
-
- - <gliss startid="#startgliss" endid="#endgliss"/> - -
-

-

The gliss element is a member of the model.controlEventLike class and therefore, like other control events, it occurs inside a measure after the staves and uses its staff, layer, tstamp, tstamp2, startid and endid attributes to connect it to the affected notes or chords. It is a semantic error not to specify a starting point attribute. The visual appearance of the indicating line may be recorded in the lform and lwidth attributes.

-
-
- Bend -

A bend is a variation in pitch (often microtonal) upwards or downwards during the course of a note. Typically, the performer attacks the note at ‘true’ pitch, changes the intonation, then returns to true pitch. The bend element can also be used for so-called scoop, plop, falloff, and doit performance effects. It should not be used for laissez vibrer (l.v.) indications. As with other elements in the model.controlEventLike class, the starting point of the bend may be indicated by either a tstamp, tstamp.ges, tstamp.real or startid attribute. It is a semantic error not to specify a starting attribute.

-
-
- Tremolandi -

CMN has two slightly different concepts which are both called tremolo. The first is a rapid repetition of a single pitch or chord, whereas the second is a rapid alternation between two different notes or chords. In addition, either species of tremolo may be measured or unmeasured. A measured tremolo is an abbreviation for written-out notation; that is, the tremolo is intended to be perceived as notes with distinct rhythmic values. On the other hand, in an unmeasured tremolo no specific number of alternations is intended.

-

For the repetition of a single note or chord, MEI offers the bTrem (bowed tremolo) element, which is a member of the model.eventLike.cmn class, meaning it is encoded following the normal course of musical events within a layer. It holds exactly one note or chord element that is to be repeated.

-

-

- Bowed tremolandi in Schubert’s last string quartet - -
-
- - <layer> - <bTrem unitdur="32"> - <note dur="2" oct="4" pname="e" stem.mod="3slash"> - <accid accid="n"/> - </note> - </bTrem> - <bTrem unitdur="32"> - <chord dur="4" stem.mod="3slash"> - <note oct="4" pname="e"/> - <note oct="4" pname="d"> - <accid accid="s"/> - </note> - </chord> - </bTrem> - <bTrem unitdur="32"> - <chord dur="4" stem.mod="3slash"> - <note oct="4" pname="e"/> - <note oct="4" pname="c"> - <accid accid="s"/> - </note> - </chord> - </bTrem> -</layer> - -
-

-

The unitdur attribute value indicates the exact note values in an aural rendition of a measured tremolo, i.e., quarters, 8ths, and so on. The stem.mod attribute must also be explicity set on the child note or chord element for a complete visual representation. The example above shows a short excerpt from the second movement of Franz Schubert’s - String Quartet in G major, D. 887).

-

However, the number of slashes present on the note may disagree with the number of slashes that should be present according to the unitdur attribute, especially in music manuscripts.

-

-

- - <bTrem unitdur="64"> - <note dur="4" oct="4" pname="g" stem.mod="2slash"/> -</bTrem> - -
-

-

Note that within beams the number of slashes should be adjusted anyway.

-

-

- - <beam> - <bTrem unitdur="32"> - <note dots="1" dur="8" oct="4" pname="b" stem.mod="2slash"/> - </bTrem> - <bTrem unitdur="32"> - <note dots="1" dur="16" oct="4" pname="b" stem.mod="1slash"/> - </bTrem> -</beam> - -
-

-

The bTrem element can be used as shorthand for a tuplet consisting of repetitions of a single note or chord. This kind of markup may be the result of an optical music recognition process in which complete semantics cannot be determined a priori. When used this way, the num attribute on bTrem can record a number to be rendered along with the pseudo-tuplet. In spite of this capability, the tuplet element is preferred. This makes the following examples’ visual appearance equal, but not necessarily their semantics.

-

-

- - <bTrem num="3"> - <note dur="4" oct="4" pname="g" stem.mod="3slash"/> -</bTrem> - -
-
- - <tuplet num="3" numbase="2"> - <bTrem> - <note dur="4" oct="4" pname="g" stem.mod="3slash"/> - </bTrem> -</tuplet> - -
-

-

In the case of alternating pitches, MEI offers the fTrem (fingered tremolo) element. While it mostly behaves the same as bTrem, a fingered tremolo requires exactly two child elements, either being a note or chord. The unitdur attribute value indicates the exact note values in an aural rendition of a measured tremolo, i.e., 4ths, 8ths, 16ths, etc. The number of beams present in the source is captured by the beams attribute.

-

-

- Fingered tremolos - -
-
- - <fTrem unitdur="32"> - <note pname="f" oct="4" dur="4"/> - <note pname="a" oct="4" dur="4"/> -</fTrem> - -
-

-

Similar to bTrem, here the number of beams present may disagree with the rhythmic value indicated by the unitdur attribute, especially in manuscript sources. The number of so-called ‘floating’ beams, which are not attached to stems, may be encoded in the beams.float attribute.

-

-

- Tremolos with floating beams - -
-

-
-
- Fermata -

A very common feature of music notation from the CMN period is the so-called ‘fermata’ (or ‘corona’ in Italian). It is usually written as a dot above or below an arc. It may stand above or below the staff it affects with its ‘open’ side usually facing towards the staff. A fermata indicates that a related note or rest should be held longer than its written duration would normally require. Sometimes, a fermata occurs over or under a bar line to indicate a pause or even the end of a phrase or section.

-

-

- The probably most famous fermatas in history from Beethoven’s fifth symphony - -
-

-

In MEI, fermatas may be encoded using an attribute on elements like note, chord or rest. This attribute allows placement of a fermata above or below the element to which it’s attached.

-

-

- Fermatas in Mozart’s String quartet K. 428 indicating general pauses - -
-

-

-

- - <mRest fermata="above"/> - -
-

-

However, if there is further (visual) information about the fermata that should be addressed in the encoding, MEI offers the fermata element. This element, which is a member of the model.controlEventLike.cmn class and therefore requires the use of such attributes as staff, layer, tstamp and startid, allows specification of the orientation of the fermata using its form attribute. In addition, the shape attribute may be used to indicate whether the fermata is rendered as the common semicircle ("curved"), a semisquare ("square"), or a triangle ("angular"). If the fermata should be rendered using some other symbol, a user-defined symbol may be referred to using an altsym attribute or the glyph.name and glyph.num attributes respectively.

-

-

- - <fermata form="inv" - place="above" - shape="square" - staff="2" - tstamp="4"/> - -
-
- - <fermata altsym="#myFermata.1" place="above" staff="2" tstamp="5"/> - -
-

-
-
- Octave Shift -

An indication that a passage should be performed one or more octaves above or below its written pitch is represented by the octave element.

-

-

- - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Octave shift example</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>Example use of the "octave" element for octave shifts. For correct MIDI output, the - "oct.ges" attribute needs to be provided.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef n="1"> - <staffGrp> - <staffDef n="1" lines="5" clef.shape="G" clef.line="2" /> - </staffGrp> - </scoreDef> - <?edit-start?> - <section> - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="2" oct="6" pname="e" /> - <beam> - <note dur="8" oct="6" pname="f" /> - <note dur="8" oct="6" pname="a" /> - <note dur="8" oct="6" pname="g" /> - <note dur="8" oct="6" pname="b" /> - </beam> - </layer> - </staff> - </measure> - <measure right="dbl" n="2"> - <staff n="1"> - <layer n="1"> - <note dur="1" oct="7" pname="c" /> - </layer> - </staff> - </measure> - <measure n="3"> - <staff n="1"> - <layer n="1"> - <note xml:id="n1" dur="2" oct.ges="6" oct="5" pname="e" /> - <beam> - <note dur="8" oct.ges="6" oct="5" pname="f" /> - <note dur="8" oct.ges="6" oct="5" pname="a" /> - <note dur="8" oct.ges="6" oct="5" pname="g" /> - <note dur="8" oct.ges="6" oct="5" pname="b" /> - </beam> - </layer> - </staff> - <octave startid="#n1" endid="#n2" dis="8" dis.place="above" /> - </measure> - <measure right="dbl" n="4"> - <staff n="1"> - <layer n="1"> - <note xml:id="n2" dur="1" oct.ges="7" oct="6" pname="c" /> - </layer> - </staff> - </measure> - <measure n="5"> - <staff n="1"> - <layer n="1"> - <note xml:id="n3" dur="2" oct.ges="2" oct="3" pname="e" /> - <beam> - <note dur="8" oct.ges="2" oct="3" pname="f" /> - <note dur="8" oct.ges="2" oct="3" pname="a" /> - <note dur="8" oct.ges="2" oct="3" pname="g" /> - <note dur="8" oct.ges="2" oct="3" pname="b" /> - </beam> - </layer> - </staff> - <octave startid="#n3" endid="#n4" dis="8" dis.place="below" /> - </measure> - <measure right="dbl" n="6"> - <staff n="1"> - <layer n="1"> - <note xml:id="n4" dur="1" oct.ges="3" oct="4" pname="c" /> - </layer> - </staff> - </measure> - <measure n="7"> - <staff n="1"> - <layer n="1"> - <note xml:id="n5" dur="2" oct.ges="2" oct="4" pname="e" /> - <beam> - <note dur="8" oct.ges="2" oct="4" pname="f" /> - <note dur="8" oct.ges="2" oct="4" pname="a" /> - <note dur="8" oct.ges="2" oct="4" pname="g" /> - <note dur="8" oct.ges="2" oct="4" pname="b" /> - </beam> - </layer> - </staff> - <octave startid="#n5" tstamp2="1m+4.0000" dis="15" dis.place="below" /> - </measure> - <measure right="dbl" n="8"> - <staff n="1"> - <layer n="1"> - <note xml:id="n6" dur="1" oct.ges="3" oct="5" pname="c" /> - </layer> - </staff> - </measure> - <measure n="9"> - <staff n="1"> - <layer n="1"> - <note xml:id="n7" dur="2" oct.ges="2" oct="3" pname="e" /> - <beam> - <note dur="8" oct.ges="2" oct="3" pname="f" /> - <note dur="8" oct.ges="2" oct="3" pname="a" /> - <note dur="8" oct.ges="2" oct="3" pname="g" /> - <note dur="8" oct.ges="2" oct="3" pname="b" /> - </beam> - </layer> - </staff> - <octave startid="#n7" endid="#n8" lwidth="0.5000vu" dis="8" dis.place="below" /> - </measure> - <measure right="dbl" n="10"> - <staff n="1"> - <layer n="1"> - <note xml:id="n8" dur="1" oct.ges="3" oct="4" pname="c" /> - </layer> - </staff> - </measure> - <measure n="11"> - <staff n="1"> - <layer n="1"> - <note xml:id="n9" dur="2" oct.ges="4" oct="3" pname="e" /> - <beam> - <note dur="8" oct.ges="4" oct="3" pname="f" /> - <note dur="8" oct.ges="4" oct="3" pname="a" /> - <note dur="8" oct.ges="4" oct="3" pname="g" /> - <note dur="8" oct.ges="4" oct="3" pname="b" /> - </beam> - </layer> - </staff> - <octave startid="#n9" tstamp2="1m+4.0000" lform="solid" dis="8" dis.place="above" /> - </measure> - <measure right="dbl" n="12"> - <staff n="1"> - <layer n="1"> - <note dur="1" oct.ges="5" oct="4" pname="c" /> - </layer> - </staff> - </measure> - </section> - <?edit-end?> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

Its dis and dis.place attributes record the amount and direction of displacement, respectively. The lform attribute captures the appearance of the continuation line associated with the octave displacement. The starting point of the octave displacement may be indicated by either a tstamp, tstamp.ges, tstamp.real or startid attribute, while the ending point may be recorded by either a tstamp2, dur, dur.ges or endid attribute. It is a semantic error not to specify one starting-type attribute and one ending-type attribute.

-
-
-
- Instrument-specific Symbols in CMN -

CMN contains a number of symbols which are closely related to a specific instrument. MEI offers elements for three of these symbols, namely breath marks, harp pedal diagrams, and piano pedals.

-
- Breath Marks -

A breath mark indicates a point at which the performer of a wind instrument or singer may breathe. It is sometimes also used to indicate a short pause or break for instruments not requiring breath, which allows it to also serve as a guide to phrasing. In MEI, breath marks are encoded using the breath element, which is a member of model.controlEventLike.cmn. It is a semantic error not to specify a starting point attribute.

-

-

- - <measure> - <staff n="1"> - <layer> - <note dur="2" oct="3" pname="g" syl="Wald,"/> - <note dur="4" oct="3" pname="c" syl="so"/> - </layer> - </staff> - <breath staff="1" tstamp="1.5"/> -</measure> - -
-

-

The usual sign for the breath mark is a comma; however, other visual forms of the breath mark may be indicated using the altsym attribute (see chapter for further details).

-
-
- Harp Pedals -

Modern harps have seven pedals which allow adjustment of their strings to different pitches. The settings for these pedals occur at the beginning of the harp notation and/or whenever it is necessary to change the harp’s tuning. These settings may be rendered using letter pitches (in the order of the pedals from left to right) or in a diagrammatic fashion, such as the form invented by Carlos Salzedo.

-

In MEI, harp pedal settings are encoded using the harpPedal element. It is a member of the model.controlEventLike.cmn class and is therefore placed within measure, following all staff children. The staff and layer attributes may be used to assign it to a certain staff or layer. Either a tstamp or startid attribute must be used to indicate the placement within the measure (see and for further details about those linking mechanisms).

-

The musical intention of the element is described using the c, d, e, f, g, a and b attributes, which affect the corresponding strings of the harp. All of these attributes may take the values f (flat), s (sharp) or n (natural), where a natural is the default value, which is assumed when one of these attributes is not specified.

-

-

- Harp pedal diagrams - -
-
- - <measure> - <!-- staves omitted --> - <harpPedal tstamp="1" c="s" b="f" e="f"/> -</measure> - -
-

-

In the first diagram of the preceding example, the B, and E pedals are in the flat position, while the C pedal is in sharp position. The other, non-specified pedals are in the natural position.

-
-
- Piano Pedal -

Music for piano also often includes indications of the use of pedals. In MEI, these symbols are encoded using the pedal element. As a member of the model.controlEventLike.cmn class, it is located within measure and refers to a staff, layer and timestamp using the staff, layer and tstamp attributes. Alternatively, the startid attribute may be used to identify a note or chord to which the mark should be assigned.

-

The meaning of the mark is captured using the dir attribute, which provides the following values:

- - - depress the pedal - - release the pedal - - release, then immediately depress the pedal again - - depress the pedal half way - -

-

- - <measure> - <!-- staves omitted --> - <pedal dir="down" staff="2" tstamp="1"/> -</measure> - -
-

-

To specify the pedal, that has to be used, the func attribute allows the following values:

- - - The sustain pedal, also referred to as the "damper" pedal, allows the piano strings to vibrate sympathetically with the struck strings. It is the right-most and the most frequently used pedal on modern pianos. (Often marked with: ) - - The soft pedal, sometimes called the "una corda", "piano", or "half-blow" pedal, reduces the volume and modifies the timbre of the piano. On the modern piano, it is the left-most pedal. - - The sostenuto or tone-sustaining pedal allows notes already undamped to continue to ring while other notes are damped normally; that is, on their release by the fingers. This is usually the center pedal of the modern piano. (Often marked with: ) - - The silent or practice pedal mutes the volume of the piano so that one may practice quietly. It is sometimes a replacement for the sostenuto pedal, especially on an upright or vertical instrument. - -
-
- Fingering -

A common feature for keyboard music is fingering, indicating the finger, which should be used to play a single note. Basic fingering can be encoded in MEI using the fing element, which is a member of the model.fingeringLike class, and thus part of the model.controlEventLike class.

-

The following example, taken from Charles-Louis Hanon’s - Le Pianiste virtuose, shows typical fingering:

-

-

- Fingering in Hanon’s exercise no. 21 - -
-
- - <fing startid="#ex_2099285249" place="above">1</fing> - -
-
- - <fing startid="#ex_0938118303" place="below">5</fing> - -
-

-
-
-
- Ossia -

The term ossia, Italian for "or", denotes an alternative for a certain passage which is provided by the composer without any preference of one alternative over another. An ossia often provides a simpler (easier to perform) version of the original content. Another frequent use case for ossia is the provision of indications about performance practice, such as an alternative version with ornamentation written out in full. In all cases, it is up to the performer to choose between the alternatives.

-

Most often an ossia is rendered above the main staff on a reduced-size staff. Sometimes, however, the alternate material occurs on the same staff as the primary text, but in a separate layer. In this case, the alternative material is usually rendered in small-sized notation on the normal-sized staff. For both situations, MEI offers the ossia element, which may be nested either inside measure to reflect an ossia on a separate staff, or inside staff to reflect an inline ossia in a separate layer. The following example demonstrates an ossia on a separate staff:

-

-

- - <measure> - <staff n="1"> - <!-- first staff, without ossia --> - </staff> - <ossia> - <staff> - <!-- alternative content on reduced-size staff --> - </staff> - <staff n="2"> - <!-- original content on regular staff --> - </staff> - </ossia> - <staff n="3"> - <!-- third staff, without ossia --> - </staff> -</measure> - -
-

-

The example above demonstrates that only one of the two staff elements within ossia has an n attribute. This mechanism allows one to distinguish between the "regular" and the "alternative" content: The one bearing the n attribute goes in line with the preceding measure’s staff, the other one is printed in reduced size above. In this case, the vertical order of staves follows document order: The top-most staff is encoded as the first child, the lowest comes last. In combination with the presence of the n attribute, this allows the capture of multiple simultaneous ossia staves.

-

All staves within ossia, even the alternative ones without a direct reference, obey the definitions of the associated staffDef, which can be derived from the value of the n attribute. Alternatively, a separate staffDef may be given at the beginning of the contained layer element(s).

-

In case of an inline ossia, the whole setup of elements moves down one step in the hierarchy, as seen in the following example:

-

-

- - <measure> - <staff n="1"> - <!-- content omitted --> - </staff> - <staff n="2"> - <ossia> - <layer n="1"> - <!-- original content in regular layer --> - </layer> - <layer> - <!-- alternative content in separate layer --> - </layer> - </ossia> - </staff> - <staff n="3"> - <!-- content omitted --> - </staff> -</measure> - -
-

-
-
- Cue -

Cue notes are smaller notes that usually occur in an orchestral or vocal part and are not to be played or sung by the corresponding musician, but by other instruments or singers. Cue notes are used for orientation, i.e., to follow the music during longer pauses and to find the correct re-entry point more easily. In MEI the cue attribute is available to indicate such notes.

-

-

- - <rest dur="8" cue="true"/> -<note dur="4" oct="5" pname="f" cue="true"/> - -
-

-

Most often cue notes occur in a group rather than one by one. This is because usually a whole layer of another part is inserted as a cue. Therefore, a complete layer can also be marked as cue.

-

-

- Cue notes in the flute part of Brahms’ Ein deutsches Requiem. - -
-
- - <score> - <scoreDef> - <staffGrp> - <staffDef n="1" lines="5"> - <clef shape="G" line="2" /> - <keySig sig="5f" /> - <meterSig count="3" unit="4" /> - </staffDef> - </staffGrp> - </scoreDef> - <section> - <measure metcon="false"> - <staff n="1"> - <layer n="1"> - <rest dur="4" /> - </layer> - <layer n="2" cue="true"> - <clef shape="F" line="4" /> - <note dur="4" oct="2" pname="f" /> - </layer> - </staff> - </measure> - <measure n="1"> - <staff n="1"> - <layer n="1"> - <mRest /> - </layer> - <layer n="2" cue="true"> - <note dur="2" oct="2" pname="b" accid.ges="f" /> - <note dur="4" oct="2" pname="f" /> - </layer> - </staff> - </measure> - <measure n="2"> - <staff n="1"> - <layer n="1"> - <rest dur="4" /> - <rest dur="4" /> - <clef shape="G" line="2" /> - <note dur="4" oct="5" pname="b" accid.ges="f" /> - </layer> - <layer n="2" cue="true"> - <note dur="2" oct="2" pname="b" accid.ges="f" /> - </layer> - </staff> - </measure> - </section> -</score> - - -
-

-

If the voice from which the cue notes originate is also encoded, they should refer to their sounding counterpart with the corresp attribute.

-

Cue notes must not be confused with other small notes such as grace notes or fiorituras.

-
-
- Directives and Rehearsal marks -

In CMN scores, there is often a large number of natural language instructions. Some of them concern the loudness and the speed of the performance, in which case MEI offers the elements dynam (described at ) and tempo. In other cases, however, they provide other instructions for the performer. Instead of providing separate elements for all possible types of such directions, MEI offers the generic dir element. Although this element is not CMN specific (it is defined in ), it is frequently used in this repertoire.

-
- Tempo changes and other directives -

A tempo or character indication is often provided above the topmost staff of the first measure of a score, movement, or section. This indication, such as "Allegro moderato" or "Andante maestoso", may be regarded as a label. Though it is possible to label the movement, etc. using a label attribute attached to the enclosing structural entity (that is, on mdiv or section), it is often required to capture the exact position, spelling, or other features of the label as found in the underlying source material. In these cases, an element is necessary.

-

Labels which address the tempo at which the music should be performed should be encoded using the tempo element, which is a specialized form of dir. tempo is a member of the model.controlEventLike class and as such occurs as a child of measure, following all staff children. Its staff, layer and tstamp attributes are used to ensure correct semantic positioning, and place indicates a visual position with respect to the staff.

-

-

- - <measure n="1"> - <!-- all staves omitted --> - <tempo place="above" staff="1" tstamp="1">Allegro moderato</tempo> -</measure> - -
-

-
-
- Rehearsal marks -

Rehearsal marks are another specialized kind of directive. Consisting of letters, numbers, or a combination of both, rehearsal marks are used in scores and corresponding performer parts to identify convenient points to restart rehearsal after breaks or interruptions. For this reason, they are often visually emphasized by placing them within a square or circle. In MEI, they are encoded using the reh element, which holds the textual content of the rehearsal mark. It is a member of the model.controlEventLike.cmn class. The visual rendition of the rehearsal mark, including the surrounding shape, may be captured using the rend element described in chapter .

-

The following detail from an edition of Hector Berlioz’ Symphonie Fantastique shows a typical example:

-

-

- Rehearsal mark - -
-
- - <measure> - <staff n="1"> - <!-- content omitted --> - </staff> - <staff n="2"> - <!-- content omitted --> - </staff> - <staff n="3"> - <!-- content omitted --> - </staff> - <reh place="above" staff="1"> - <rend rend="box">37</rend> - </reh> -</measure> - -
-

-

As rehearsal marks usually are placed at the beginning of a measure the tstamp attribute may be omitted. To place it anywhere else the startid, tstamp or even ho attributes could be used.

-

The following example demonstrates how rehearsal marks often apply to more than one staff. In this instance, the rehearsal mark is placed above staff 1 and below staves 7 and 11.

-

-

- - <measure> - <reh place="above" staff="1">A</reh> - <reh place="below" staff="7 11">A</reh> -</measure> - -
-

-
-
-
- Repetition in CMN -

Repetition is a characteristic feature of music. Many musical forms rely on repetition (sometimes with modification) of distinct sections of the music. Repetition in this sense can be thought of as ‘structural’. At the same time, composers and engravers of music often use local symbols for repeating smaller portions of music instead of writing them in full more than once. In this case, the repetition is better defined as a species of abbreviation.

-
- Structural Repetition -

Large-scale structural repetition, utilizing section and expansion elements, is discussed in section . This section will focus on repetition within sections.

-
-
- Measure-Level Repetition Symbols -

In addition to repetition at the section level, CMN includes a number of different symbols for measure-level repetitions. Many of these symbols are found in manuscripts and may be regarded as personal conventions of their respective authors. Some signs, however, have been widely adopted. For example, it is common to indicate the repetition of a single beat or an entire measure with one or more diagonal lines, sometimes with dots at the upper left and lower right, much like a percent sign. The illustration below contains the most common signs:

-

-

- Beat repeat signs - -
-

-

In general, MEI places primary emphasis on the capture of the semantic meaning of symbols, not their visual rendition. In this case, the focus is on the material being repeated, for example, a beat, a measure, a 2-measure fragment, etc. The following elements are provided for this purpose:

-

- - - - - - - -

-

The beatRpt element is used to represent a single repeated beat. Its visual rendition can be recorded using the slash attribute. This attribute indicates the number of slashes required to render the appropriate repeat symbol, which, as demonstrated in the preceding figure, depends on the rhythmic content of the beat being repeated. When a beat that consists of a single note or chord is repeated, the repetition sign is typically rendered as a single thick, slanting slash; therefore, the value 1 should be used. The following values should be used when the beat is divided into even notes: 4ths or 8ths=1, 16ths=2, 32nds=3, 64ths=4, 128ths=5. When the beat is comprised of mixed duration values, the symbol is always rendered as 2 slashes and 2 dots.

-

In addition to its indication of a repeated beat, the beatRpt element is sometimes used in popular music notation, especially in guitar or percussion parts, to indicate a repeated rhythmic pattern. The beatRpt element can be used, but when these parts require durations longer or shorter than a beat, note elements with appropriately-shaped note heads should be employed instead.

-

The mRpt element is available for repetition of an entire measure. Like mRest, it must be the sole child of layer, no other events should be used. The n attribute of mRpt should not be used to record the number displayed above the measure in the figure below. Instead, the numbering of repetitions of the written-out measure can be enabled using the multi.number attribute available on the scoreDef and staffDef elements.

-

-

- Measure repetition - -
-
- - <section> - <measure> - <staff> - <layer> - <beam> - <note dur="8" oct="4" pname="f"/> - <note dur="16" pname="a"/> - <note oct="5" pname="c"/> - <note dur="8" oct="4" pname="a"/> - </beam> - <beam> - <note dur="8" oct="5" pname="c"/> - <note oct="4" pname="a"/> - <note pname="g"/> - </beam> - </layer> - </staff> - </measure> - <measure> - <staff> - <layer> - <mRpt/> - </layer> - </staff> - </measure> - <measure> - <staff> - <layer> - <mRpt/> - </layer> - </staff> - </measure> - <measure> - <staff> - <layer> - <mRpt/> - </layer> - </staff> - </measure> -</section> - -
-

-

The halfmRpt element represents the incorrect, but frequently found, use of the measure repeat (or similar) sign to indicate repetition of half of a measure. This practice mostly occurs in hand-written notation and usually involves the repetition of the second half of a measure in duple time. This element is necessary because the function of the symbol, not the visual symbol itself, is of primary importance. The following example from the beginning of Beethoven’s Waldstein sonata illustrates such usage:

-

-

- Half-measure repeat - -
-
- - <section> - <measure> - <staff n="1"> - <!-- omitted --> - </staff> - <staff n="2"> - <layer n="1"> - <!-- omitted --> - </layer> - <layer n="2"> - <chord dur="2" stem.mod="1slash"> - <note oct="2" pname="g"> - </note> - <note oct="1" pname="b"> - </note> - </chord> - <halfmRpt/> - </layer> - </staff> - </measure> - <measure> - <staff n="1"> - <!-- omitted --> - </staff> - <staff n="2"> - <layer n="1"> - <!-- omitted --> - </layer> - <layer n="2"> - <halfmRpt/> - <halfmRpt/> - </layer> - </staff> - </measure> -</section> - -
-

-

As seen in the example above, it is possible to continuously repeat half measures, even across bar lines.

-

The mRpt2 and multiRpt elements (like the multiRest element) never occur in scores, only in performer parts, where it is often necessary to abbreviate the notation due to page size limitations.

-

-

- Two-measure repetition - -
-
- Multi-measure repetition - -
-

-

The mRpt2 element represents repetition of a 2-measure fragment, while multiRpt is for repetition of fragments longer than two measures. In modern publishing practice, repeats of more than two measures are written out using repeat signs. This element is provided, however, for handling non-standard practices often found in manuscripts. The num attribute on multiRpt records the number of preceding measures to be repeated.

-

All elements described above allow for association of the sign with a symbol in a digital facsimile (via the facs attribute) and with a user-defined symbol (using altsym). See and for further details. In addition, the expand attribute is available on the foregoing elements to inform a rendering process whether to use the repeat symbol or the full content represented by it. A value of true indicates that the content should be displayed, while a false value means to show only the repeat symbol.

-
-
-
-
- Common Music Notation Ornaments -

This module includes elements and attributes for the encoding of ornaments typical of ‘Common Music Notation’ (CMN). Ornaments are formulae of embellishment that can be realized by adding supplementary notes to one or more notes of the melody. In written form, these are usually expressed as symbols written above or below a note, though some have a more complex written expression, such as those that involve multiple notes and/or include grace notes.

-

These symbols may have different resolutions depending on a large number of factors, such as historical context, national boundaries, composer, scribe, etc. The elements described here, therefore, are not bound to a specific symbol; they are, instead, meant to encode the encoder’s interpretation of a symbol and its position on the staff.

-

Nonetheless, in order to establish common ground, the guidelines suggest commonly accepted symbols and realizations for the ornaments supported by MEI.

-

The following sections will introduce each element in detail for all types of ornaments supported.

-
- Encoding Common To All Ornaments -

When encoding CMN, ornaments should be encoded within a measure, following the staff elements, and connected to events on the staff via attributes. The startid attribute is used to refer to the xml:id of the starting note. Additionally, if the ornament involves more than one events on the staff, the endid attribute can be used to anchor the ornament to a concluding event.

-

The following example demonstrates the encoding of a mordent over a middle C:

-

-

- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="c" xml:id="co_1_n1"/> - </layer> - </staff> - <mordent place="above" staff="1" startid="#co_1_n1"/> -</measure> - -
-

-

Alternatively, the relationship of an ornament to a note can be expressed in terms of beats with the attribute tstamp. If the ornament involves more than one event on the staff, the tstamp2 attribute can be used to indicate the ending time stamp, as is explained in section . These methods may also be utilized simultaneously.

-

The following example shows the use of tstamp for an ornament. Assuming that the following measure is in 2/2, the ornament (in this case, a mordent) is related to the note on the second beat.

-

-

- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="2" oct="4" pname="c"/> - <note dur="2" oct="4" pname="c"/> - </layer> - </staff> - <mordent place="below" staff="1" tstamp="2"/> -</measure> - -
-

-

The relationship between an ornament and the notes on staff must always be encoded. It is, in fact, a semantic error not to specify a starting event or time stamp for an ornament.

-

In their resolution, ornaments will involve auxiliary notes, which typically follow the key signature or the scale of the current key. When the ornament involves other chromatic auxiliaries, an accidental is expressed next to or above the ornament sign. The attributes accidlower and accidupper, available on all ornaments described in this chapter, can be used to record this accidental. The attribute values ‘upper’ and ‘lower’ indicate whether the accidental is associated with an upper or lower auxiliary note, not the position of the accidental sign.

-
- Overriding Default Resolutions -

The symbols and sounded resolutions suggested for each ornament in this chapter are to be considered defaults. Nevertheless, because of the great historical and geographical variance in the notation of ornaments, the encoder is given methods to override the default resolutions.

-

It is possible, for example, to specify in the meiHead a new default sounded resolution for an ornament. As discussed in the section , the element encodingDesc holds a description (optional, but recommended) of the methods and editorial principles which govern the transcription or encoding of the source material. Let us take a trill as an example. The section regarding does not set a specific number of alternations between the principal and secondary notes; the encoder, however, may specify an exact number in the encoding description.

-

-

- - <encodingDesc> - <editorialDecl> - <p>All trills should be resolved by playing three alternations.</p> - </editorialDecl> -</encodingDesc> - -
-

-

Alternatively, resolutions can be defined on a case-by-case basis by encoding a specific resolution using the choice element. See the section below for an example of a specific resolution of a trill.

-
-
-
- Mordents -

A mordent is an ornament that involves an auxiliary note a step above or below the principal note. The presence of a mordent is encoded with the mordent element and its attributes:

-

- - - - - -

-

It is recommended, but not required, to use the attribute form to encode the typology of mordents. Two common types are supported: those mordents that involve a note lower than the principal note, and those that involve a note higher than the principal note.

-

The attribute form accepts the following values:

- - - usually corresponding to the symbol: . This mordent is commonly performed as the principal note, followed by its upper neighbor, with a return to the principal note. - - usually corresponding to the symbol: . This mordent is commonly performed as the principal note, followed by its lower neighbor, with a return to the principal note. - -

The following example demonstrates the encoding of simple mordents:

-

-

- Example of simple mordent - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="4" pname="g" stem.dir="up"/> - <note dur="4" oct="4" pname="b" stem.dir="down"/> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - </layer> - </staff> - <mordent form="upper" staff="1" tstamp="1"/> -</measure> - -
-

-

Occasionally, mordents can be longer, employing five notes instead of three. The long attribute can be used to identify mordents of this type. The following example shows the encoding of a long mordent:

-

-

- Example of a long mordent - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="4" pname="g" stem.dir="up"/> - <note dur="4" oct="4" pname="b" stem.dir="down"/> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - </layer> - </staff> - <mordent form="upper" long="true" staff="1" tstamp="1"/> -</measure> - -
-

-
-
- Trills -

Trills are a type of ornament that consists of a rapid alternation of a note with one a semitone or tone above. A trill is encoded with the trill element and its attributes:

-

- - - - -

-

Trills in modern notation are usually expressed with the abbreviation "tr" above a note on the staff. Often the abbreviation is followed by a wavy line that indicates the length of the trill.

-

The following example demonstrates the encoding of simple trills:

-

-

- Example of simple trills. - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="f" stem.dir="up"/> - <note dur="4" oct="4" pname="a" stem.dir="up"/> - <rest dur="8"/> - <note dur="8" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="5" pname="e" stem.dir="down"/> - </layer> - </staff> - <trill place="above" staff="1" tstamp="1"/> - <trill accidupper="f" place="above" staff="1" tstamp="2"/> - <trill place="above" staff="1" tstamp="3.5"/> - <trill accidupper="s" place="above" staff="1" tstamp="4"/> -</measure> - -
-

-

It has been specified earlier that it is a semantic error not to encode a starting event or time stamp for an ornament. This starting point of a trill can be expressed with the startid attribute and/or with the tstamp attribute. Specifying the end point is not required, although the tstamp2 or endid attribute may be used to imply the use of a wavy line extender as shown in this example:

-

-

- Example of trills followed by wavy lines. - -
-
- - <score> - <scoreDef> - <staffGrp> - <staffDef clef.line="2" clef.shape="G" keysig="2f" lines="5" n="1"/> - </staffGrp> - </scoreDef> - <section> - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="f" xml:id="n1"/> - <note dur="4" oct="5" pname="d" xml:id="n2"/> - <note dur="4" oct="5" pname="d" xml:id="n3"/> - <note dur="4" oct="4" pname="g" xml:id="n4"/> - </layer> - </staff> - <trill place="above" staff="1" startid="#n1" endid="#n2"/> - <trill place="above" staff="1" startid="#n2" endid="#n3"/> - <trill accidupper="n" - place="above" - staff="1" - startid="#n3" - endid="#n4"/> - <trill accidupper="f" - place="above" - staff="1" - startid="#n4" - tstamp2="5"/> - </measure> - </section> -</score> - -
-

-

When giving an end point to trills, the extender attribute should also be added, to indicate the presence or absence of a line extender. Notice, that the note referenced in endid is not part of the trill itself, just like in glissandos.

-

Chromatic alterations of auxiliary notes are occasionally expressed on the staff using small notes enclosed in parentheses, as shown in the example below. However, the attribute accidupper is still to be used to encode the alteration. Display of the auxiliary note in this ‘cautionary’ manner is left to down-stream rendering processes.

-

-

- Example alterations expressed on the staff. - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="2" oct="4" pname="g" stem.dir="up"/> - </layer> - </staff> - <trill accidupper="f" place="above" staff="1" tstamp="1"/> -</measure> - -
-

-

Some trills may be introduced by a turn or followed by an inverted turn leading to the next note (see Le garzantine, Musica 2003, p. 911). In such cases, the trill is encoded as in previous examples and associated with the principal note. Starting or concluding turns are notated on the staff (in layer) as .

-

The following example, from a keyboard sonata by Joseph Haydn, shows a trill with concluding grace notes (called Nachschlag):

-

-

- Haydn, Sonata in D major, Hoboken XVI:33 (Wiener Urtex no. 34), mvmt. 1. - -
-
- - <measure n="2"> - <staff n="1"> - <layer n="1"> - <note accid.ges="s" - dur="32" - grace="acc" - oct="6" - pname="c" - stem.dir="up"/> - <note dur="2" oct="5" pname="b" stem.dir="down"/> - <graceGrp attach="pre" grace="unacc"> - <beam> - <note dur="32" oct="5" pname="a" stem.dir="up"/> - <note dur="32" oct="5" pname="b" stem.dir="up"/> - </beam> - </graceGrp> - </layer> - </staff> - <trill place="above" staff="1" tstamp="1" tstamp2="3" vo="6.5"/> -</measure> - -
-

-
- Special Cases -

Symbols and abbreviations for trills have changed and evolved considerably throughout history. Strategies to clarify the encoding and interpretation of ornaments have been discussed in section above. However, in order to aid the encoder in making educated choices in the encoding of non-standard trills, this section shows two examples diverging from modern standard use.

-

The abbreviation "tr" followed by a wavy line spanning multiple notes is sometimes used to indicate multiple trills:

-

-

- Example of multiple trills. - -
-

-

The encoding of this kind of trill may vary depending on the purpose of the encoding. For representation of the source, a single trill is sufficient:

-

-

- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="f" stem.dir="up"/> - <note dur="4" oct="4" pname="a" stem.dir="up"/> - <rest dur="8"/> - <note dur="8" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="5" pname="e" stem.dir="down"/> - </layer> - </staff> - <trill place="above" staff="1" tstamp="1" tstamp2="0m+4"/> -</measure> - -
-

-

To support analytical and aural rendering applications, however, each trill may be explicitly encoded, as the following example demonstrates:

-

-

- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="f" stem.dir="up"/> - <note dur="4" oct="4" pname="a" stem.dir="up"/> - <rest dur="8"/> - <note dur="8" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="5" pname="e" stem.dir="down"/> - </layer> - </staff> - <trill place="above" staff="1" tstamp="1"/> - <trill accidupper="f" place="above" staff="1" tstamp="2"/> - <trill place="above" staff="1" tstamp="3.5"/> - <trill accidupper="s" place="above" staff="1" tstamp="4"/> -</measure> - -
-

-

However, when it is necessary to support multiple outputs, use of the choice element and appropriate sub-elements is recommended. In this case, the orig and reg elements can be used to represent the original source and a regularization provided by the editor, respectively:

-

-

- - <choice> - <orig> - <trill place="above" staff="1" tstamp="1" tstamp2="0m+4"/> - </orig> - <reg> - <trill place="above" staff="1" tstamp="1"/> - <trill accidupper="f" place="above" staff="1" tstamp="2"/> - <trill place="above" staff="1" tstamp="3.5"/> - <trill accidupper="s" place="above" staff="1" tstamp="4"/> - </reg> -</choice> - -
-

-

Another situation that requires disambiguation of an ornament’s name and its potential rendition is due to the fact that the symbols for trills and mordents have been often used interchangeably in the past. The following example, taken from - Klavierbüchlein für Wilhelm Friedemann Bach - (1720), shows a trill (Trillo) identified by the symbol associated with a mordent in modern practice. Nonetheless, J.S. Bach’s suggested resolution should be encoded with a variant of the procedure presented above.

-

In the example below, the child elements of choice; that is, orig and reg, represent non-exclusive options; that is, both may be processed by applications that aim to support both visual and aural renditions.

-

-

- Trill transcribed from J. S. Bach’s Klavierbüchlein für Wilhelm Friedemann Bach - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - </layer> - </staff> - <choice> - <orig> - <trill place="above" staff="1" tstamp="1"/> - </orig> - <reg> - <note dur="32" oct="5" pname="d"/> - <note dur="32" oct="5" pname="c"/> - <note dur="32" oct="5" pname="d"/> - <note dur="32" oct="5" pname="c"/> - <note dur="32" oct="5" pname="d"/> - <note dots="1" dur="16" oct="5" pname="c"/> - </reg> - </choice> -</measure> - -
-

-

Depending on the purpose of the encoding, it may be more convenient to encode the regularized text within the stream of events, along with a corresponding choice with regard to the existence of the trill marking, as in the following example:

-

-

- - <measure> - <staff> - <layer> - <choice> - <orig> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - </orig> - <reg> - <note dur="32" oct="5" pname="d"/> - <note dur="32" oct="5" pname="c"/> - <note dur="32" oct="5" pname="d"/> - <note dur="32" oct="5" pname="c"/> - <note dur="32" oct="5" pname="d"/> - <note dots="1" dur="16" oct="5" pname="c"/> - </reg> - </choice> - </layer> - </staff> - <choice> - <orig> - <trill place="above" staff="1" tstamp="1"/> - </orig> - <reg> - </reg> - </choice> -</measure> - -
-

-

The orig element contains the single-note-with-trill transcription of the original text, while the reg element represents the realization-without-trill version.

-

This approach facilitates substitution of the realization of the trill for the original written note (as well as the opposite procedure) and is therefore the recommended markup for applications where exchange of this kind is desirable.

-
-
-
- Turns -

A turn is an ornament that typically consists of four notes: the upper neighbor of the principal note, the principal note, the lower neighbor, and the principal note again.

-

The presence of a turn is encoded with the turn element and its attributes:

-

- - - - -

-

It is recommended, but not required, to use the attribute form to encode the typology of the turn.

-

The attribute form accepts the following values:

- - - usually corresponding to the symbol: . This turn is commonly performed beginning on a note higher than the principal note. - - usually corresponding to the symbol: . This turn is commonly performed beginning on a note lower than the principal note. - -

The following example shows the encoding of a simple turn:

-

-

- Example of a simple turn. - -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - <note dur="4" oct="5" pname="d" stem.dir="down"/> - <note dur="4" oct="5" pname="e" stem.dir="down"/> - <note dur="4" oct="5" pname="c" stem.dir="down"/> - </layer> - </staff> - <turn form="upper" staff="1" tstamp="1"/> -</measure> - -
-

-

Turns can sometimes be performed after the principal note (usually on the second half of the beat, see Read 1979, p. 246) and leading to the following event. To indicate this, the turn symbol is typically written in between the principal note and the next. These kind of turns are encoded with the attribute delayed.

-

The following example from Beethoven’s piano sonata no. 1 in F minor, op. 2, no. 1, mvmt. 2 demonstrates the encoding of turns with the delayed attribute. Note that the tstamp attribute indicates the actual starting point in time, while startid points to the principal note.

-

-

- Delayed turn. - -
-
- - <measure> - <staff n="1"> - <layer n="1"> - <note dots="1" - dur="4" - oct="5" - pname="g" - stem.dir="down" - tie="i"/> - <beam> - <note dots="1" - dur="16" - oct="5" - pname="g" - stem.dir="down" - tie="t"/> - <note dur="32" oct="5" pname="a" stem.dir="down"/> - </beam> - </layer> - </staff> - <turn accidlower="s" - delayed="true" - place="above" - staff="1" - tstamp="2.75"/> -</measure> - -
-

-
-
- Other Ornaments -

CMN ornaments that are not mordents, trills, or turns can be encoded with a generic ornam.

-

This element allows the encoder to represent ornaments as textual strings (e.g., with a Unicode symbol) or with a user defined symbol. Chromatic auxiliaries can be represented with accidlower and accidupper. The ornam element can also be a control element. That is, it can be linked via its attributes to other events. The starting point of the directive may be indicated by either a tstamp, tstamp.ges, tstamp.real or startid attribute, while the ending point may be recorded by either a tstamp2, dur, dur.ges or endid attribute. It is a semantic error not to specify a starting point attribute.

-

For example, Johann Sebastian Bach used non-standard ornaments in the Klavierbüchlein für Wilhelm Friedemann Bach:

-

-

- Table of ornaments used by Johann Sebastian Bach in the Klavierbüchlein für Wilhelm Friedemann Bach - -
-

-

The ornament for (5) doppelt-cadence could be encoded in the following way, by adopting the Unicode code-points defined by the SMuFL standard:

-

-

- - <ornam tstamp="1"> - <symbol glyph.auth="smufl" - glyph.num="#xE5C0" - glyph.name="ornamentPrecompDoubleCadenceLowerPrefix"/> -</ornam> - -
-

-

A resolution, or expansion of the ornament can be provided as discussed in below.

-
-
- Ornaments in Combinations -

Particularly in baroque keyboard music, but also in the early classical period, various combinations of ornaments can be found. Despite being written vertically above the same note, they are to be performed in sequence.

-

The following example from Carl Philipp Emanuel Bach’s song Dorinde Wq 199/7 shows a turn followed by a inverted mordent:

-

-

- Combined ornaments in C.P.E. Bach’s song Dorinde - -
-

-

When encoding the example above, both ornaments will be positioned above the same note. The encoded order of the elements, moreover, may correspond to the performed sequence, which in this example is top to bottom: first the turn, then the mordent. As every renderer deals differently with such combined ornaments it is best practice to encode the performed sequence additionally with next and prev attributes. The visual order can be specified globally with aboveorder in the preceding scoreDef.

-

-

- - <measure n="3"> - <staff n="1"> - <layer n="1"> - <note dur="8" grace="unknown" oct="5" pname="f" stem.dir="up"/> - <note dur="4" oct="5" pname="e" stem.dir="down" xml:id="ex_m3_n1"/> - <beam> - <note dur="16" oct="5" pname="d" stem.dir="up"/> - <note accid="s" dur="16" oct="4" pname="f" stem.dir="up"/> - <note dur="16" oct="4" pname="g" stem.dir="up"/> - <note dur="16" oct="5" pname="e" stem.dir="up"/> - </beam> - <note dur="8" grace="unknown" oct="5" pname="d" stem.dir="up"/> - <note dur="4" oct="5" pname="c" stem.dir="down" xml:id="ex_m3_n2"/> - </layer> - </staff> - <mordent xml:id="or_1" - form="upper" - staff="1" - startid="#co_1_m_n1" - prev="#or_2"/> - <turn xml:id="or_2" - form="upper" - staff="1" - startid="#co_m_1_n1" - next="#or_1"/> - <mordent xml:id="or_3" - form="upper" - staff="1" - startid="#co_m_1_n2" - prev="#or_4"/> - <turn xml:id="or_4" - form="upper" - staff="1" - startid="#co_m_1_n2" - next="#or_3"/> -</measure> - -
-

-
-
-
-
- Repertoire: Mensural Notation -

This chapter describes the module for encoding mensural notation from the late 13th century to about 1600. Historically, mensural notation preceded the development of Common Music Notation (CMN) and it included a wide range of features that persist in CMN and that can be encoded in a standard manner in MEI. In mensural notation, pitches are notated as in CMN, leaving out here the major exception of musica ficta. The pitch is given by the position of the note on the staff and the current clef as in CMN, and the mensural module introduces no modification to MEI regarding how pitches are encoded.

-

There are a number of differences, however, in the representation of duration in mensural notation. The mensural module introduces specific attribute values for notes and rests for appropriately encoding mensural durations. One of the main differences is that the duration of a note is not determined by its symbol, but also by the meter and the context in which the symbol appears in relation to other notes and rests in the same voice. The meter is given by one of the 16 mensural species provided by four levels of division: modus major, modus minor, tempus and prolatio. In the case of triple meter and depending on the specific context where the note is positioned, certain rules must be applied in order to determine the duration of a note. In these cases, encoding both the sign and its actual duration is highly recommended (as will be shown in ).

-

Another difference is the use of proportions that are indicated by numeric ratios or by specific mensuration signs. The proportions indicate that the durations have to be modified and they may be combined. Proportions and mensuration signs were eventually simplified and became time signatures in CMN. The attributes and elements available in this module for encoding mensural signs and proportions can be found below (see and ).

-

In mensural notation, notes can also be notated in ligatures that regroup two or more notes. Ligatures were a legacy from an earlier notation system that were still widely used in Renaissance music notation. They gradually disappeared during the seventeenth century. The mensural module provides multiple ways of encoding the ligatures.

-
- Durations -

When the mensural module is included, dur on note, rest, and other elements takes the following values (from the Latin names of notes):

- - - Two or three times as long as a longa - - Two or three times as long as a brevis - - Two or three times as long as a semibrevis - - Half or one-third as long as a brevis - - Half or one-third as long as a semibrevis - - Half as long as a minima - - Half as long as a semiminima - - Half as long as a fusa - -

-

- The upper staff shows the different mensural note shapes and the lower staff shows the different mensural rests - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Notes and Rests</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The upper staff shows the different mensural note shapes and the lower staff shows - the different mensural rests.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="notes" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" /> - <staffDef label="rests" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" /> - </staffGrp> - </scoreDef> - <section> - <?edit-start?> - <staff n="1"> - <layer n="1"> - <note dur="maxima" /> - <note dur="longa" /> - <note dur="brevis" /> - <note dur="semibrevis" /> - <note dur="minima" /> - <note dur="semiminima" /> - <note dur="fusa" /> - <note dur="semifusa" /> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <rest dur="maxima" /> - <rest dur="longa" /> - <rest dur="brevis" /> - <rest dur="semibrevis" /> - <rest dur="minima" /> - <rest dur="semiminima" /> - <rest dur="fusa" /> - <rest dur="semifusa" /> - </layer> - </staff> - <?edit-end?> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

Normally, longa rests are vertical strokes occupying two or three spaces in the staff, depending on the mensuration. For instance, in modusminor="3", they take up three spaces; and in modusminor="2", they take two. However, there are situations where both types of longa rests can be present in the same piece, regardless of the modus minor. For this reason, the dur attribute can take on two other values when used within rest elements:

- - - Two-breve rest - - Three-breve rest - -

The example below illustrates this case in a passage in perfect modus from the triplum voice of a motet in the Roman de Fauvel music manuscript. The blue arrows on the image are pointing to the two-breve and three-breve rests in this passage.

-

-

- Inflammatis invidia / Sicut de ligno / Victimae paschali detail from F-Pn 146, fol. 22r (https://gallica.bnf.fr/ark:/12148/btv1b8454675g/f55.image). - -
-

-

-

- Encoding of Inflammatis invidia / Sicut de ligno / Victimae paschali detail from F-Pn 146, fol. 22r (https://gallica.bnf.fr/ark:/12148/btv1b8454675g/f55.image) - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 --> -<layer n="1"> - <!-- First system in the image --> - <!-- ... --> - <rest dur="2B"/> - <ligature> - <note dur="semibrevis" oct="4" pname="d"/> - <note dur="semibrevis" oct="4" pname="c"/> - </ligature> - <ligature> - <note dur="semibrevis" oct="4" pname="d"/> - <note dur="semibrevis" oct="4" pname="e"/> - </ligature> - <ligature> - <note dur="semibrevis" oct="4" pname="d"/> - <note dur="semibrevis" oct="3" pname="a"/> - </ligature> - <note dur="longa" oct="3" pname="b"/> - <dot form="div"/> - <ligature> - <note dur="semibrevis" oct="4" pname="c"/> - <note dur="semibrevis" oct="4" pname="d"/> - </ligature> - <ligature> - <note dur="semibrevis" oct="4" pname="c"/> - <note dur="semibrevis" oct="3" pname="b"/> - </ligature> - <ligature> - <note dur="semibrevis" oct="3" pname="a"/> - <note dur="semibrevis" oct="3" pname="g"/> - </ligature> - <note dur="longa" oct="3" pname="a"/> - <note dur="semibrevis" oct="4" pname="d"/> - <note dur="semibrevis" oct="4" pname="e"/> - <!-- Next system in the image --> - <note dur="longa" oct="4" pname="f"/> - <note dur="brevis" oct="4" pname="e"/> - <dot form="div"/> - <note dur="brevis" oct="4" pname="d"/> - <ligature> - <note dur="semibrevis" oct="4" pname="c"/> - <note dur="semibrevis" oct="3" pname="b"/> - </ligature> - <ligature> - <note dur="semibrevis" oct="4" pname="c"/> - <note dur="semibrevis" oct="4" pname="d"/> - </ligature> - <note dur="longa" oct="4" pname="e"/> - <rest dur="3B"/> - <!-- ... --> -</layer> - -
-

-
- Alteration and Imperfection -

In ternary mensurations, the ambiguity between the note shape and its actual duration requires specific attention. The rules of mensural notation can require the alteration or the imperfection of a note; that is, an increase or reduction in its performed duration. In these cases, if the encoding is intended to be used for more than just graphically representing the notation, encoding only the note shape by means of the dur attribute alone is insufficient. In that case, in addition to encoding the duration sign in the dur attribute, it is recommended to encode its performed duration in the dur.quality attribute. The dur.quality attribute specifies the length of a note according to the contextual rules of mensural notation. Its values, listed below, are adopted from the original Latin terms:

- - - Three times the duration of the note in the next smaller degree - - Two times the duration of the note in the next smaller degree - - Twice the original duration of the note (only usable in perfect mensurations) - - Category of a regular semibrevis in Ars antiqua, equivalent to a third of a brevis - - Category of an altered semibrevis in Ars antiqua, equivalent to two minor semibrevis - - One of the three categories of a longa in Ars antiqua ('duplex', 'perfecta', and 'imperfecta') - -

The last three values are to be used exclusively in Ars antiqua mensural notation, where maior and minor refer to types of semibreves, and duplex refers to a type of longa. Examples of each of these six values are presented below. In these examples, the ‘voice’ staff renders the notes in the code snippet, and the ‘reference’ staff, together with the dotted bar lines, are shown to help to visualize the relative values of the notes in the ‘voice’ staff.

-

The following example illustrates an alteration (the second brevis) in modus minor perfectus. Notice that the second brevis has doubled its regular value, it has been altered, unlike the first one.

- Example of alteration (The bottom staff, together with the dotted barlines, is used here to help visualizing the durational values of the notes in the upper staff) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of 'alteration'</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help - visualizing the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 --> - <layer n="1"> - <note dur="longa" dur.quality="perfecta" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" dur.quality="altera" /> - <barLine form="dashed" /> - <note dur="longa" dur.quality="perfecta" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

It is possible to omit the dur.quality attribute in a note when the performed duration of the note is the default value provided by the mensuration. In this case, the longas are perfect, just as the mensuration (perfect modus minor) indicates. Therefore, the dur.quality attribute can be omitted for the two longas.

- Example omitting dur.quality for default values provided by the mensuration - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 --> -<layer> - <note dur="longa"/> - <note dur="brevis"/> - <note dur="brevis" dur.quality="altera"/> - <note dur="longa"/> -</layer> - -
The same applies to the examples that follow.

-

The following example illustrates an imperfection (the two longae) in modus minor perfectus with the same longa-brevis-brevis-longa sequence but with an additional dot of division between the two breves (see for more details). Notice that here the longae have been imperfected, unlike the previous example in which they kept the perfect value indicated by the mensuration.

- Example of imperfection (The bottom staff, together with the dotted barlines, is used here to help visualizing the durational values of the notes in the upper staff) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of 'imperfection' and 'dot of division'</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help visualizing - the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 --> - <layer n="1"> - <note dur="longa" dur.quality="imperfecta" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <dot form="div" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="longa" dur.quality="imperfecta" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

The following example in modus minor imperfectus illustrates the use of a dot of augmentation following the longa (see for more details). Notice that the longa, which is supposed to be imperfect according to the mensuration, has a perfect value due to the augmentation dot.

- Example of augmentation (The bottom staff, together with the dotted barlines, is used here to help visualizing the durational values of the notes in the upper staff) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of 'augmentation'</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help visualizing - the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="2" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="2" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 2 and @tempus = 2 --> - <layer n="1"> - <note dur="longa" dur.quality="perfecta" /> - <dot form="aug" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="brevis" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

Finally, the following example illustrates the dur.quality values related to the Ars antiqua style, for perfect modus, with the breve equivalents notated in the lower staff for reference (as in the previous examples).

- Example of ars antiqua related values for perfect modus (The bottom staff, together with the dotted barlines, is used here to help visualizing the durational values of the notes in the upper staff) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of 'imperfection' and 'dot of division'</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help visualizing - the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.black" lines="5" clef.shape="G" clef.line="2" modusminor="3" tempus="3" /> - <staffDef label="reference" n="2" notationtype="mensural.black" lines="5" clef.shape="G" clef.line="2" modusminor="3" tempus="3" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 and @tempus = 3 --> - <layer n="1"> - <note dur="longa" dur.quality="perfecta" /> - <barLine form="dashed" /> - <note dur="semibrevis" dur.quality="minor" /> - <note dur="semibrevis" dur.quality="minor" /> - <note dur="semibrevis" dur.quality="minor" /> - <dot form="div" /> - <barLine form="dashed" /> - <note dur="semibrevis" dur.quality="minor" /> - <note dur="semibrevis" dur.quality="maior" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="longa" dur.quality="duplex" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="brevis" /> - <note dur="brevis" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <note dur="brevis" /> - <note dur="brevis" /> - <barLine form="dashed" /> - <note dur="brevis" /> - <note dur="brevis" /> - <note dur="brevis" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

- Note: In Ars Antiqua, only the longa could be "perfecta" / "imperfecta" and the brevis could have a regular value ("recta") or be "altera". In the Ars nova, principles of imperfection and alteration were extended into the other note levels (brevis-semibrevis and semibrevis-minima). This means that the breves in Ars antiqua do not have a "perfecta" / "imperfecta" quality, and this is why there is no dur.quality attribute for the breves in the previous example. However, the brevis can have a ternary division (indicated by tempus="3"), being divided either into three (equal) minor semibreves or into a minor-maior pair of semibreves. The encoding also allows for the possibility of encoding a binary division of the breve in Ars antiqua notations: the indication tempus="2" indicates the breve is divided into two equal semibreves. This is why in this example with tempus="3", the semibreves do have a dur.quality attribute (with values minor or maior).

-

An alternative encoding---removing the dur.quality attributes for notes which lengths are not modified from their default values (i.e., the perfect long and the minor semibreves)---would be:

- Encoding of the ars antiqua related values for perfect modus (see example above) - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3 and @tempus = 3 --> -<layer> - <note dur="longa"/> - <note dur="semibrevis"/> - <note dur="semibrevis"/> - <note dur="semibrevis"/> - <dot form="div"/> - <note dur="semibrevis"/> - <note dur="semibrevis" dur.quality="maior"/> - <note dur="brevis"/> - <note dur="longa" dur.quality="duplex"/> -</layer> - -
-

-

The conjunct use of the dur and dur.quality attributes is generally enough to encode the duration of a note—and, as indicated before, one could even remove dur.quality when its value is in agreement with the mensuration. However, there are cases (e.g., partial imperfection) where the values of dur.quality are not enough to provide the note’s duration.

-
-
- Partial Imperfection -

In opposition to regular imperfection, which is caused by a note of the next smaller degree (e.g., a perfect brevis imperfected by a following/preceding semibrevis), partial imperfection is caused by a note of two or even three orders apart. As an example, consider an imperfect longa made up of two perfect breves. This longa can be ‘partially imperfected’ by a following/preceding semibrevis. This semibrevis causes part of the longa—one of its perfect breves—to be imperfected, taking away one-third of one of its two halves. In this case, the longa’s value changes from 6 semibreves (two perfect breves) into 5 semibreves. Partial imperfection is not supported by the dur.quality attribute—because there can be many cases of partial imperfection, as will be seen in the following examples. To encode a partial imperfection, the num and numbase pair of attributes are used instead. Given the change in the longa’s value from 6 semibreves to 5 semibreves, the corresponding attributes to encode this particular case of partial imperfection would be num="6" and numbase="5" as shown below in the code snippet and its rendering.

-

-

- Example of "partial imperfection of an immediate part" (ad partem propinquam) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of "partial imperfection of an immediate part" (ad partem propinquam)</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help visualizing - the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="3" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="3" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 2 and @tempus = 3 --> - <layer n="1"> - <note dur="longa" num="6" numbase="5" /> - <barLine form="dotted" /> - <note dur="semibrevis" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

Partial imperfection can also happen from both sides of a note at once, as shown below:

-

-

- Example of "partial imperfection" from both sides (ad partes) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of "partial imperfection" from both sides (ad partes)</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help visualizing - the durational values of the notes in the upper staff.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="3" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" tempus="3" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 2 and @tempus = 3 --> - <layer n="1"> - <note dur="semibrevis" /> - <barLine form="dotted" /> - <note dur="longa" num="6" numbase="4" /> - <barLine form="dotted" /> - <note dur="semibrevis" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <note dur="semibrevis" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

An example of partial imperfection caused by a note three orders apart is given next. Here the longa is partially imperfected by a minima (instead of by a semibrevis).

-

-

- Example of "partial imperfection of a remote part" (ad partem remotam) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of "partial imperfection of a remote part" (ad partem remotam)</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted and dashed barlines, is used here to help - visualizing the durational values of the notes in the upper staff. Dotted barlines in the - bottom staff show the minim groups equivalent to a semibreve, and the dashed barlines show - the groups of semibreves equivalent to a breve.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" prolatio="3" tempus="2" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="2" prolatio="3" tempus="2" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 2, @tempus = 2, and @prolatio = 3 --> - <layer n="1"> - <note dur="longa" num="12" numbase="11" /> - <barLine form="dotted" /> - <note dur="minima" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dotted" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dotted" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-

In the next example, the longa is also imperfected by a minima. However, the num and numbase ratio is different from the example above because the default value of the longa here (18 minimas) is different from that of the previous example (12 minimas).

-

-

- Example of "partial imperfection of a remote part" (ad partem remotam) - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of "partial imperfection of a remote part" (ad partem remotam)</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>The bottom staff, together with the dotted barlines, is used here to help - visualizing the durational values of the notes in the upper staff. Dotted - barlines in the bottom staff show the minim groups equivalent to a semibreve, - and the dashed barlines show the groups of semibreves equivalent to a breve.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score> - <scoreDef> - <staffGrp> - <staffDef label="voice" n="1" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" prolatio="3" tempus="2" /> - <staffDef label="reference" n="2" notationtype="mensural.white" lines="5" clef.shape="G" clef.line="2" modusminor="3" prolatio="3" tempus="2" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <?edit-start?> - <!-- mensuration encoded in <staffDef> element indicates @modusminor = 3, @tempus = 2, and @prolatio = 3 --> - <layer n="1"> - <note dur="longa" num="18" numbase="17" /> - <barLine form="dotted" /> - <note dur="minima" /> - <barLine form="dashed" /> - </layer> - <?edit-end?> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dotted" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dotted" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dashed" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dotted" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <note dur="minima" oct="4" pname="a" /> - <barLine form="dashed" /> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-

-
-
-
- Mensuration -

Using the mensural module, mensuration signs can be indicated with the attributes available on the scoreDef and staffDef elements. Mensuration signs encoded using attributes on scoreDef are regarded as default values which may be overridden by values attached to individual staffDef elements.

-

The division levels corresponding to modus maior, modus minor, tempus, and prolatio can be encoded in the modusmaior, modusminor, tempus, and prolatio attributes respectively. Their value must be 3 (perfect) or 2 (imperfect).

-

- - - -

-

The mensur signs themselves can be encoded in the mensur.sign attribute with a possible value of C or O. Its orientation can be encoded in the mensur.orient attribute, for example, with the value reversed for a flipped C sign. The number of slashes (up to 6) can be given in the mensur.slash attribute. There is also a mensur.dot attribute for indicating the presence of a dot through the boolean values true or "false".

-

- - - -

-

- mensur elements can also be used instead of staffDef and its attributes. In mensur, the division levels are encoded with the previously mentioned modusmaior, modusminor, tempus, and prolatio attributes, while the attributes to indicate the mensur signs are: sign, orient, slash, and dot. mensur can be a child of the staffDef and layer elements.

-

- - - -

-

- - - -

-

- - - - -

-
- Change in mensuration -

The following example illustrates a change in mensuration. In this case, the element mensur is used within the layer element, preceding the stream of notes affected by the new mensuration defined by it.

- Example of a change in mensuration - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of 'mensuration changes'</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <?edit-start?> - <score> - <scoreDef> - <staffGrp> - <staffDef n="1" notationtype="mensural" lines="5" clef.shape="G" clef.line="2" mensur.color="red" mensur.dot="true" mensur.sign="O" mensur.slash="1" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <layer n="1"> - <note /> - <note /> - <note /> - <mensur sign="C" loc="3" /> - <note /> - <note /> - <note /> - </layer> - </staff> - </section> - </score> - <?edit-end?> - </mdiv> - </body> - </music> -</mei> -
-

-

Sesquialtera is frequently used to change the mensuration. The effect of the sesquialtera on the mensuration can be encoded by using the tempus and prolatio attributes of mensur (for example, when changing the tempus to perfect, the effect can be encoded in tempus="3"). The actual sesquialtera can be encoded using num="3", numbase="2", and level to define the note level the sesquialtera is applied to (e.g., level="semibrevis").

-
-
- Implicit mensuration -

It is common in Ars antiqua and some Ars nova pieces to have no mensuration signs. In this case, the mensuration—the division levels corresponding to modus maior, modus minor, tempus, and prolatio—is given by the context. The next example shows the incipit of a four-voice piece, Josquin’s Tu solus qui facis mirabilia, where only two of the voices (Cantus and Tenor) have a mensuration sign. The other two (Altus and Bassus) have no mensuration signs, and the mensura is given by the context. Therefore, while only the Cantus and the Tenor have attributes for encoding the mensuration sign (in this case, mensur.sign and mensur.slash), all four voices include attributes to encode the mensura (tempus and prolatio).

- Example of omitted mensuration signs - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of omitted mensuration signs</title> - </titleStmt> - <pubStmt> - <date isodate="2023">2023</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI) Board</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>In this choir book, only the verso parts have a mensuration sign, whereas Altus and - Bassus on the recto don't.</annot> - </notesStmt> - <sourceDesc> - <source> - <bibl>FlorPanc27, 79v-80r</bibl> - </source> - </sourceDesc> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <?edit-start?> - <score> - <scoreDef keysig="1f"> - <staffGrp> - <staffDef n="1" label="Cantus" lines="5" notationtype="mensural.white" clef.shape="C" - clef.line="1" mensur.sign="C" mensur.slash="1" prolatio="2" tempus="2" /> - <staffDef n="2" label="Tenor" lines="5" notationtype="mensural.white" clef.shape="C" - clef.line="4" mensur.sign="C" mensur.slash="1" prolatio="2" tempus="2" /> - <staffDef n="3" label="Altus" lines="5" notationtype="mensural.white" clef.shape="C" - clef.line="3" prolatio="2" tempus="2" /> - <staffDef n="4" label="Bassus" lines="5" notationtype="mensural.white" clef.shape="F" - clef.line="4" prolatio="2" tempus="2" /> - </staffGrp> - </scoreDef> - <section> - <staff n="1"> - <layer n="1"> - <note pname="b" oct="4" dur="brevis" /> - <note pname="b" oct="4" dur="brevis" /> - <note pname="a" oct="4" dur="brevis" /> - <note pname="g" oct="4" dur="brevis" /> - <note pname="g" oct="4" dur="semibrevis" /> - <note pname="g" oct="4" dur="semibrevis" /> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <note pname="g" oct="3" dur="brevis" /> - <note pname="b" oct="3" dur="brevis" /> - <note pname="c" oct="4" dur="brevis" /> - <note pname="c" oct="4" dur="brevis" /> - <note pname="c" oct="4" dur="semibrevis" /> - <note pname="c" oct="4" dur="semibrevis" /> - </layer> - </staff> - <staff n="3"> - <layer n="1"> - <note pname="d" oct="4" dur="brevis" /> - <note pname="d" oct="4" dur="brevis" /> - <note pname="f" oct="4" dur="brevis" /> - <note pname="e" oct="4" dur="brevis" /> - <note pname="e" oct="4" dur="semibrevis" /> - <note pname="e" oct="4" dur="semibrevis" /> - </layer> - </staff> - <staff n="4"> - <layer n="1"> - <note pname="g" oct="2" dur="brevis" /> - <note pname="g" oct="3" dur="brevis" /> - <note pname="g" oct="3" dur="brevis" /> - <note pname="c" oct="3" dur="brevis" /> - <note pname="c" oct="3" dur="semibrevis" /> - <note pname="c" oct="3" dur="semibrevis" /> - </layer> - </staff> - </section> - </score> - <?edit-end?> - </mdiv> - </body> - </music> -</mei> -
-

-
-
- Italian Divisiones -

The division of the breve in Italian trecento notation can be encoded using the divisio attribute, which provides the values: ternaria, quaternaria, senariaimperf, senariaperf, octonaria, novenaria, duodenaria. The divisio attribute would usually replace the use of the tempus and prolatio set of attributes.

-

- - - -

-

The signs for the Italian divisiones can be encoded in the sign or mensur.sign attribute (to be used with mensur or staffDef respectively), with the values: t for ternaria, q for quaternaria, si and i for senaria imperfecta, sp and p for senaria perfecta, oc for octonaria, n for novenaria, and d for duodenaria. And the additional values for senaria gallica, sg and g, and senaria ytalica, sy and y.

-
-
-
- Proportions -

Proportions can also be indicated within the staffDef element. The proport.num and proport.numbase attributes are available for encoding the numerator and the denominator of the proportion, respectively. There is also a proport element that can be used as an alternative, with the corresponding num and numbase attributes.

-

- - - -

-
-
- Ligatures -

Ligatures can be encoded using the ligature element. The form attribute is available for specifying if the ligature is recta or obliqua.

-

-

- Recta and obliqua ligatures - -
-
- Encoding of recta and obliqua ligatures - <layer> - <ligature form="recta"> - <note dur="semibrevis" oct="4" pname="d"/> - <note dur="semibrevis" oct="3" pname="g"/> - </ligature> - <ligature form="obliqua"> - <note dur="semibrevis" oct="3" pname="g"/> - <note dur="semibrevis" oct="4" pname="c"/> - </ligature> -</layer> - -
-

-

In cases where the ligature contains both recta and obliqua notes, the lig attribute of the note element can be used to specify the form of the ligature at the note level.

-

-

- Ligature with more than two notes with recta and obliqua - -
-
- Encoding of that ligature with more than two notes with recta and obliqua - <ligature form="recta"> - <note dur="longa" oct="3" pname="a"/> - <note dur="longa" oct="4" pname="e"/> - <note dur="semibrevis" lig="obliqua" oct="4" pname="d"/> - <note dur="semibrevis" lig="obliqua" oct="4" pname="c"/> - <note dur="brevis" oct="3" pname="b"/> - <note dur="brevis" oct="4" pname="e"/> -</ligature> - -
-

-
-
- Music Data Organization -

The data organization based on measure elements that usually prevails in MEI is not appropriate for mensural notation because most music until 1600 does not have measures (bars) as we understand them today. Even though it is not defined by the mensural module, a more suitable alternate data organization without measures is available: staff elements may occur directly within the section element without being organized into measures first. The organization of events (notes, rests, etc.) within the staff and layer elements remains unchanged.

-

-

- Example of an encoding without measure - <section> - <staff n="1"> - <layer> - <note dur="longa" oct="5" pname="c"/> - <note dur="brevis" oct="4" pname="g"/> - <note dur="brevis" oct="4" pname="e"/> - </layer> - </staff> - <staff n="2"> - <layer> - <note dur="maxima" oct="3" pname="c"/> - </layer> - </staff> -</section> - -
-

-

This feature may also be used to encode measured music without using the measure element. That is, the same data organization described above may be used, but with the addition of bar lines, indicated by the barLine element, for those situations where a measure-by-measure organization is not appropriate, for example, when measures are not coincident in all the staves of a score.

-
-
- Other Features -

Other features included in the MEI schema that allow for the encoding of various mensural notation properties are presented below:

-
- Notation Type -

The notationtype attribute, part of the MEI module, can be used within the staffDef element to specify which dialect of mensural notation is in use.

-

- - - -

-

At the moment, three values are in use for mensural notation:

- - - For mensural notation in general - - For black mensural notation, this is in reference to the use of filled-in note heads - - For white mensural notation, this is in reference to the use of void note heads, which became most widely used in the Renaissance period - -

The values of the notationtype attribute can indicate notation types other than mensural, such as common (Western) music notation, neume notation, and tablature.

-

The attribute notationsubtype can be used, together with the notationtype attribute, to provide more specificity regarding the type of notation encoded. This attribute can be used, for example, to specify if a piece in black mensural notation (notationtype="mensural.black") is written in Ars antiqua or Ars nova style. Currently, the values allowed in the notationsubtype attribute consist of any sequence of characters provided by the user.

-

- - - -

-

- Important: An element with a notationsubtype attribute must have a notationtype attribute.

-
-
- Stems -

The characteristics of a note’s stem can be encoded within the note element, using the attributes:

-

- - - - -

-

[include example (image and code) of a note with one stem that includes many of these attributes]

-

Sometimes notes have two stems. In this case, the stem element can be used as a child of note to define the individual characteristics of each stem with the following attributes:

-

- - - -

-

- - - - -

-

[include example (image and code) of a note with two stems]

-
-
- Plicas -

Plicas can be encoded using the plica element as a child of note. The direction of the plica, as well as its length, can be encoded using the following visual-domain attributes:

-

- - - -

-

- - - -

-
- Encoding and rendering of plicas - -
-
-
- Dots -

Dots of division and augmentation can be encoded by using the dot element (provided by the MEI.shared module). This element is meant to be used as a child of layer following the note or rest after which it appears in the original source.

-

Dots in mensural notation are not encoded as children of notes or rests, but rather as a sibling of these. They are also not encoded as attributes (the use of the dot attribute in a note or rest element is only acceptable in Common Music Notation, not mensural).

-

To indicate the nature of the dot (as a dot of division or augmentation), the dot element has an attribute form, which can take on the following values:

- - - Value of the form attribute for a dot of augmentation (this is a dot that adds half the value to the previous note, like a dotted note in common Western music notation) - - Value of the form attribute for a dot of division (this is a dot that modifies the perfect groupings of the notes, thus, changing some notes' duration in the process) - -

The actual effect of these dots (augmenting a note and making it perfect, or dividing a sequence of notes in different groupings by imperfecting some notes or altering others) is encoded with the dur.quality attribute of the correspoding note elements. Examples of the use of dots of division and augmentation can be found in the section.

-
-
- Accidentals -

[explain that accidentals are usually encoded as independent elements and that accid.ges can be used within notes]

-
-
- Coloration -

[explain where/how coloration can be encoded]

-
-
- Custos -

[explain that there is a custos element available]

-
-
-
-
- Repertoire: Neume Notation -

This chapter describes the elements, model classes, and attribute classes that are part of the MEI.neumes module.

-
- Overview of the Neumes Module -

The MEI Neumes Module represents the community’s attempt to create a standardized set of rules that encapsulate in a logical, systematic, and unequivocal way the musical information represented and conveyed by Western European neumatic notations (beginning with the late ninth century and continuing to the printed books of the twentieth). Most neume notation is used to set music to an existing text. The syllable is the fundamental unit of structure, with the neumes themselves serving as a means of “sonifying” the text. A syllable may be expressed via one or more neumes, with the particular neume shape chosen depending on the pitch contour that is being employed and the desired interpretation.

-

The `syllable` element is used as the primary organizational element for neume notation within a `layer` element. Within `syllable`, the `syl` element defined in the `MEI.shared` module is used for encoding the textual content, while the `neume` and `nc` elements are used to encode the neumes themselves. Within these Neumes Module elements, other standard MEI mechanisms are available to accommodate, for example, editorial or critical markup.

-
- Basic four elements -

The following four elements are the fundamental components of the Neumes Module:

-

- - - -

-

Neume notation can be thought of as "neumed text". Therefore, the syllable element provides high-level organization in this repertoire.

-

- - - -

-

(syllable) – Individual lyric syllable.

- - -
-

-

- - - Sign representing one or more musical pitches. As such, a neume consists of one or more nc element(s):

- - - Connected - Non-connected - - - -
- Connected - -
- - -
- Non-connected - -
- - -
-

- - - -

-

Sign representing a single pitched event, although the exact pitch may not be known. Examples of neume components are:

- - - Example 1 - Example 2 - Example 3 - - - -
- nc-1 - -
- - -
- nc-2 - -
- - -
- nc-3 - -
- - -
-
-
-
- Neumes Module Background -

Neume encoding in MEI was initially developed as part of the Hildegard von Bingen project at the University of Tübingen. MEI was chosen as the basic representation format after a comparison of existing music encoding formats. The initial work on this module was performed by Gregor Schräder (Ein XML-Datenformat zur Repräsentation kritischer Musikedition unter besonderer Berücksichtigung von Neumennotation), supervised by Prof. Stefan Morent. Since 2012 a group of scholars has been working on the development of a new version of the MEI schema for neume notations (Ichiro Fujinaga, Jennifer Bain, Debra Lacoste, Kate Helsen, and Inga Behrendt). Afterwards, other chant scholars joined the group bringing further expertise on other kinds of early music notations (namely Elsa De Luca, Alessandra Ignesti, and Sarah A. Long).

-
-
- Neume Notation and MEI -

There are four main challenges in encoding Western European early music. The first relates to the fact that early notation was just a mnemonic aid that helped the readers to recall the music they already knew by heart and, as such, it conveys only partial musical information (Bain, Behrendt, & Helsen 2014; Helsen, Behrendt, & Bain 2017). Indeed, it is only with the invention of staff lines in the eleventh century that the system of musical transmission gradually changed, relying more on the written record rather than on orality. The second challenge refers to the existence of different regional styles of early notation; early-music manuscripts display a great graphical variety of musical signs, which include both neumes and other notational elements conveying further musical information (e.g., significative letters, Old Hispanic ticks, etc.). Thirdly, some of those regional notational styles occasionally share graphically similar shapes; these similar shapes within the different notational styles are understood by modern scholars to represent the same, a similar, or even a different musical meaning. Finally, while on occasion the neume shapes appear to mirror graphically the musical characteristics of the sound being represented (e.g., pen-stroke going up = rising melody), in many instances it is generally understood that the meaning attached to the neumes (or the other notational elements) may not be so straight-forward, but instead was ruled by conventions shared by the people who knew orally the musical repertory being fixed in written form by means of notation.

-

What do these challenges entail for modern encoders?

-

Firstly, sometimes we have to deal with written signs whose meaning is obscure to us and, while we can infer the meaning of some of those signs from the study of later manuscripts with the same melodies and a more precise notation, in other cases we need to turn to music palaeographers who examine the recurrence of those written signs and the context where they were used. By analysing scribal hands in particular manuscripts, palaeographers can often work out if a written sign is a meaningless scribal variant or a graphical feature conveying musical meaning to the medieval reader. Secondly, since a neume shape could either mirror on the page the aural event or bear some other musical meaning attached by convention, the encoding sometimes relies on the visual level or on the semantic level, and this distinction has to be made on a case-by-case basis. Moreover, since the same written sign could have multiple interpretations according to the style of notation where it was employed, it is crucial to be aware of the conventions of each regional notational alphabet in order to capture the musical information conveyed by that sign in the contexts where it is found.

-

See two examples of shapes found in different regional styles that are not captured with the same encoding:

-

- Example 1 -

-

- St Gall notation Oriscus (one-note ornamental neume). The oriscus is the middle note of a three-note raising gesture (commonly called salicus in the literature).

- - -
-

-

-

- - <neume> - <nc> - <oriscus/> - </nc> - <nc tilt="ne" intm="u"/> -</neume> - -
-

-

- Old Hispanic notation: Two-note downward melodic gesture.

- - -
-

-

-

- - <neume> - <nc tilt="ne"/> - <nc curve="c" tilt="s" intm="d"/> -</neume> - -
-

-

- Example 2 -

-

- Old Hispanic notation: Four-note neutral-low-high-low melodic gesture.

- - -
-

-

-

- - <neume> - <nc tilt="ne"/> - <nc tilt="se" intm="d"/> - <nc tilt="ne" intm="u"/> - <nc tilt="se" intm="d"/> -</neume> - -
-

-

- Aquitanian notation: Three-note rising neume with oriscus on the second note.

- - -
-

-

-

- - <neume> - <nc> - <oriscus/> - </nc> - <nc tilt="ne" intm="u"/> -</neume> - -
-

-

A further complication is that while the music encoding aims to narrow down and capture the meaning of the neumes in a logical and coherent system, occasionally the significance of some neumes is under debate (e.g., quilisma) and, despite its aim for accuracy, the encoding must remain open for future interpretations. From all these challenges has arisen the need for an early music encoding standardisation, that is, a set of rules that work for the description of any neume across all early notations regardless of the different methodologies applied to the study of individual notations and their idiosyncrasies.

-

Broadly speaking, Western early notations belong to two main categories. On one side we have notations where two or more notes were represented by a single pen-stroke, while on the other side there are notations where the notes are graphically separated by means of discrete dots or short pen-strokes. These distinctions have been described even within single notational styles as gapped or not gapped (Behrendt, Bain, & Helsen 2017). To date, the MEI Neumes Module has been tested mainly on square notations and stroke notations (St. Gall, Old Hispanic, etc.), but also on Aquitanian point-notation.

-
-
- Samples of MEI encodings -
- Elements -

- neume and nc are the most common elements used in the MEI Neumes module. In the following examples we can see how these elements are used to describe sung gestures of 1, 2, and 4 notes in square notation.

- - - - One pitch - Staff notation. Example A - - -
- One pitch - -
- - -
-

-

- - <neume> - <nc pname="f" oct="3"/> -</neume> - -
-

- - - - One pitch - Staff notation. Example B - - -
- One pitch - -
- - -
-

-

- - <neume> - <nc pname="c" oct="3"/> -</neume> - -
-

- - - - Two pitches - Staff notation - - -
- Two pitches - -
- - -
-

-

- - <neume> - <nc pname="e" oct="3" tilt="n"/> - <nc pname="c" oct="3"/> -</neume> - -
-

- - - - Four pitches - Staff notation - - -
- Four pitches - -
- - -
-

-

- - <neume> - <nc pname="a" oct="3"/> - <nc pname="b" oct="3"/> - <nc pname="g" oct="3" tilt="se" con="g"/> - <nc pname="f" oct="3" tilt="se" con="g"/> -</neume> - -
-

-

In addition to neume and nc the following elements are also frequently used in the MEI Neumes Module: custos, episema, hispanTick, liquescent, ncGrp, oriscus, quilisma, signifLet, strophicus. Note that nc, episema, hispanTick, and signifLet are neume elements. Instead oriscus, liquescent, quilisma, and strophicus are elements that must be part of a nc element. The custos is an element that is encoded inside the syl element. Furthermore, there are many other elements such as Editorial and Metadata elements that are not specific to Neumes and are not listed here.

-

- custos: to indicate a symbol placed at the end of a line of music to indicate the first note of the next line. Sometimes called a "direct" (see MEI encoding of custos below).

-

mdiv: to indicate pause between neumes

- - -

-

- episema: to indicate an episema (see MEI encoding of episema below).

- - -
-

-

- hispanTick: to indicate Old Hispanic ticks (see MEI encoding of hispanTick below).

- - -
-

-

- liquescent: to indicate a liquescent (see MEI encoding of liquescent neumes below).

- - -
-

-

- ncGrp: to indicate multiple ncs.

-

- oriscus: to indicate an oriscus.

- - - - ORISCUS - Square notation - - -
- Oriscus1 - -
- - -
-

-

- - <neume> - <nc oct="3" pname="g"> - <oriscus/> - </nc> -</neume> - -
-

- - - - ORISCUS - St Gall notation - - -
- Oriscus2 - -
- - -
-

-

- - <neume> - <nc/> - <nc> - <oriscus/> - </nc> - <nc tilt="ne" intm="u"/> -</neume> - -
-

-

- quilisma: to indicate a quilisma (see MEI encoding of quilisma below).

-

-

- - -
-

-

- signifLet: element indicates significative letter(s) attached to a neume or a nc (see MEI encoding of signifLet below).

-

-

- - -
-

-

- strophicus: to indicate a strophicus

- - - - STROPHICUS - Square notation - - -
- Strophicus - -
- - -
-

-

- - <neume> - <nc pname="c" oct="4" tilt="n" ligated="true"/> - <nc pname="a" oct="3" ligated="true"/> - <nc pname="c" oct="4"/> - <nc pname="c" oct="4"> - <strophicus/> - </nc> - <nc pname="c" oct="4"> - <strophicus/> - </nc> -</neume> - -
-

-
-
- Neume component attributes -

- - - - - - -

- - - - GAPPED CONNECTION - Old Hispanic notation - - -
- Gapped - -
- - -
-

-

- - <neume> - <nc tilt="e"/> - <nc con="g" tilt="n" rellen="l" intm="u"/> -</neume> - -
-

- - - - LOOPED CONNECTION - Old Hispanic notation - - -
- Looped - -
- - -
-

-

- - <neume> - <nc s-shape="s"/> - <nc con="l" tilt="ne" intm="u"/> -</neume> - -
-

- - - - EXTENDED CONNECTION - Old Hispanic notation - - -
- Extended - -
- - -
-

-

- - <neume> - <nc tilt="ne"/> - <nc curve="c" con="e" tilt="sw" rellen="s" intm="d"/> -</neume> - -
-

-

Nota bene: the following neume has a similar shape but the neumatic connection is not extended.

- - - - NON-EXTENDED CONNECTION - Old Hispanic notation - - -
- Non-extended - -
- - -
-

-

- - <neume> - <nc tilt="n"/> - <nc curve="c" tilt="s" rellen="s" intm="d"/> -</neume> - -
-

-

- - - -

- - - - CURVE - Old Hispanic notation - - -
- Curve - -
- - -
-

-

- - <neume> - <nc curve="c"/> - <nc con="g" curve="a" intm="s"/> -</neume> - -
-

-

- - - -

- - - - ANGLED - Old Hispanic notation - - -
- Angled - -
- - -
-

-

- - <neume> - <nc tilt="e"/> - <nc angled="true" intm="u"/> - <nc angled="true" intm="u"/> - <nc tilt="n" rellen="l" intm="u"/> -</neume> - -
-

-

- - - -

- - - - HOOK – Old Hispanic notation - - -
- Hook - -
- - -
-

-

- - <neume> - <nc tilt="ne"/> - <nc tilt="se" hooked="true" rellen="s" intm="d"/> -</neume> - -
-

-

- - - {true | false} if this nc is part of a ligature. See the encoding of the strophicus example, above.

-

- - - -

- - - - RELATIVE LENGTH – Old Hispanic notation. Example A - - -
- Relative-Length-A - -
- - -
-

-

- - <neume> - <nc tilt="ne"/> - <nc tilt="se" rellen="s" intm="d"/> -</neume> - -
-

- - - - RELATIVE LENGTH – Old Hispanic notation. Example B - - -
- Relative-Length-B - -
- - -
-

-

- - <neume> - <nc tilt="ne"/> - <nc tilt="se" rellen="l" intm="d"/> -</neume> - -
-

-

- - - -

- - - - TILT – Old Hispanic / St Gall notation - - -
- Tilt - -
- - -
-

-

- - <neume> - <nc tilt="ne"/> -</neume> - -
-

-

- - - -

- - - - S-SHAPE – Old Hispanic notation - - -
- S-shape-A - -
- - -
-

-

- - <neume> - <nc s-shape="s"/> -</neume> - -
-

- - - - S-SHAPE – St Gall notation - - -
- S-shape-B - -
- - -
-

-

- - <neume> - <nc s-shape="w"> - <oriscus/> - </nc> -</neume> - -
-

-
-
- Custos attributes -

- - - - - -

- - - - CUSTOS - Staff notation - - -
- Custos1 - -
- - -
-

-

- - <custos pname="f" oct="3"/> - -
-

- - - - CUSTOS - Late Aquitanian notation - - -
- Custos2 - -
- - -
-

-

- - <custos pname="c" oct="4"/> - -
-

- - - - CUSTOS - Aquitanian notation - - -
- Custos3 - -
- - -
-

-

- - <custos loc="+3"/> - -
-

- - - - CUSTOS - Aquitanian notation - - -
- Custos4 - -
- - -
-

-

- - <custos loc="0"/> - -
-

- - - - CUSTOS - Aquitanian notation - - -
- Custos5 - -
- - -
-

-

- - <custos pname="a" oct="4"/> - -
-

-

Nota bene: in the last example we can read the exact pitch of the custos because the lozenged punctum (placed one step below the line) signals the lower note of the semitone E-F. This information, combined with the identification of the finalis of the piece, allows us to decipher the mode of this piece, that is the 4th.

-
-
- Episema attributes -

- - - - -

- - - - EPISEMA – Staff notation - - -
- Episema-A - -
- - -
-

-

- - <neume> - <nc pname="a" oct="4" tilt="s"> - <episema form="h" place="above"/> - </nc> - <nc pname="g" oct="4"/> -</neume> - -
-

- - - - EPISEMA - St Gall notation. Example A - - -
- Pes rotundus episema - -
- - -
-

-

- - <neume> - <nc curve="a"/> - <nc intm="u" tilt="ne" rellen="l"> - <episema form="h" place="above-right"/> - </nc> -</neume> - -
-

- - - - EPISEMA - St Gall notation. Example B - - -
- Pes quadratus episema - -
- - -
-

-

- - <neume> - <nc tilt="se"/> - <nc intm="u" tilt="ne" rellen="l"> - <episema form="h" place="above-right"/> - </nc> -</neume> - -
-

- - - - EPISEMA - St Gall notation. Example C - - -
- Pes quassus episema - -
- - -
-

-

- - <neume> - <nc s-shape="w"/> - <nc intm="u" tilt="ne" rellen="l"> - <episema form="v" place="above-right"/> - </nc> -</neume> - -
-

-
-
- Liquescent attributes -

- - - - -

- - - - LIQUESCENT - Staff notation. Example A - - -
- Liquescent.Ex.A - -
- - -
-

-

- - <neume> - <nc curve="a" pname="b" oct="3"> - <liquescent/> - </nc> -</neume> - -
-

- - - - LIQUESCENT - Staff notation. Example B - - -
- Liquescent.Ex.B - -
- - -
-

-

- - <neume> - <nc curve="c" pname="c" oct="4" tilt="n"> - <liquescent/> - </nc> -</neume> - -
-

- - - - LIQUESCENT - Aquitanian notation - - -
- Liquescent - -
- - -
-

-

- - <neume> - <nc curve="c"> - <liquescent/> - </nc> -</neume> - -
-

-
-
- Old Hispanic tick attributes -

- - - - -

- - - - HISPAN TICK - Old Hispanic notation. The following encoding refers to the neume signalled by the arrow on the left. - - -
- Hispan tick - -
- - -
-

-

- - <neume> - <nc curve="a"/> - <nc tilt="n" intm="u"> - <hispanTick tilt="n" place="above-right"/> - </nc> -</neume> - -
-

-
-
- Quilisma attribute -

- - - -

- - - - QUILISMA - Staff notation - - -
- Quilisma - -
- - -
-

-

- - <neume> - <nc pname="d" oct="4"/> - <nc pname="e" oct="4"> - <quilisma/> - </nc> - <nc pname="f" oct="4"/> - <nc pname="e" oct="4"/> -</neume> - -
-

- - - - QUILISMA - Old Hispanic notation - - -
- Quilisma2 - -
- - -
-

-

- - <neume> - <nc> - <quilisma waves="2"/> - </nc> - <nc tilt="n" intm="u"/> - <nc tilt="se" rellen="l" intm="d"/> -</neume> - -
-

-
-
- Significative letters attribute -

- - - -

- - - - SIGNIFICATIVE LETTERS - St Gall notation - - -
- Significative Letters - -
- - -
-

-

- - <neume> - <nc tilt="ne"> - <signifLet place="above-right">c</signifLet> - </nc> - <nc con="g" rellen="s" intm="d"/> - <nc con="g" tilt="e" rellen="l" intm="d"/> -</neume> - -
-

-
-
- Note -

Other articulation marks such as ictus, circulus, semicirculus, accentus, and other fonts in SMuFL can be encoded using: glyph.auth, glyph.name, glyph.num, and glyph.uri.

-
-
- Basic Encoding – Syllable -

The following example illustrates the MEI encoding of the opening of Hildegarde’s “O Splendidissima Gemma” with the text “O splendidissima”. This example provides the basic MEI skeleton to have a valid MEI file and it may be used for reference for scholars willing to start encoding early music (and its text) in MEI. Information about the staff has been omitted for brevity, but it was originally encoded on a 5-line staff with two clefs, a “C” and a “F” on lines 5 and 3, respectively.

-

-

- - -
-

-

-

- - <music xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <body> - <mdiv> - <score> - <section> - <staff n="1"> - <layer> - <syllable> - <syl n="initial"> - <rend color="red">O</rend> - </syl> - <neume> - <nc oct="3" pname="e"/> - <nc oct="2" pname="d"/> - <nc oct="3" pname="e"/> - </neume> - </syllable> - <syllable> - <syl>splen_</syl> - <neume> - <nc oct="3" pname="g"/> - <nc oct="3" pname="e"/> - </neume> - <neume> - <nc oct="3" pname="d"/> - <nc oct="3" pname="e"/> - </neume> - </syllable> - <syllable> - <syl>di_</syl> - <neume> - <nc tilt="n" oct="3" pname="f"/> - <nc tilt="se" con="g" oct="3" pname="d"/> - <nc tilt="se" con="g" oct="3" pname="c"/> - </neume> - </syllable> - <syllable> - <syl>dis_</syl> - <neume> - <nc tilt="n" oct="3" pname="e"/> - </neume> - </syllable> - <syllable> - <syl>si_</syl> - <neume> - <nc oct="2" pname="a"/> - <nc con="g" oct="2" pname="b"/> - <nc con="g" tilt="n" oct="3" pname="c"/> - </neume> - </syllable> - <syllable> - <syl>ma </syl> - <neume> - <nc oct="2" pname="b"/> - <nc oct="2" pname="a"/> - </neume> - </syllable> - </layer> - </staff> - </section> - </score> - </mdiv> - </body> -</music> - -
-

-
-
- Manuscripts -

Samples of MEI of St Gall notation are taken from the winter volume of the so-called ”Hartker Antiphonary” CH-SGs Cod. Sang. 390.

-

Samples of MEI of Old Hispanic notation are taken from the ”León Antiphoner” E-L MS 8.

-

Samples of MEI of Aquitanian notation are taken from sources on the Portuguese Early Music Database.

-
-
-
- Bibliographic References -

Bain, Jennifer, Inga Behrendt, and Kate Helsen. 2014. “Linienlose Neumen und ihre Repräsentation mit MEI Schema, Herausforderungen in der Arbeit im Optical Neume Recognition Project (ONRP).” Digitale Rekonstruktionen mittelalterlicher Bibliotheken. Edited by Sabine Philippi and Philipp Vanscheidt. Trierer Beiträge zu den historischen Kulturwissenschaften 12: 119–32.

-

Behrendt, Inga, Jennifer Bain, and Kate Helsen. 2017. “MEI Kodierung der frühesten Notation in linienlosen Neumen.” Kodikologie und Paläographie im Digitalen Zeitalter 4 / Codicology and Palaeography in the Digital Age. Vol. 4. Edited by Hannah Busch, Franz Fischer, and Patrick Sahle, with the cooperation of Philip Hegel and Celiz Krause, Norderstedt 2016. Köln: Institut für Dokumentologie und Editorik e.V, 2017, 281–96.

-

- De Luca, Elsa, Jennifer Bain, Inga Behrendt, Ichiro Fujinaga, Kate Helsen, Alessandra Ignesti, Debra Lacoste, and Sarah Long. 2019. ”Cantus Ultimus’ MEI Neume Module and its Interoperability Across Chant Notations”. Music Encoding Conference, Vienna.

-

- De Luca, Elsa, Jennifer Bain, Inga Behrendt, Ichiro Fujinaga, Kate Helsen, Alessandra Ignesti, Debra Lacoste, and Sarah Long. “Capturing Early Notations in MEI: The Case of Old Hispanic Neumes”. Musiktheorie-Zeitschrift für Musikwissenschaft 2, 2019: 229-49.

-

Helsen, Kate, Inga Behrendt, and Jennifer Bain. 2017. “A Morphology of Medieval Notations in the Optical Neume Recognition Project.” Arti musices: Croatian Musicological Review 48/2: 241–266.

-

MEI Guidelines v4, ch. 6: Neume Notation introducing nc as “neume component”.

-
-
-
- Repertoire: String Tablature -

This chapter describes the attribute classes that are part of the MEI.tablature module.

-
- Overview of the Tablature Module -

The tablature module is used to record basic tablature notation. It is designed primarily for guitar and similar plucked-string instruments.

-

The lines attribute on the staffDef element is used to define the number of lines, courses, or strings, present in the tablature. The tab.strings attribute is then used to enumerate the pitches of the open strings. It is important to note that this is given using the written pitch, not the sounding pitch. For example, the Western 6-string guitar, in standard tuning, sounds an octave below written pitch.

-

The tab.strings attribute gives the string tuning, ordered from highest to lowest pitch.

-

For standard guitar tuning, the staffDef element might look like this:

-

-

- - <staffDef lines="6" n="1" tab.strings="e5 b4 g4 d4 a3 e3"/> - -
-

-

Chromatic alteration of the open string’s pitch may be indicated with the '-' or 'f' (flat), or the '#' or 's' (sharp). Multiple sharps and flats are not permitted.

-

A guitar in E-flat tuning might look like this:

-

-

- - <staffDef lines="6" n="1" tab.strings="ef5 bf4 gf4 df4 af3 ef3"/> - -
-

-

Some instruments, like the 12-string guitar, have the four lowest strings tuned an octave above but are still written on a 6-line tablature staff. In this case, you may enumerate the open string pitches while maintaining 6 lines.

-

-

- - <staffDef lines="6" n="1" tab.strings="e4 e3 a4 a3 d4 d3 g5 g4 b4 b4 e5 e5"/> - -
-

-

The note element is used to capture the specific events in the tablature. The tab.string attribute is used to capture which string the note is to be played on. String order is the same as that given in the tab.strings attribute. This attribute takes a positive integer in the range of 1-9.

-

-

- - <note dur="4" oct="3" pname="a" tab.string="3"/> - -
-

-

In the case of fretted instruments, the fret number may be captured using the tab.fret attribute. An open string may be indicated using the value 0 (zero).

-

-

- - <layer> - <note dur="4" oct="2" pname="a" tab.fret="5" tab.string="6"/> - <note dur="4" oct="2" pname="a" tab.fret="0" tab.string="5"/> -</layer> - -
-

-
-
-
- Lyrics and Performance Directions -

This chapter describes how to encode words and syllables in vocal notation. This text is typically written under a staff to indicate the text to be vocally performed. As such, this text should not be confused with other text on the score, for which see chapter .

-
- Vocal Text -

These guidelines suggest two methods for encoding text in vocal notation: encoding syllables as and encoding performed text as after the notes (and other staff events) either within layer elements or within measure elements when available (for example in a Common Music Notation context). Each method may be more convenient depending on the source text and on the textual phenomena that the encoding intends to record.

-

Both methods eventually rely on the syl element, which is part of the ‘shared’ module and is therefore available in all MEI files. The following sections will begin by introducing the general use of syl and then show in detail the two different encoding methods.

-
-
- Lyric Syllables -

By ‘lyric syllable’, these guidelines mean a word or portion of a word that is to be performed vocally. Each syllable is encoded with the syl element, with which it is also possible to specify the position of the syllable in a word, the type of connectors between syllables, alignment adjustments, and the formatting for each syllable. These are the key components:

-

- - - - - -

-

The attribute wordpos is used to specify the position of the marked-up lyric syllable in a word. It allows the following values:

- - - Indicates that the current syllable’s position is initial; that is, at the beginning of a word; - - Indicates that the current syllable is in the middle of a word; - - Indicates that the syllable’s position is terminal; that is, at the end of a word. - -

When a syllable is at the beginning or in the middle of a word (in which case it will have the wordpos attribute set to ‘i’ or ‘m’), it is recommended to specify the type of connector written between the current and the following syllable. This is expressed with the con attribute, which takes the following values:

- - - A space is used as a connector between syllables; - - A dash is used as a connector between syllables; - - An underscore sign (indicating prolongation of the syllable) is used as a connector between syllables; - - A tilde is used to indicate elision with the following syllable. This is typically rendered as a small curved line between the syllables. - -

Occasionally, a word or a final syllable needs to be extended across multiple notes. In this case an ‘extender’ is provided. An extender is a continuous line drawn at the text’s baseline from the end of the syllable associated with the first note until the last note to be sung with the syllable.

-

The use of syl described in this section is common to CMN and other notation systems, such as mensural notation. Other uses specific to certain types of notation and repertoires are addressed in other chapters. See for example .

-
-
- Vocally Performed Text Encoded Within Notes -

Each lyric syllable can be encoded directly within an associated note, either by using the syl attribute on note or the verse element.

-

Using the syl attribute on notes is the simplest way of encoding vocally performed text and is recommended only for simple situations or for those encodings which do not focus on vocally performed text.

-

The following example from Handel’s Messiah (HWV 56) shows the use of syl:

-

-

- Handel, Messiah HWV 56, Hallelujah - -
-
- - <measure> - <staff> - <layer> - <note dots="1" dur="4" oct="5" pname="c" syl="Hal-"/> - <note dur="8" oct="4" pname="g" syl="le-"/> - <beam> - <note dur="8" oct="4" pname="a" syl="lu-"/> - <note dur="8" oct="4" pname="g" syl="jah,"/> - </beam> - <rest dur="4"/> - </layer> - </staff> -</measure> - -
-

-

When there are multiple lines of vocally performed text, or the encoder wishes to be more specific about connectors, etc., the use of verse and syl is recommended.

-

- - - -

-

The following example from Handel’s Messiah (HWV 56) shows the use of verse:

-

-

- - <measure> - <staff> - <layer> - <note dots="1" dur="4" oct="5" pname="c"> - <verse n="1"> - <syl con="d" wordpos="i">Hal</syl> - </verse> - </note> - <note dur="8" oct="4" pname="g"> - <verse n="1"> - <syl con="d" wordpos="m">le</syl> - </verse> - </note> - <beam> - <note dur="8" oct="4" pname="a"> - <verse n="1"> - <syl con="d" wordpos="m">lu</syl> - </verse> - </note> - <note dur="8" oct="4" pname="g"> - <verse n="1"> - <syl wordpos="t">jah,</syl> - </verse> - </note> - </beam> - <rest dur="4"/> - </layer> - </staff> -</measure> - -
-

-

As it is common practice in written text, it is assumed that a space separates words. Many vocal texts, however, introduce elisions and connect two syllables into one unit. For example, the vocal text from Mozart’s Don Giovanni sung by Don Giovanni in Finale II, Ho fermo il core in petto introduces an elision between the word fermo and il and between core and in. An elision can be indicated by placing both syllables within the same note and setting the syl element’s con attribute value to 't':

-

-

- - <note> - <verse> - <syl con="t" wordpos="t">re</syl> - <syl wordpos="i">in</syl> - </verse> -</note> - -
-

-

When there is more than one line of text, more than one verse element can be used. The following example from a piano reduction of Wagner’s Rheingold has two lines of text, with an English translation on the second line. Note the use of the xml:lang attribute to differentiate the two languages:

-

-

- Example from Wagner’s Rheingold with translated text. - -
-
- - <scoreDef> - <staffGrp> - <staffDef clef.line="4" clef.shape="F" keysig="4s" lines="5" n="1"></staffDef> - </staffGrp> -</scoreDef> -<section> - <measure> - <staff n="1"> - <layer n="1"> - <note dur="2" oct="3" pname="f" stem.dir="down"> - <verse n="1" xml:lang="ger"> - <syl con="d" wordpos="i">Rei</syl> - </verse> - <verse n="2" xml:lang="eng"> - <syl>thinks</syl> - </verse> - </note> - <note dur="8" oct="3" pname="f" stem.dir="down"> - <verse n="1"> - <syl wordpos="t">fes</syl> - </verse> - <verse n="2"> - <syl>it</syl> - </verse> - </note> - <note dur="8" oct="3" pname="f" stem.dir="down"> - <verse n="1"> - <syl>zu</syl> - </verse> - <verse n="2"> - <syl>were</syl> - </verse> - </note> - </layer> - </staff> - </measure> - <measure> - <staff n="1"> - <layer> - <note dur="4" oct="3" pname="b" stem.dir="down"> - <verse n="1"> - <syl con="d" wordpos="i">wal</syl> - </verse> - <verse n="2"> - <syl>wise</syl> - </verse> - </note> - <note dur="4" oct="3" pname="d" stem.dir="down"> - <accid accid="n"></accid> - <verse n="1"> - <syl wordpos="t">ten,</syl> - </verse> - <verse n="2"> - <syl>now</syl> - </verse> - </note> - <rest dur="4" dur.ges="8p"></rest> - </layer> - </staff> - </measure> -</section> -
-

-

Optionally, it is possible to include an lb element within verse to explicitly encode line and line group endings. This is specifically meant to facilitate karaoke applications.

-

Finally, the rhythm attribute on l can be used to specify a rhythm for the syllable that differs from that of the notes on the staff (see ).

-
-
- Vocally Performed Text Encoded Separately -

Vocally performed text may also be encoded separately from the notes with the lg element. These are the main components:

-

- - - - - - -

-

Since this element is separated from the encoding of the notes, it must be associated with a staff that will provide rhythm information when required for automated processing. The staff attribute gives the associated staff and if there is more than one layer on that staff, the layer attribute may be used to indicate the layer from which the rhythm should be taken. If there is any divergence between the rhythm of the vocally performed text and the notes, the rhythm attribute on l may be used to specify the text’s rhythm.

-

-

- - - <measure metcon="false" n="1"> - <staff n="1"> - <layer n="1"> - <note dur="4" pname="e" oct="3" stem.dir="down"> - <verse n="1"> - <syl>Es</syl> - </verse> - </note> - </layer> - </staff> -</measure> -<measure n="2"> - <staff n="1"> - <layer n="1"> - <note dur="2" pname="a" oct="3" stem.dir="down"> - <verse n="1"> - <syl>war</syl> - </verse> - </note> - <note dur="4" pname="a" oct="3" stem.dir="down"> - <verse n="1"> - <syl>ein</syl> - </verse> - </note> - <note dots="1" dur="4" pname="e" oct="3" stem.dir="down" xml:id="n8zcqth"> - <verse n="1"> - <syl con="d" wordpos="i">Kö</syl> - </verse> - </note> - <note dur="8" pname="e" oct="3" stem.dir="down" xml:id="nibn3m21"> - <verse n="1"> - <syl wordpos="t">nig</syl> - </verse> - </note> - <note dur="4" pname="e" oct="3" stem.dir="down"> - <verse n="1"> - <syl>in</syl> - </verse> - </note> - </layer> - </staff> - <tie endid="#nibn3m21" staff="1" startid="#n8zcqth" lform="dashed"/> -</measure> -<measure n="3"> - <staff n="1"> - <layer n="1"> - <note dots="1" dur="2" pname="f" oct="3" stem.dir="down"> - <verse n="1"> - <syl con="d" wordpos="i">Thu</syl> - </verse> - </note> - <note dur="2" pname="c" oct="3" stem.dir="up"> - <verse n="1"> - <syl wordpos="t">le,</syl> - </verse> - </note> - </layer> - </staff> -</measure> -<!-- later --> -<div> - <lg staff="1"> - <l rhythm="4 2 4 2 4 2. 2"> <syl>Es</syl> <syl>ging</syl> <syl>ihm</syl> <syl>nichts</syl> <syl con="d" wordpos="i">dar</syl> <syl con="d" wordpos="m">ü</syl> <syl wordpos="t">ber,</syl> - </l> - </lg> -</div> - - -
-

-
-
- Drama -

This section is supposed to explain stage directions and speeches in MEI drama.

-
-
-
- Text Encoding -

This chapter describes methods for encoding textual content with MEI. It is divided into section: One part deals with in MEI, the other with . While the first covers structures of textual documents such as front matter or back matter, the latter describes how to mark up features and various entities within a text, such as names, tables or quotes. These features may appear both within data (a figure scribbled as marginal annotation into a score by a bored second violin…) and metadata (a number of dates within a text about the creation of a work). Accordingly, many of the elements and models explained in this chapter are used to encode . However, they should not be confused with the elements from the chapter, which deals with performed text in MEI.

-

Most of the elements described here take inspiration from encoding formats that deal primarily with text, such as HTML and the Text Encoding Initiative (TEI). These elements are provided to encode relatively basic textual information. For deeper encoding of text, these Guidelines recommend consideration of other text-specific encoding formats with embedded MEI markup.

-
- Text Structures -

This chapter focuses on the text that accompanies the score, i.e., paratext (prefatory material, back matter, appendices, etc.).

-
- Organizing Text into Divisions -

Text can be organized in different parts, for example in chapters or sections. The div element is used to encode such structural divisions.

-

- - - -

-

For example, printed scores, before the actual notation, can have text that can be organized in multiple sections (e.g., a preface, a critical report, performance instructions, etc. for which see the following sections); each of these sections should be identified by a different div element. Text might also occur in between music sections (see ), for example in a collection of romantic piano works, a few pieces might be preceded or followed by poetry. Such text should be encoded with the div element, as demonstrated in the following example:

-

-

- - <mdiv> - <score> - <section> - <!-- Score of Franz Liszt's "Sonetto 104 del Petrarca --> - </section> - <div> - <!-- Text of Francesco Petrarca's Sonett n. 104. --> - <lg> - <l>L'aspectata vertù, che 'n voi fioriva</l> - <l>quando Amor cominciò darvi bataglia,</l> - <!-- ... --> - </lg> - </div> - </score> -</mdiv> - -
-

-

Textual divisions may have titles or other forms of introductory material, which are encoded with the head element.

-

- - - -

-

The following example shows the encoding of a preface translated into three different languages, each with a different heading:

-

-

- - <front> - <div xml:lang="en"> - <head>Preface</head> - <!-- text --> - </div> - <div xml:lang="de"> - <head>Vorwort</head> - <!-- text --> - </div> - <div xml:lang="it"> - <head>Prefazione</head> - <!-- text --> - </div> -</front> - -
-

-

Having said that div identifies any structural organization of text, it is often helpful to distinguish the typology of division. The type attribute can be used for this purpose.

-

- - - -

-

- type may contain any number of space-separated tags describing the nature of the div (or, in fact, any other element). The following example shows the use of type (in combination with n) to indicate three prefaces in English, German and Italian are columns on the same page.

-

-

- - <front> - <div n="1" type="column" xml:lang="en"> - <head> - Preface - </head> - <!-- text --> - </div> - <div n="2" type="column" xml:lang="de"> - <head>Vorwort</head> - <!-- text --> - </div> - <div n="3" type="column" xml:lang="it"> - <head>Prefazione</head> - <!-- text --> - </div> - <pb/> -</front> - -
-

-
-
- Paratext -

This section introduces paratextual material, such as title pages, prefaces, indexes and other text that precedes or follows the actual score.

-
- Front Matter -

By ‘front matter’ these Guidelines mean distinct sections of a text (usually, but not necessarily, a printed one), prefixed to it by way of introduction or identification as a part of its production. Features such as title pages or prefaces are clear examples; a less definite case might be the prologue attached to a dramatic work. The front matter of an encoded text should not be confused with the MEI header described in chapter , which provides metadata for the entire file.

-

An encoder may choose simply to ignore the front matter in a text, if the original presentation of the work is of no interest. No specific tags are provided for the various kinds of subdivision which may appear within front matter: instead, generic div (“division”) elements may be used, which should not be confused with mdiv (“musical division”) elements. The following suggested values for the type attribute may be used to distinguish various kinds of division characteristic of front matter:

- - - A foreword or preface addressed to the reader in which the author or publisher explains the content, purpose, or origin of the text. - - A formal declaration of acknowledgement by the author in which persons and institutions are thanked for their part in the creation of a text. - - A formal offering or dedication of a text to one or more persons or institutions by the author. - - A summary of the content of a text as continuous prose. - - A table of contents, specifying the structure of a work and listing its constituents. The list element should be used to mark its structure. - - A pictorial frontispiece, possibly including some text. - -

The following extended example demonstrates how various parts of the front matter of a text may be encoded. The front part begins with a title page, which is presented in section , below. This is followed by a dedication and a preface, each of which is encoded as a distinct div:

-

-

- - <front> - <titlePage> - <!-- transcription of title page --> - </titlePage> - <div type="dedication"> - <p> - <!-- Dedicatory text --> - </p> - </div> - <div type="preface"> - <head> - Preface - </head> - <p> - <!-- paragraph 1 --> - </p> - <p> - <!-- paragraph 2 --> - </p> - <!-- additional material --> - </div> -</front> - -
-

-

The front matter concludes with another div element, shown in the next example, this time containing a table of contents, which contains a list element (as described in chapter ). Note the use of the ptr element to provide page-references: the implication here is that the target identifiers (song1, song2, etc.) will correspond with identifiers used for the mdiv elements containing the individual songs. (For a description of the ptr element, see chapter .)

-

-

- - <div type="contents"> - <head> - Contents - </head> - <list form="ordered"> - <li>On Wenlock Edge - <ptr target="#song1"/> - </li> - <li>From Far, From Eve and Morning - <ptr target="#song2"/> - </li> - <li>Is My Team Ploughing? - <ptr target="#song3"/> - </li> - <li>Oh, When I Was In Love With You - <ptr target="#song4"/> - </li> - <li>Bredon Hill - <ptr target="#song5"/> - </li> - <li>Clun - <ptr target="#song6"/> - </li> - </list> -</div> - -
-

-

Alternatively, the pointers in the table of contents might link to the page breaks at which a song begins, assuming that these have been included in the markup:

-

-

- - <list form="ordered"> - <li>On Wenlock Edge - <ref target="#song1-p1">1</ref> - </li> - <li>From Far, From Eve and Morning - <ref target="#song2-p15">15</ref> - </li> - <!-- .... --> -</list> -<!-- Later in the document --> -<mdiv type="song"> - <pb xml:id="song1-p1"/> - <!-- .... --> -</mdiv> -<mdiv type="song"> - <pb xml:id="song2-p15"/> - <!-- .... --> -</mdiv> -<!-- .... --> - -
-

-
-
- Back Matter -

Conventions vary as to which elements are grouped as back matter and which as front. For example, some books place the table of contents at the front, and others at the back. For this reason, the content models of the front and back elements are identical.

-

The following suggested values may be used for the type attribute on all division elements, in order to distinguish various kinds of divisions characteristic of back matter:

- - - An ancillary self-contained section of a work, often providing additional but in some sense extra-canonical text. - - A list of terms associated with definition texts (‘glosses’). - - A section in which textual notes are gathered together. - - A list of bibliographic citations. - - Any form of index to the work. - - A statement appearing at the end of a book describing the conditions of its physical production. - -

No additional elements are proposed for the encoding of back matter at present. Some characteristic examples follow; first, an index (for the case in which a printed index is of sufficient interest to merit transcription):

-

-

- - <back> - <div type="index"> - <head> - Index - </head> - <list type="index"> - <li>a2, a3, etc., 175-176</li> - <li>Abbreviations, 3 - <list type="index"> - <li>Percussion, 205-213</li> - <li>Strings, 307</li> - </list> - </li> - <li>Afterbeats, 77</li> - </list> - </div> -</back> - -
-

-

Note that if the page breaks in the original source have also been explicitly encoded, and given identifiers, the references to them in the above index can more usefully be recorded as links. For example, assuming that the encoding of page 77 of the original source starts like this:

-

-

- - <pb xml:id="text.P77"/> - -
-

-

then the last item above might be encoded more usefully in the following form:

-

-

- - <li>Afterbeats, - <ref target="#text.P77">77</ref> -</li> - -
-

-
-
-
-
- Text in MEI -

This chapter describes methods for encoding textual content with MEI. Textual information on scores has several different uses, although some text is closer to music notation than other kinds. For example, tempo marks, directives and lyrics are directly related to the functionality of the notated music and are, therefore, described in other chapters (see for example and ).

-

Most of the elements described here take inspiration from encoding formats that deal primarily with text, such as HTML and the Text Encoding Initiative (TEI). These elements are provided to encode relatively basic textual information. For deeper encoding of text, these Guidelines recommend consideration of other text-specific encoding formats with embedded MEI markup.

-
- Paragraphs -

Paragraphs are fundamental to prose text and typically group one or more sentences that form a logical passage. Usually, it is typographically distinct; that is, it usually begins on a new line and the first letter of the content is often indented, enlarged, or both. This element has a similar meaning as the corresponding elements in Encoded Archival Description (EAD), Text Encoding Initiative (TEI), and HTML.

-

A paragraph is encoded with the p element:

-

- - - -

-

Prose text is used for several different purposes within a MEI document, therefore p can occur in many situations. For example, it may be used within metadata elements (see ):

-

-

- - <samplingDecl> - <p>The encoding contains only the first 5 measures.</p> -</samplingDecl> - -
-

-

Alternatively, paragraphs may be part of the document contents (and therefore encoded within music), either as or within the music notation. In these cases, a paragraph will likely be contained by a div or other elements containing prose (e.g., annot, figDesc, etc.).

-

The following example shows a paragraph in a preface section:

-

-

- - <front> - <div> - <head> - The Preludes<lb/> - Symphonic Poem No.3 by F. Liszt. - </head> - <p>What else is our life but a series of preludes to that unknown Hymn, the first and - solemn note of which is intoned by Death? - </p> - </div> -</front> - -
-

-
-
- Text Rendition -

Sometimes, it is desirable to capture the typographical qualities of a word or phrase without assigning it a special meaning. For this purpose, MEI offers the rend element, similar to TEI’s hi element. Using CSS-like values, its rend attribute can be used to specify many typographic features, such as font style, font variants, and relative font size and weight. In addition, text decoration, direction, and enclosing ‘boxes’ may be captured. While rend is used to record relative font size and weight, absolute values for these qualities (measured in printer’s points) should be specified using the fontsize and fontweight attributes. In addition to commonly found typographical qualities, MEI provides the altrend attribute for the capture of additional, user-defined rendition information.

-

The rend element can accept glyph.auth and glyph.uri attributes, which provide encoders with the ability to specify an external authority for Unicode codepoints in the textual content. Only the text content that should be rendered using SMuFL code points should go inside the rend element when using glyph.auth and glyph.uri.

-

-

- - <rend> - This is what a G clef looks like: <rend glyph.auth="smufl">&amp;#xE050;</rend> -</rend> -
-

-

- - - - - - - -

-
-
- Figures -

The fig element groups elements representing or containing graphic information such as an illustration or figure. This element is modelled on the figure element in the Text Encoding Initiative (TEI). The fig element is used to contain images, captions, and textual descriptions of the pictures. The images themselves are specified using the graphic element, whose target attribute provides the location of an image. For example:

-

-

- - <fig> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/> -</fig> - -
-

-

The graphic element may occur multiple times within the markup of the figure in order to indicate the availability of different image formats or resolutions:

-

-

- - <fig> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-72.png"/> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-600.png"/> -</fig> - -
-

-
- Figure Captions and Descriptions -

The element caption may be used to transcribe (or supply) a title or descriptive heading for the graphic itself, as in the following example:

-

-

- - <fig> - <caption>Grace notes</caption> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/> -</fig> - -
-

-

The figure description (figDesc) element usually contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image, perhaps without displaying it. This element is intended for use as an alternative to the content of its parent fig element; for example, for display when the equipment in use cannot display graphic images. It may also be used for indexing or documentary purposes, in which case best practice suggests the use of controlled vocabulary terms.

-

-

- - <fig> - <graphic target="emblem1.png"/> - <caption>Emblemi d'Amore</caption> - <figDesc>A pair of naked winged cupids, each holding a flaming torch, in a rural setting.</figDesc> -</fig> - -
-

-

Occasionally, a figure description may have a complex structure. In this case, one or more textual component elements (p [paragraph], table, list, quote, or lg [linegroup]) may be used to model the internal structure of the description:

-

-

- - <fig> - <caption>Grace notes</caption> - <figDesc> - <p>The example shows grace notes within beams ...</p> - <p>This illustration was created by ...</p> - </figDesc> - <graphic target="../samples/snippets/mei2012-30shortexamples/beam-grace/grace-300.png"/> -</fig> - -
-

-
-
- Images -

The graphic element indicates the location of an inline graphic, illustration, or figure. As noted above, there exists a wide variety of different graphics formats, and the following list is in no way exhaustive. Moreover, inclusion of any format in this list should not be taken as indicating endorsement by the MEI of this format or any products associated with it. Some of the formats listed here are proprietary to a greater or lesser extent and cannot therefore be regarded as standards in any meaningful sense. They are, however, widely used by many different vendors. The following formats are widely used at the present time, and are likely to remain supported by more than one vendor’s software:

- - BMP: Microsoft bitmap format - CGM: Computer Graphics Metafile - GIF: Graphics Interchange Format - JPEG: Joint Photographic Expert Group - PBM: Portable Bit Map - PCX: IBM PC raster format - PICT: Macintosh drawing format - PNG: Portable Network Graphics format - Photo-CD: Kodak Photo Compact Disk format - QuickTime: Apple real-time image system - SMIL: Synchronized Multimedia Integration Language format - SVG: Scalable Vector Graphics format - TIFF: Tagged Image File Format - -

Brief descriptions of all the above are given below. Where possible, current addresses or other contact information are shown for the originator of each format. Many formal standards, especially those promulgated by the ISO and many related national organizations (ANSI, DIN, BSI, and many more), are available from those national organizations. Addresses may be found in any standard organizational directory for the country in question.

-
- Vector Graphic Formats - - - SVG is a language for describing two-dimensional vector and mixed vector or raster graphics in XML. It is defined by the Scalable Vector Graphics (SVG) 1.0 Specification, W3C Recommendation, 04 September 2001, available at http://www.w3.org/TR/2001/REC-SVG-20010904/. - - This format is universally supported on Macintosh (tm) systems, and readable by a limited range of software for other systems. Documentation is available from Apple Computer, Cupertino, California USA. - - This vector graphics format is specified by an ISO standard, ISO 8632:1987, amended in 1990. It defines binary, character, and plain-text encodings; the non-binary forms are safer for blind interchange, especially over networks. Documentation is available from ISO and from its member national bodies, such as AFNOR, ANSI, BSI, DIN, JIS, etc. - -
-
- Raster Graphic Formats - - - PNG is a non-proprietary raster format currently widely available. It provides an extensible file format for the losslessly compressed storage of raster images. Indexed-color, grayscale, and true-color images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits. It is defined by IETF RFC 2083, March 1997. - - Currently the most widely supported raster image format, especially for black and white images, TIFF is also one of the few formats commonly supported on more than one operating system. The drawback to TIFF is that it actually is a wrapper for several formats, and some TIFF-supporting software does not support all variants. TIFF files may use LZW, CCITT Group 4, or PackBits compression methods, or may use no compression at all. Also, TIFF files may be monochrome, greyscale, or polychromatic. All such options should be specified in prose at the end of the encodingDesc section of the MEI header for any document including TIFF images. TIFF is owned by Aldus Corporation. Documentation on TIFF is available from the owner at Craigcook Castle, Craigcook Road, Edinburgh EH4 3UH, Scotland, or 411 First Avenue South, Seattle, Washington 98104 USA. - - Raster images are widely available in this form, which was created by CompuServe Information Services, but has by now been implemented for many other systems as well. Documentation is copyright by, and is available from, CompuServe Incorporated, Graphics Technology Department, 5000 Arlington Center Boulevard, Columbus, Ohio 43220 USA. - - PBM files are easy to process, eschewing all compression in favor of transparency of file format. PBM files can, of course, be compressed by generic file-compression tools for storage and transfer. Public domain software exists which will convert many other formats to and from PBM. Documentation of PBM is copyright by Jeff Poskanzer, and is available widely on the Internet. - - This format is used by most IBM PC paint programs, and supports both monochrome and polychromatic images. Documentation is available from ZSoft Corporation, Technical Support Department, ATTN: Technical Reference Manual, 450 Franklin Rd. Suite 100, Marietta, GA 30067 USA. - - This format is the standard raster format for computer using Microsoft Windows (tm) or Presentation Manager (tm). Documentation is available from Microsoft Corporation. - -
-
- Photographic and Motion Video Formats - - - This format is sponsored by CCITT and by ISO. It is ISO/IEC Draft International Standard 10918-1, and CCITT T.81. It handles monochrome and polychromatic images with a variety of compression techniques. JPEG per se, like CCITT Group IV, must be encapsulated before transmission; this can be done via TIFF, or via the JPEG File Interchange Format (JFIF), as commonly done for Internet delivery. - - This format was introduced by Kodak for rasterizing photographs and storing them on CD-ROMs (about one hundred 35mm file images fit on one disk), for display on televisions or CD-I systems. Information on Photo-CD is available from Kodak Limited, Research and Development, Headstone Drive, Harrow, Middlesex HA1 4TY, UK. - -
-
-
-
- Lists -

When a text contains lists, they can be encoded with the following elements:

-

- - - - - -

-

The list element can identify any kind of list; the form attribute can be used to specify whether the list is ordered, unordered etc. Each item in the list is encoded with the li element. The n can be used to record a label for a list item, as in the following example:

-

-

- - <p>The modulation follows the following steps: - <list form="ordered"> - <li n="1">C major</li> - <li n="2">A minor</li> - <li n="3">D major seventh</li> - <li n="4">G major</li> - </list> -</p> - -
-

-

Occasionally, lists have headers or titles, which can be encoded with head:

-

-

- - <list> - <head> - Ornaments in different languages - </head> - <li n="English" xml:lang="en">Turn</li> - <li n="Italian" xml:lang="it">Gruppetto</li> - <li n="French" xml:lang="fr">Gruppetto</li> - <li n="German" xml:lang="de">Doppelschlag</li> -</list> - -
-

-
-
- Tables -

The element table contains text displayed in tabular form, i.e., in rows and columns. A table is the least ‘graphic’ of the elements discussed in this chapter. Almost any text structure can be presented as a series of rows and columns: one might, for example, choose to show a glossary or other form of list in tabular form, without necessarily regarding it as a table. When tabular presentation is regarded as of less intrinsic importance, it is correspondingly simpler to encode descriptive or functional information about the contents of the table, for example to identify one cell as containing a name and another as containing a date, though the two methods may be combined.

-

The table element may appear both within other components (such as paragraphs), or between them, provided that the module defined in this chapter has been enabled. It is to a large extent arbitrary whether a table should be regarded as a series of rows or as a series of columns. For compatibility with currently available systems, however, these Guidelines require a row-by-row description of a table.

-

While rows and columns are always encoded in top-to-bottom, left-to-right order, formatting properties such as those provided by CSS may be used to specify that they should be displayed differently.

-
- Rows -

The tr (table row) element is a formatting element that contains one or more td or th elements (cells) in a table. A cell is the intersection of a row and a column. The precise rendition of the table and its cells should be specified in a style steet.

- - <table> - <tr> - <th colspan="7">Besetzungen der Triosonate und ihrer Nachfolger</th> - </tr> - <tr> - <td/> - <td>Triosonate - <lb/>Standardbes. - </td> - <td>Triosonate für - <lb/>Orgel (Bach) - </td> - <td>Sonate mit obl. - <lb/>Cembalo (Bach) - </td> - <td>Klaviertrio</td> - <td>Streichquartett</td> - <td>Streichtrio</td> - </tr> - <tr> - <td>1. Oberstimme</td> - <td>1. Violine</td> - <td>Orgel r.H.</td> - <td>Violine - <lb/>(Flöte, Gambe) - </td> - <td>Violine</td> - <td>1. Violine</td> - <td>1. Violine</td> - </tr> - <tr> - <td>2. Oberstimme</td> - <td>2. Violine</td> - <td>Orgel l.H.</td> - <td>Cembalo r.H.</td> - <td>Klavier r.H.</td> - <td>2. Violine</td> - <td/> - </tr> - <tr> - <td>harmonische Füllung</td> - <td>Cembalo r.H.</td> - <td/> - <td/> - <td/> - <td>Bratsche</td> - <td>Bratsche</td> - </tr> - <tr> - <td>Bass-Stimme</td> - <td>Cello</td> - <td>Orgel Pedal</td> - <td>Cello</td> - <td>Cello</td> - <td>Cello</td> - <td>Cello</td> - </tr> -</table> - -
-

-
-
- Cells -

The td (table data) element designates a table cell that contains data as opposed to a cell that contains column or row heading information. The colspan and rowspan attributes provide tabular rendering information. They indicate that a particular cell or row of a table spans more than one row or column.

-

-

- - <table> - <tr> - <td colspan="2" rowspan="2">unmittelbares Schlagen</td> - <td colspan="2" rowspan="2">mittelbares Schlagen</td> - </tr> - <tr> - <td>Gegenschlag</td> - <td>Aufschlag</td> - <td>Schütteln</td> - <td>Schrapen</td> - </tr> - <tr> - <td>1. Stäbe</td> - <td>1. Stäbe</td> - <td>1. Rahmen</td> - <td>1. Raspeln</td> - </tr> - <tr> - <td>2. Platten</td> - <td>2. Röhren</td> - <td>2. Gefäße</td> - <td>2. Räder</td> - </tr> - <tr> - <td/> - <td>3. Platten</td> - <td>3. Reihen</td> - <td/> - </tr> - <tr> - <td/> - <td>4. Gefäße</td> - <td/> - <td/> - </tr> -</table> - -
-

-

The th (table header) element designates a table cell containing column or row heading information as opposed to one containing data. The colspan and rowspan attributes tabular display rendering information. They indicate that a particular cell or row of a table spans more than one row or column.

-

-

- - <table> - <tr> - <th colspan="4">Systematische Einteilung der Idiophone</th> - </tr> - <tr> - <td colspan="2">unmittelbares Schlagen</td> - <td colspan="2">mittelbares Schlagen</td> - </tr> - <tr> - <td>Gegenschlag</td> - <td>Aufschlag</td> - <td>Schütteln</td> - <td>Schrapen</td> - </tr> - <tr> - <td>1. Stäbe</td> - <td>1. Stäbe</td> - <td>1. Rahmen</td> - <td>1. Raspeln</td> - </tr> - <tr> - <td>2. Platten</td> - <td>2. Röhren</td> - <td>2. Gefäße</td> - <td>2. Räder</td> - </tr> - <tr> - <td/> - <td>3. Platten</td> - <td>3. Reihen</td> - <td/> - </tr> - <tr> - <td/> - <td>4. Gefäße</td> - <td/> - <td/> - </tr> -</table> - -
-

-
-
-
- Quotation -

It is common, in many types of texts, to find quotations. A quotation is typically attributed to another text other than the one being encoded. Often, the quoted material is typographically distinct from the surrounding text; i.e., surrounded by so-called ‘quote marks’ or rendered as a separate block of text. The quote element is used to mark this function:

-

- - - -

-

The following examples show the use of quote.

-

-

- - <p>Hugh MacDonald has argued that Liszt's Symphonic Poems were meant to - <quote>display the traditional logic of symphonic thought</quote>. -</p> - -
-
- - <p>The majority of the works represented in this catalogue were purchased in Paris and - London between 1928 and 1934. After graduating from Harvard in 1924, Mackay-Smith - spent several years in Europe: - <quote> - <p>I bought my first early music from Harold Reeves in London in the summer of 1928 when - I was able to acquire virtually all the 18th century editions, particularly of trio - music, which he then had in stock, going back not only through his current but also - through earlier catalogues, picking out numbers which remained unsold. It is almost - a shame today to think of the prices at which such things were then available, one - or two pounds apiece. - </p> - </quote> -</p> - -
-

-
-
- Poetry -

This lg (line group) element is used generically to encode any section of text that is organized as a group of lines. Following the recommendations of the Text Encoding Initiative, it is recommended to use it, along with the following elements, for marking up poetry:

-

- - - - - -

-

Because lg groups verses, it can be used to encode additional stanzas not integrated into the music notation. In addition, it is common for a poem to include a title or a header, as is demonstrated by the following example:

-

-

- - <mdiv> - <score> - <section> - <!-- Score of Franz Liszt's "Sonetto 104 del Petrarca" --> - </section> - <div> - <!-- Text of Francesco Petrarca's Sonett n. 104. --> - <lg> - <head> - Sonetto 104 - </head> - <l>L'aspectata vertù, che 'n voi fioriva</l> - <l>quando Amor cominciò darvi bataglia,</l> - <l>produce or frutto, che quel fiore aguaglia,</l> - <l>et che mia speme fa venire a riva.</l> - <!-- ... --> - </lg> - </div> - </score> -</mdiv> - -
-

-
-
- Names -

The name element may be used to mark up portions of a text that function as name.

-

- - - -

-

The name element is intended for generic applications and may be used to identify any named entity, such as a person, item, application, place, etc. Sometimes, however, a more specific encoding is desired, identifying the type of entity by using dedicated elements. MEI offers an (optional) module for this, which provides such elements for various types of names.

-
-
- Dates -

The date element may be used to mark up portions of a text that denote a date.

-

- - - -

-

The element date contains a date in any format, including a date range. A date range may be expressed as textual content or, when intervening punctuation is present, as a combination of date sub-elements and text.

-

-

- - <p> - <date>5/3/05</date> - <date>May 30, 2012</date> - <date>March 1-21, 1812</date> - <date> - <date>March 1, 1812</date>- - <date>March 21, 1812</date> - </date> -</p> - -
-

-

To be more specific about the date, the attributes in the att.datable and att.calendared classes can be used:

-

- - - - -

-

In the following example, the ambiguous date text "5/3/05" is resolved using the isodate attribute:

-

-

- - <p> - <date isodate="1905-05-03">5/3/05</date> - <date isodate="2005-03-05">5/3/05</date> -</p> - -
-

-
-
- Numbers -

The num element may be used to identify any numeric information in a text. The unit may be used to specify the unit of measurement.

-

- - - - -

-

This element is useful when it is necessary to provide specific information about numeric data, such as the unit of measurement or the kind of quantity described, or when it should be displayed in a special manner.

-
-
- Addresses -

Addresses may be encoded using the address element, which itself may hold an arbitrary number of addrLine elements.

-

- - - - -

-

It is important to note that the address element does not hold a reference to the person or organization whose address is specified. This must be provided in a separate element, as in the following example:

- - <p> - <corpName>Universität Paderborn</corpName> - <address> - <addrLine>Warburger Straße 100</addrLine> - <addrLine>33098 Paderborn</addrLine> - <addrLine>Germany</addrLine> - </address> -</p> - -
-

-
-
- Bibliographic Citations and References -

The following element is used in the encoding of bibliographic citations and references:

-

- - - -

-

The bibl element may contain a mix of text and more specific elements, including the following:

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-

These elements fall into the following categories: - identification of the bibliographic entity and those responsible for its intellectual content - publication and distribution data for the bibliographic entity - description of the physical characteristics of the item - annotation of the bibliographic citation and additional details regarding the item’s intellectual content

-

The elements title, edition, series, and identifier fall into the first category as do the elements arranger, author, composer, librettist, lyricist, funder, sponsor, and respStmt. The respStmt element is provided for marking responsibility roles that cannot be recorded using more specific elements. The biblScope element also carries information of an identifying nature.

-

The identifier for a given item may be an International Standard Book/Music Number, Library of Congress Control Number, a publisher’s or plate number, a personal identification number, an entry in a bibliography or catalog, etc.

-

To classify the title according to some convenient typology, the type attribute may be used. Sample values include: main (main title), subordinate (subtitle, title of part), abbreviated (abbreviated form of title), alternative (alternate title by which the work is also known), translated (translated form of title), uniform (collective title). The type attribute is provided for convenience in analysing titles and processing them according to their type; where such specialized processing is not necessary, there is no need for such analysis, and the entire title, including subtitles and any parallel titles, may be enclosed within a single title element. Title parts may be encoded in title sub-elements. The name of the list from which a controlled value is taken may be recorded using the authority attribute.

-

Publication and distribution data may be captured using pubPlace, publisher, distributor, and date elements directly inside bibl when the citation is unstructured. However, these elements should be grouped within imprint whenever practical.

-

The physical characteristics of the cited item may be described using the extent element.

-

Annotation of the bibliographic citation and the provision of other pertinent details are addressed by several elements. Commentary on the bibliographic item or citation is accommodated by the annot and creation elements. The annot element is provided for generic comments, while creation is intended to hold information about the context of the creation of the cited item. Terms by which the bibliographic item can be classified may be placed in genre. For letters and other correspondence, recipient captures the name of the person or organization to whom the item was addressed. The natural language(s) of the item may be recorded in one or more textLang elements. Finally, a holding institution may be documented using the repository element directly within bibl, but physLoc should be used whenever possible as a grouping mechanism for location and shelfmark information. To identify sub-units of the holding institution, repository sub-elements may be used. The name of the list from which a controlled value for the agency name is taken may be recorded using the authority attribute.

-

When supplied with a target attribute, bibl may function as a hypertext reference to an external electronic resource. In addition, other related bibliographic items may be described or referenced using the relatedItem element.

-

-

- - <bibl> - <genre>letter</genre> - <author>Carl Nielsen</author> - <recipient>Gustav Hetsch</recipient> - <creation> - <date isodate="1915-04-08">1915-04-08</date> - </creation> - <physLoc> - <repository> - <identifier auth.uri="http://www.rism.info/" auth="RISM">DK-Kk</identifier> - </repository> - <identifier>CNA IAc</identifier> - </physLoc> - <relatedItem rel="host"> - <bibl xml:id="shared.bibl_d1e380372"> - <title>CNB</title> - <biblScope>V/210</biblScope> - </bibl> - </relatedItem> -</bibl> - -
-

-

Please consult and for more information about recording the names and dates frequently found in bibliographic citations.

-
- Related Items -

In some situations it is necessary to provide references from one bibliographic item to another. For these situations, MEI offers the relatedItem element. A relatedItem may be used inside of bibl, and may either point to a different entity using its target attribute, or may hold the related item as a child.

-

-

- - <bibl> - <genre>letter</genre> - <author>Carl Nielsen</author> - <recipient>Gustav Hetsch</recipient> - <creation> - <date isodate="1915-04-08">1915-04-08</date> - </creation> - <physLoc> - <repository> - <identifier auth.uri="http://www.rism.info/" auth="RISM">DK-Kk</identifier> - </repository> - <identifier>CNA IAc</identifier> - </physLoc> - <relatedItem rel="host"> - <bibl xml:id="shared.bibl_d1e380372"> - <title>CNB</title> - <biblScope>V/210</biblScope> - </bibl> - </relatedItem> -</bibl> - -
-

-

In this example, the nested relatedItem / bibl provides information about the ‘container’ where the outer bibl may be found. The kind of relation is expressed using the rel attribute. It describes the relationship of the child bibl to the relatedItem’s parent bibl.

-

- - - -

-

In these relations, the subject is always the relatedItem, and the object is always the parent of the relatedItem. Thus, a value of rel="preceding" indicates that the resource described within the relatedItem (or referenced by its target attribute) precedes the bibl containing the relatedItem. Following MODS, both values of preceding and succeeding indicate a temporal order.

-

It is important not to confuse relatedItem with the concepts of ; see .

-
-
-
- Annotations -

Annotations are one of the most versatile features of MEI. They are provided using the annot element.

-

- - - -

-

This element may be contained by a wide range of other elements and may contain a large number of other elements. While this offers great flexibility in addressing the wide variety of textual features that might occur within an annotation, it may lead to markup that cannot be effectively processed mechanistically.

-

In all cases, annot provides a comment upon a feature of the encoding, but never contains textual transcription. Depending on its context, an annotation will deal with either its parent element, or, more usually, with the element(s) specified in its plist attribute. This attribute uses URI references to link to one or more other elements using their xml:id attribute values, as in the following example:

-

-

- - <note xml:id="shared.someInterestingNote"/> -<!-- elsewhere in the document: --> -<annot plist="#shared.someInterestingNote"> - <!-- additional information about this note --> -</annot> -
-

-
-
-
-
- Analysis Markup and Harmonies -

This chapter of the MEI Guidelines describes how the results of a musical analysis or harmonic information may be stored in MEI.

-
- Analytical Information -

This chapter describes the use of attributes that capture data which may be useful for analytical purposes. The analysis module provides attributes that record relationships between entities found in the encoding. These attributes may be used differently by different users, depending on the purpose of the analysis.

-

These Guidelines recommend that encoders employ commonly accepted analytical practices, such as ‘functional analysis’ or ‘Schenkerian analysis’, and document their use in the encodingDesc described in section . For general information on musical analysis, please consult Grove Music Online, ‘Analysis’.

-

The relationships between event elements, such as note, chord, and rest, are the basic material of musical analysis. MEI provides linking attributes to ensure a closed network of these relations. They provide the opportunity to record data useful for common analytical tasks. In the context of a formal analysis, for instance, these attributes can be useful in the capture information about the structure of a musical work. Further information on these attributes can be found in .

-
- Event-Specific Analytical Information -

In addition to the common linking attributes (see ), the analysis module also offers other, more specific attributes on certain musical elements:

-

- - - - - - - - -

-
- Melodic Intervals -

The intm attribute offers several methods for encoding the melodic interval from a preceding pitch. First, Parsons Code allows for description of the contour of the melody in very general terms; that is, as up, down, or same note. Parsons Code is helpful for identifying musical works with clearly defined melodies and analyzing the relationship between successive notes of monophonic tunes. For more information about the Parsons Code, please see the "The Directory of Tunes and Musical Themes" by Denys Parsons (2002). The next example shows interval relationships indicated by the Parsons Code:

-

-

- - <measure n="1"> - <staff n="1"> - <layer> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="d" intm="u"/> - <note dur="4" oct="4" pname="e" intm="u"/> - <note dur="4" oct="4" pname="f" intm="u"/> - <note dur="2" oct="4" pname="g" intm="u"/> - <note dur="2" oct="4" pname="g" intm="s"/> - <note dur="4" oct="4" pname="f" intm="d"/> - </layer> - </staff> -</measure> - -
-

-

Alternatively, diatonic interval quality and size may be indicated by a letter signifying the interval quality (A= augmented, d= diminished, M = major, m = minor, P = perfect) followed by a number indicating the size of the interval. The interval direction may be encoded using a leading plus (+) or minus (-) sign:

-

-

- - <measure> - <staff> - <layer> - <note dur="4" oct="5" pname="c"/> - <note dur="4" oct="5" pname="d" intm="+M2"/> - <note dur="4" oct="5" pname="c" intm="-M2"/> - <note dur="4" oct="4" pname="b" intm="-m2"/> - <note dur="4" oct="3" pname="b" intm="-P8"/> - </layer> - </staff> -</measure> - -
-

-

As a third option, signed integers may be used to record the difference in half steps between the previous pitch and the current one. Decimal values accommodate the description of microtonal intervals:

-

-

- - <measure> - <staff> - <layer> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="d" intm="1.1"/> - <note dur="4" oct="5" pname="d" intm="7.9"/> - <note dur="4" oct="5" pname="c" intm="-2.334"/> - </layer> - </staff> -</measure> - -
-

-
-
- Melodic Function -

The mfunc attribute describes melodic function of a note or neume using the Humdrum **embel syntax. In the following example, the note B is labeled as a lower neighbor while all other notes are labeled as chord tones:

- - <section> - <measure n="2"> - <staff n="1"> - <layer> - <chord dur="4" stem.dir="up" xml:id="analysis.chord1"> - <note dur="4" mfunc="ct" oct="4" pname="f" xml:id="analysis.m2e1"/> - <note dur="4" mfunc="ct" oct="4" pname="a" xml:id="analysis.m2e2"/> - <note dur="4" mfunc="ct" oct="5" pname="c" xml:id="analysis.m2e3"/> - </chord> - <note accid="f" - dur="4" - mfunc="ln" - oct="4" - pname="b" - stem.dir="down" - xml:id="analysis.m2e4"/> - </layer> - </staff> - </measure> - <measure n="3"> - <staff n="1"> - <layer> - <chord dur="4" stem.dir="up" xml:id="analysis.chord2"> - <note dur="4" mfunc="ct" oct="4" pname="c" xml:id="analysis.m3e5"/> - <note dur="4" mfunc="ct" oct="4" pname="e" xml:id="analysis.m3e6"/> - <note dur="4" mfunc="ct" oct="4" pname="g" xml:id="analysis.m3e7"/> - </chord> - </layer> - </staff> - </measure> -</section> - -
-

-
-
- Harmonic Intervals -

- - - -

-

In contrast with intm, which characterizes melodic (sequential) intervals, the inth attribute is used to encode the harmonic interval between the current note and other pitches occurring at the same moment in time. The notes of interest may or may not be marked as a chord. In the markup below, for example, the values of inth capture the harmonic intervals between notes distributed across multiple staves and layers.

-

-

- - <measure> - <staff> - <layer n="1"> - <note dur="4" inth="M3 P5" oct="4" pname="c" xml:id="analysis.e1"/> - </layer> - <layer n="2"> - <note dur="4" inth="M3 m3" oct="4" pname="e" xml:id="analysis.e2"/> - </layer> - </staff> - <staff n="2"> - <layer n="3"> - <note dur="4" inth="P5 m3" oct="4" pname="g" xml:id="analysis.e3"/> - </layer> - </staff> -</measure> - -
-

-

Use of the inth permits detailed specification of intervallic information for every note and its function in relation to other simultaneously-occurring notes and hence about the harmonic nature of the musical work.

-
-
- Scale Degrees -

- - - -

-

The deg attribute can be used to represent key-dependent scale-degree information for music in major or minor keys.

-

Scale-degree values are relative to the prevailing major or minor key. In the case of minor keys, scale degrees are characterized with respect to the harmonic minor scale. For example, the pitch F in the key of A minor is the submediant (6), but F is the lowered submediant (6-) in the key of A major.

-

Melodic approach can be indicated by a leading caret (^) or lowercase v, representing ascending and descending approaches, respectively.

-

Chromatic alteration of the scale degree can be represented using a trailing plus (+) or minus (-) signs, signifying raised or lowered scale degree, respectively. The actual amount of chromatic alteration is not indicated.

-

-

- - <!-- Fifth scale degree in the prevailing scale --><note deg="5"/> - -
-
- - <!-- Augmented 5th --><note deg="5+"/> - -
-
- - <!-- Lowered 6 scale degree approached from below --><note deg="^6-"/> - -
-
- - <!-- Leading tone approached from above --><note deg="v7"/> - -
-

-
-
- Pitch Class -

The pclass attribute can be used to encode information about the pitch class to which a note belongs. The attribute’s value must be an integer less than or equal to 11. It is only allowed on the note element. The pclass attribute comes from "musical set theory" elaborated first by Howard Hanson and Allen Forte as a new method for organizing tones. It provides a concept for categorizing musical objects (notes) and describing their relationships. It is a kind of grouping and combining, mostly developed in connection with atonal music. However, the concept of set theory is general and can also be applied to tonal music. A pitch class means the summary of every pitch with specific characteristics that means a pitch class set is an unordered collection of pitches, e.g., every pitch with the name C.

-

A pitch class may contain a large number of pitches, because different octaves and enharmonic spellings of pitch make no difference. The notes C, E, and G would be 0, 4 and 7 in pitch class notation, for example, regardless of the octave in which they are performed. The example below contains the same pitch in four different enharmonic spellings, but all are part of the same pitch class.

-

-

- - <chord> - <note dur="2" oct="5" pclass="2" pname="d"/> - <note accid="ss" dur="4" pclass="2" pname="c"/> - <note accid="ff" dur="1" pclass="2" pname="e"/> -</chord> - -
-

-

For further information on pitch class set theory, please consult the following sources:

- - - http://www.mta.ca/faculty/arts-letters/music/pc-set_project/pc-set_new/pages/introduction/toc.html - "Analyzing Atonal Music: Pitch Class Set Theory and its Contexts" by Michael Schuijler (2008) - Cohen, Allen Laurence (2004). Howard Hanson in Theory and Practice - -
-
- Solmization -

Solmization is a system which associates a syllable with each note of a musical scale. There are various forms of solmization used throughout the world. In Europe and North America, solfège is the most common practice. In this system, the seven syllables for a major scale are do, re, mi, fa, so, la and ti. In the ‘fixed-do’ system, the syllable "do" is always associated with the pitch "c", while in the ‘movable-do’ system, "do" is associated with the tonic note. The psolfa attribute is only allowed on note and nc elements. Its value is unconstrained in order to accommodate various solmization systems.

- - <measure> - <staff n="1"> - <layer> - <note dur="4" oct="4" pname="c" psolfa="do"/> - <note dur="4" oct="4" pname="d" psolfa="re"/> - <note dur="4" oct="4" pname="e" psolfa="mi"/> - <note dur="4" oct="4" pname="f" psolfa="fa"/> - </layer> - </staff> -</measure> - -
-

-
-
-
- Metrical Conformance -

It is often helpful to record whether a given staff, layer, or measure obeys the meter established for it. The following attributes are provided for this purpose:

-

- - - - -

-

When used on staff or layer elements, the metcon attribute can be used to indicate if the duration of the contained events is equal to (c), less than (i), or greater than (o) that predicted by the time signature. When used on the measure element, metcon takes a boolean value, where true indicates conformance by all staff and layer descendants of the measure.

-

In the first example below, the layer, staff, and measure all match the prevailing meter. In the second example, however, the first layer does not comply with the meter, making the staff containing it and measure as a whole non-compliant. When there is a single layer or when all the layers on a staff agree with each other, metrical compliance can be indicated on the staff element. When, however, not all layers have the same value for metcon, then it is necessary to omit metcon at the staff level. The value of metcon on the measure level can usually be computed based on the values of its layer and staff sub-elements.

-

-

- - <!-- in 2/4 --><measure metcon="true" n="1"> - <staff n="1"> - <layer> - <note dur="4" oct="4" pname="f"/> - <note dur="8" oct="4" pname="b"/> - <note dur="8" oct="4" pname="a"/> - </layer> - </staff> -</measure> - -
-
- - <!-- in 2/4 --><measure metcon="false" n="1"> - <staff n="1"> - <layer metcon="i"> - <note dur="4" oct="4" pname="f"/> - <note dur="8" oct="4" pname="b"/> - </layer> - <layer metcon="true"> - <note dur="4" oct="4" pname="d"/> - <note dur="8" oct="4" pname="g"/> - <note dur="8" oct="4" pname="f"/> - </layer> - </staff> -</measure> - -
-

-
-
-
- Harmony -

This chapter describes the encoding of indications of harmony occurring within a music text, e.g., chord names, tablature grids, figured bass, or signs for harmonic analysis, and the methods by which these indications can be connected with their interpretations. For encoder-supplied analysis of intervallic content, please see chapter .

-
- Indications of Harmony -

On the most basic level, chords in the musical text can be encoded using the chord element:

-

- - - -

-

Additional information on the use of the chord element is available in and .

-

With only this kind of markup, harmonic information is implicit in the notes themselves. The elements and attributes of this module, however, provide for the encoding of explicit indications of harmony, such as chord symbols, tablature grids, figured bass signs, and the symbols of harmonic analysis like Roman numerals and their interpretation.

-
- Interpreted Chord Data in scoreDef -

An harmonic label, such as "7", may occur many times throughout an MEI instance. Where the goal is diplomatic transcription, simply recording the uninterpreted label is sufficient. Recording the precise meaning of such a label requires storing an interpretation. But, including the interpretation at every point of occurrence of the label would swell the size of the file and complicate the markup for those users who are not interested in the interpretation. Therefore, MEI separates the encoding of harmonic labels from the encoding of the interpretation of those labels.

-

The following elements enable the creation and re-use of interpreted chord data:

-

- - - - - - - - - - -

-

The chordTable element is a container for a set of chord definitions, while the chordDef element defines a single chord. Chord definitions may be created a priori or as the result of analysis of the pitch content of the music at hand, for instance, by examination of the notes occurring on the downbeat of each measure. In this way, the chord definitions serve as a record of the analysis.

-

Even though it is not required by the schema, an xml:id attribute on chordDef is necessary to permit the creation of associations between harmonic indications in the musical text with the chord defined here. The xml:id attribute provides a unique identifier for the chord definition that can be referenced by the harm element’s chordref attribute.

-

Individual pitches of a chord are encoded using chordMember. The inth attribute provides the means for indicating the number of half steps of the chord note above the bass note.

-

These simple resources allow for the detailed specification and interpretation of harmonic indications found in the musical text. For example, the harmonic label A can be equated with a fully spelled-out indication of functional harmony that can be substituted for the harmonic label, say, in an aural rendition:

-

-

- - -<!-- Chord defined in scoreDef --><chordDef xml:id="harmonychordA"> - <chordMember oct="2" pname="a"></chordMember> - <chordMember oct="3" pname="e"></chordMember> - <chordMember accid.ges="s" oct="4" pname="c"></chordMember> - <chordMember oct="4" pname="e"></chordMember> - <chordMember oct="4" pname="a"></chordMember> -</chordDef> -<!-- Later in musical text --> -<harm chordref="#harmonychordA" tstamp="1">A</harm> -
-

-

Alternatively, the non-bass chord tones may be indicated, not with pitch names, but with their intervallic distance above the bass note. Therefore, the example above may also be encoded:

-

-

- - <chordDef xml:id="harmonychordA2"> - <chordMember oct="2" pname="a"/> - <chordMember inth="7"/> - <chordMember inth="16"/> - <chordMember inth="19"/> - <chordMember inth="24"/> -</chordDef> - -
-

-

The preceding encoding possibilities provide the detailed information necessary to create playable chord annotations. For more generic uses, however, the encoding can be taken one step further; that is, it can be reduced to its minimum intervallic content by eliminating octave duplications and expressing all chord members, including the bass note, using intervals above the bass. Of course, the inth attribute for the bass note itself should be set to 0. For example:

-

-

- - <chordDef xml:id="harmonychordA3"> - <chordMember inth="0"/> - <chordMember inth="4"/> - <chordMember inth="7"/> -</chordDef> - -
-

-
-
- Chord Tablature Grids -

The pos attribute on chordDef, the fing and fret attributes on chordMember, and the barre element child of chordDef are provided in order to create displayable and performable chord tablature grids for guitar and other fretted string instruments. The fret at which a finger should be placed is recorded in the fret attribute, while fing indicates which finger, if any, should be used to play an individual string. The values x and o are used to indicate muffled and open strings, respectively.

-

The chordDef element may contain barre sub-elements when a single finger is used to stop multiple strings. Here the fret attribute gives the fret position at which the barre should be created, while the startid and endid attributes are used to indicate the chordMember elements on which the barre starts and finishes.

-
-
- Indications of Harmony in the Music Text -

With regard to indications of harmony, MEI attempts to strike a balance between very precise (interpreted) and very loose (uninterpreted) markup needs. Therefore, various kinds of harmonic labels are accommodated by the harm element. While some are more structured than others, in the final analysis they all function as labels. Therefore, MEI provides only a single element for the capture of harmonic indications of all kinds:

-

- - - - -

-

The harm element can be used to capture chord labels that consist entirely of text:

- - <measure> - <harm tstamp="1">Cmaj</harm> - <harm tstamp="2">ii6</harm> -</measure> - -
-

-

or labels that are chord tablature grids:

-

-

- Chord grid without label - -
-
- - <harm chordref="#harmonychordA" tstamp="1"/> - -
-

-

or labels that mix these styles:

-

-

- Chord grid with label - -
-
- - <harm chordref="#harmonychordA" rendgrid="gridtext" tstamp="1">A7</harm> - -
-

-

The harm element must define a point of attachment using one of the following attributes: startid, tstamp, tstamp.ges or tstamp.real. The most commonly-used of these are startid and tstamp.

-

The dur attribute encodes the logical and visual duration of the harmony. Please note that the dur attribute here is not a true duration, but rather a time stamp for the end point of the harmony.

-

Precise placement of the harmonic label can be controlled through the use of attributes in the att.harm.vis attribute class.

-
- Figured Bass -

Figured bass is a specialized form of harmonic indication. In order to support the capture of the semantics of figured bass, and not just its visual representation, MEI provides the following elements:

-

- - - - -

-

Figured bass, consisting as it does of text, can always be represented purely visually. This is probably how an OMR program or other naive encoder might deal with the markup of figured bass:

-

-

- Figured bass - -
-
- - <harm place="above" staff="1" tstamp="1">6</harm> - -
-

-

However, this kind of approach fails to recognize that a figured bass is being used and not some other system of harmonic indications. To capture this knowledge, the preceding example can also be marked more explicitly with:

-

-

- - <harm place="above" staff="1" tstamp="1"> - <fb> - <f>6</f> - </fb> -</harm> - -
-

-

In order to provide greater control over the individual components of the figured bass, each component can be treated as a figure. The natural symbol is encoded using the Unicode MUSIC NATURAL SIGN character.

-

-

- Figured bass with accidental - -
-
- - <harm place="above" staff="1" tstamp="1"> - <fb> - <f>7</f> - <f>♮</f> - </fb> -</harm> - -
-

-

Encoding order of the component f elements is significant as is the encoding order of the characters within each component. In the preceding example, the entire figured bass sign is encoded from top to bottom, in other words, just as the figure appears on the page. In the following examples, the encoding order of the characters in f explicitly locates the accidentals:

-

-

- Figured bass with chromatically altered figure - -
-
- - <harm place="below"> - <fb> - <f>7♭</f> - </fb> -</harm> - -
-
- Figured bass with chromatically altered figures - -
-
- - <harm> - <fb> - <f>6</f> - <f>4+</f> - <f>♮3</f> - </fb> -</harm> - -
-

-

You may use 6\ and 6/ for numerals that should be shown with a backslash and slash, respectively. An alternative would be to use the "bslash" (backward slash) and "fslash" (forward slash) on the rend element.

-

-

- Figured bass with chromatically altered figure - -
-
- - <harm> - <fb> - <f><rend rend="bslash">6</rend></f> - <!-- or --> - <f><rend rend="fslash">6</rend></f> - </fb> -</harm> - -
-

-

Each component of the figured bass sign may use the extender attribute to indicate that horizontal lines are used to mark the extent of the figure’s harmonic influence. The altsym attribute can be used to point to a user-defined symbol that better represents the figure component, for example, the combined "2" and "+" below. Similar to the slash in the preceding example before, the small curve over the "5" in example 6 can be represented by the Unicode COMBINING INVERTED BREVE.

-

-

- Figured bass with alternative sign - -
-
- - <measure> - <harm tstamp="1"> - <fb> - <f>̑</f> - <f extender="true">5</f> - <f altsym="combo2plus">2+</f> - </fb> - </harm> - <harm tstamp="3"> - <fb> - <f>3</f> - </fb> - </harm> -</measure> - -
-

-

Because the repertoire of signs is so large, figures which consist entirely of a mark indicating repetition of the preceding figure, should be represented by the character appearing in the document. For example, in some notational styles, the repetition sign is a dash (-), while in others it is a solidus (/). Using characters like this is also consistent with other existing figured bass encoding schemes.

-

-

- Figured bass repetition - -
-
- - <harm tstamp="1.5"> - <fb> - <f>-</f> - </fb> -</harm> - -
-

-

Often, the distinction between extending lines and repetition signs is unclear. Treating what at first appear to be extenders as repetition signs, however, can sometimes help to simplify the required markup and to make the intent of the signs explicit. For example, in the following example the dashes on beat 4 and 4.5 are treated as repetition signs:

-

-

- Extenders and repetition - -
-
- - <measure> - <harm tstamp="3.5"> - <fb> - <f>♭3</f> - <f>6</f> - <f>5</f> - </fb> - </harm> - <harm tstamp="4"> - <fb> - <f>-</f> - <f>♯3</f> - </fb> - </harm> - <harm tstamp="4.5"> - <fb> - <f>7</f> - <f>-</f> - </fb> - </harm> -</measure> - -
-

-

Using extender attributes for this example may make it easier to render the figured bass symbol, but it is less explicit with regard to the intended harmony. For example, it is difficult to ascertain what harmony should be sounding on beat 4 and its after-beat.

-

-

- - <measure> - <harm tstamp="3.5"> - <fb> - <f>♭3</f> - <f extender="true">6</f> - <f>5</f> - </fb> - </harm> - <harm tstamp="4"> - <fb> - <f extender="true">♯3</f> - </fb> - </harm> - <harm tstamp="4.5"> - <fb> - <f>7</f> - </fb> - </harm> -</measure> - -
-

-

The primary goal of fb is not the capture all the visual idiosyncracies that can be found in printed and manuscript scores throughout the centuries, but to provide a more-or-less standardized label. The markup below, or any markup in fact, cannot capture the exact look of the figured bass signs. The altsym attribute may be used to provide access to a user-defined symbol for precise rendition. Similarly, the facs attribute may be employed to point to the symbol as it occurs in the encoding source material.

-

-

- Figured bass with alternative sign - -
-
- - <!-- Ex. a --><measure> - <harm tstamp="3"> - <fb> - <f>8</f> - <f altsym="#my6_1" facs="#source6_1">6♮</f> - <f>4+</f> - <f>2</f> - </fb> - </harm> - <harm tstamp="4"> - <fb> - <f altsym="#my6_2" facs="#source6_2">6\</f> - <f>4</f> - <f>3</f> - </fb> - </harm> -</measure> - -
-
- - <!-- Ex. b --><harm tstamp="4.5"> - <fb> - <f>6\</f> - </fb> -</harm> - -
-
- - <!-- Ex. c --><harm tstamp="1"> - <fb> - <f>5/</f> - </fb> -</harm> - -
-
- - <!-- Ex. d --><harm> - <fb> - <f altsym="#my5" facs="#source5">5+</f> - </fb> -</harm> - -
-

-
-
-
-
-
-
- Scholarly Editing with MEI -

This chapter introduces markup targeting at digital scholarly editions of music. In , the alignment of multiple sources / witnesses of the same musical text is discussed. covers editorial observations in and interventions to the text. finally deals with the special requirements and needs of genetic editions in music.

-
- Critical Apparatus -

This chapter describes how to encode differences between multiple exemplars of the same musical work (often referred to in MEI as ‘sources’). The mechanisms and elements described in this chapter are closely related to their counterparts in the TEI guidelines. It is also important to refer to chapter of these guidelines, especially concerning the choice element described therein.

-
- General Usage -

The following elements are defined in the critApp Module:

-

- - - - - -

-

An app element always encapsulates the differences between varying sources. Therefore, it must contain at least two child elements. Possible child elements are lem and rdg, which use the same model, but have a different meaning: Whereas lem is used for prioritizing one alternative, a rdg has no such additional meaning and simply indicates a reading as found in one or more sources. Accordingly, lem is allowed only once in app, whereas rdg may appear as often as necessary.

-

-

- - <app> - <lem> - <!-- preferred reading --> - </lem> - <rdg> - <!-- alternative reading --> - </rdg> - <rdg> - <!-- alternative reading --> - </rdg> -</app> - -
-

-

The rdg (and lem) elements use the source attribute to point to one or more descriptions of the bibliographic sources containing the material they mark:

-

-

- - <!-- In the document content: --><app> - <rdg source="#critApp.source1"> - <!-- reading of source 1 --> - </rdg> - <rdg source="#critApp.source2 #critApp.source3"> - <!-- reading of sources 2 *and* 3 --> - </rdg> -</app> - -
-
- - <!-- Earlier in the document header: --><sourceDesc> - <source xml:id="critApp.source1"> - <!-- bibliographic description of source 1 --> - </source> - <source xml:id="critApp.source2"> - <!-- bibliographic description of source 2 --> - </source> - <source xml:id="critApp.source3"> - <!-- bibliographic description of source 3 --> - </source> -</sourceDesc> - -
-

-

The seq attribute may be used on lem or rdg to record the sequence of a series of readings. In the following example, the material in source B is marked as sequential to (and perhaps derived from) the reading in source A:

-

-

- - <app> - <rdg seq="1" source="#critApp.sourceA"> - <!-- material in source 1 --> - </rdg> - <rdg seq="2" source="#critApp.sourceB"> - <!-- material in source 2 --> - </rdg> -</app> - -
-

-

If interested in modeling such dependencies between witnesses, using markup from is generally recommendable.

-

If a source has additional content that is not found in other sources, an empty rdg element may be used to indicate the lack of material in the other sources. In the following example, source 1 includes material that is not found in sources 2 and 3:

-

-

- - <app> - <rdg source="#critApp.source1"> - <!-- additional content of source 1 --> - </rdg> - <rdg source="#critApp.source2 #critApp.source3"/> -</app> - -
-

-

When working with a large number of sources, it might seem tedious to provide references for all sources. However, use of the rdg element without source is not recommended because such an encoding is not explicit and is therefore difficult to process.

-
-
- Variants in Musical Content -

The app element may be used to accommodate textual variation at nearly any point in a musical text. For example, it may be used to indicate minor differences such as stem directions:

-

-

- - <layer> - <!-- preceding notes --> - <app> - <rdg source="#critApp.source1"> - <note dur="2" oct="4" pname="b" stem.dir="down"/> - </rdg> - <rdg source="#critApp.source2"> - <note dur="2" oct="4" pname="b" stem.dir="up"/> - </rdg> - </app> - <!-- following notes --> -</layer> - -
-

-

or to indicate more significant differences, such as the insertion of extra measures:

-

-

- - <section> - <measure>…</measure> - <measure>…</measure> - <app> - <rdg source="#critApp.source1"/> - <rdg source="#critApp.source2"> - <!-- source 2 has 2 measures not found in source 1 --> - <measure>…</measure> - <measure>…</measure> - </rdg> - </app> - <measure>…</measure> -</section> - -
-

-

However, the flexibility in the location of app places a burden on the encoder to ensure that the app, rdg, and lem elements are used correctly; that is, the content of every rdg and lem has to be a valid replacement for its parent app, even though this cannot be controlled effectively by the MEI schema.

-
-
- Variants in Score Definitions -

In addition to its use for differentiation of the musical content of multiple sources, app may also be utilized to describe the layout of different scores, even when the musical content itself remains the same. An example of this is two sources that have the same content, but a different ordering of staves on which the content is written. By definition, the order of staves in MEI is described in and derived from the order of staffDef elements in scoreDef, not from the order of staff elements within a measure. The staff element in a measure points to its corresponding staffDef using the same value for n on both elements.

-

This rather loose mechanism makes it possible to point dynamically to the correct staff definition for a given source. The following example demonstrates how this can be accomplished for two sources, both presenting a two-staff score, but with differing staff order. No further app element is necessary within the measure to describe the alternative score order of the sources.

-

-

- - <score> - <app> - <rdg source="#critApp.source1"> - <scoreDef> - <staffGrp> - <staffDef n="1"/> - <staffDef n="2"/> - </staffGrp> - </scoreDef> - </rdg> - <rdg source="#critApp.source2"> - <scoreDef> - <staffGrp> - <!-- The order of <staffDef> elements defines score order, not its @n attribute! --> - <staffDef n="2"/> - <staffDef n="1"/> - </staffGrp> - </scoreDef> - </rdg> - </app> - <section> - <measure> - <staff n="1">…</staff> - <staff n="2">…</staff> - </measure> - </section> -</score> - -
-

-

When unique values for n on layerDef and layer are provided, it is possible to reallocate layers in the same fashion as staves.

-

This mechanism may also be used to describe not only differing page orientations, formats and margins, but also clefs and keys.

-

The use of app in conjunction with staffDef illustrates the greater flexibility of connecting staff and staffDef by a shared n value. A technically more robust alternative to n would be to use the def attribute on staff, which points to the xml:id of a staffDef. However, this strong connection would be tied to one specific staffDef, and would not allow to pick one alternative out of an app.

-
-
- Nesting Apparati -

In some situations, musical sources will agree at one level while differing at a lower level. For these cases, app elements may be nested to any level necessary. In the following example, there are three sources, two of which agree on the addition of a measure, but differ in the content of the added measure:

-

-

- - <section> - <measure>…</measure> - <app> - <rdg source="#critApp.source1"/> - <rdg source="#critApp.source2 critApp.#source3"> - <!-- whereas source1 omits it, source2 and source3 have an additional measure --> - <measure> - <staff> - <layer> - <app> - <!-- while source2 provides a measure rest, source3 has a whole note --> - <rdg source="#critApp.source2"> - <mRest/> - </rdg> - <rdg source="#critApp.source3"> - <note dur="1" oct="3" pname="g"/> - </rdg> - </app> - </layer> - </staff> - </measure> - </rdg> - </app> - <measure>…</measure> -</section> - -
-

-

When nesting app elements, it is important that the value(s) in the child rdg element’s source attribute must be a strict subset of the ancestor rdg element’s source value.

-
-
-
- Editorial Markup -

It is often necessary to render an account of any changes made to a musical text during its creation (and any subsequent editing) and to accommodate editorial comment necessitated by an editorial process. The elements and attributes described in this chapter may be used to record such editorial interventions, whether made by the composer, the copyists of the manuscript, the editor of an earlier edition used as a copy text, or the current encoder/editor.

-

The scope of the elements described herein is therefore the description of features relating to the genesis, later revision and editorial interpretation of a text. Mechanisms for describing multiple sources are described in chapter of these Guidelines, while the full setup for genetic editions is described in chapter .

-

The elements described in this chapter may be contained by a wide range of other MEI elements and, in turn, may contain a variety of elements. The encoder must assume responsibility for the appropriateness of the markup; that is, a great many combinations of editorial and transcriptional markup are technically possible, but care must be taken to see that the encoding does not contravene the rationale of these Guidelines. In general, it should be ensured that a file would be valid if the editorial markup would be omitted, as such a validation cannot be ensured in an efficient way by the MEI schema.

-

For most of the elements discussed here, some encoders may wish to indicate both a responsibility; that is, a coded value indicating the person or agency responsible for making the editorial intervention in question, and an indication of the degree of certainty which the encoder wishes to associate with the intervention. The elements discussed here thus may potentially carry the following optional attributes:

-

- - - - -

-

They are available through the generic attribute class att.common, which is a member of att.responsibility, and the attribute class att.edit, to which these elements subscribe.

-

Many of the elements discussed here can be used in two ways. Their primary purpose is to indicate that their content represents an editorial intervention (or, in some cases, the lack of intervention) of a specific kind. Sometimes, pairs or other meaningful groupings of such elements can be recorded, then wrapped within the special purpose choice element:

-

- - - -

-

Wrapping elements this way enables the encoder to represent, for example, a text in its ‘original’, uncorrected form alongside the same text in one or more ‘edited’ forms. Making use of this style of representation, software may dynamically switch between the ‘Urtext view’ of the text and one or more ‘views’ of the text after the application of the encoded editorial interventions.

-

Elements which can be combined in this way constitute the model.choicePart class. The default members of this class are sic, corr, reg, orig, and unclear. As model.editLike and model.editorialLike are members of model.choicePart, choice, subst, abbr, and expan can also be combined with the other elements. All of their functions and usage are described in greater detail below.

-

Three categories of editorial intervention are discussed by the remainder of this chapter:

- - indication or correction of apparent errors; - indication of regularization of variant, irregular, non-standard, or eccentric forms; and - editorial additions, suppressions, and omissions. - -
- Abbreviations -

MEI offers methods for marking abbreviations in prose, as in the following example:

-

-

- - <p> - ... the next passage shall be performed in<abbr>pno:</abbr>... -</p> - -
-

-

or abbreviations in the music itself, as in the following example:

-

-

- - <abbr> - <bTrem unitdur="16"> - <note dur="4" oct="5" pname="c" stem.mod="2slash"/> - </bTrem> -</abbr> - -
-

-

The generic type attribute may be used to classify the abbreviation according to a convenient typology. Sample values include:

- - - the abbreviation provides the first letter(s) of the word or phrase, omitting the remainder; - - the abbreviation omits some letter(s) in the middle; - - the abbreviation comprises a special symbol or mark; - - the abbreviation includes writing above the line; - - the abbreviation comprises the initial letters of the words of a phrase; - - the abbreviation is for a title of address (Dr, Ms, Mr, ...); - - the abbreviation is for the name of an organization; - - the abbreviation is for a geographic name. - -

This tag is the mirror image of the expan tag (not to be confused with the expansion element described in ). Both abbr and expan allow the encoder to transcribe an abbreviation and its expansion. In the case of abbr, the original is transcribed as the content of the element and the expansion as an attribute value, while expan reverses this. The choice between the two is up to the user. For example:

-

-

- - <div> - <!-- using abbr --> - <p> - … the next passage shall be performed in<abbr expan="piano">pno:</abbr>… - </p> - <!-- using expan --> - <p>… the next passage shall be performed in - <expan abbr="pno:">piano</expan>… - </p> -</div> - -
-

-

The abbr tag is not required; if appropriate, the encoder may transcribe abbreviations in the source text silently, without tagging them. If abbreviations are not transcribed directly but expanded silently, then the MEI header should indicate this is the case. The cert attribute signifies the degree of certainty ascribed to the expansion of the abbreviation. The expan attribute gives an expansion of the abbreviation. The resp attribute contains an ID reference to an element containing the name of the editor or transcriber responsible for supplying the expansion of the abbreviation.

-

When the content of the abbr or expan attributes requires additional markup, an attribute cannot be used. In this case, the abbreviated and expanded forms must be presented within elements. Furthermore, as alternatives to each other, the abbr and expan elements must be wrapped by the choice element, as described above. The previous example, where the 'o:' in 'pno:' is written as superscript, would be encoded as:

-

-

- - <p>… the next passage shall be performed in - <choice> - <abbr>pn<rend rend="sup">o:</rend> - </abbr> - <expan>piano</expan> - </choice> -</p> - -
-

-
- Instructions -

Many musical scores make use of various kinds of shorthand notation which omit some parts of the score that have already been written elsewhere. Typical examples for this are symbols that indicate repetition of the preceding measure or beat. In MEI, these symbols can be encoded using the mRpt and beatRpt elements respectively. Often, similar graphical symbols (often one or two slashes, "//") are used to mean that the current staff should have the same or similar content as another staff.

-

- colla parte directives have a less strictly-defined scope than the ‘Rpt elements’ (beatRpt, halfmRpt, mRpt, mRpt2, multiRpt). That is, rather than specifying the repetition of content of a particular duration, like a measure or beat, colla parte instructions can refer to material of any length. In order to encode such scribal shorthand, MEI offers the cpMark element, which allows filling of blank spaces in the score with horizontally and/or vertically distant material.

-

- - - -

-

Like any other ‘controlEvent’ (see ), cpMark is placed in the score using the staff and tstamp attributes. The end point of the mark itself, when necessary, may be indicated using the tstamp2 attribute. The source material, which is intended to be inserted in the space indicated by the copy mark, can be identified by the attributes origin.tstamp, origin.tstamp2, origin.staff and origin.layer. While origin.tstamp provides the relative distance from the beginning of the "gap", origin.tstamp is relative to the position identified by origin.tstamp. However, origin.tstamp defaults to the same value as tstamp2 and should only be provided when necessary. When neither origin.staff nor origin.tstamp are provided, they take the same values as the cpMark’s staff and tstamp attributes; that is, they indicate a strict ‘vertical’ or ‘horizontal’ copy.

-

-

- Copy marks in the first and second violin of C.M.v.Weber’s Freischütz, Autograph, Nr.3 (Walzer), measures 223-231 - -
-

-

In the example above, there are no less than three different copy instructions, which need to be encoded with four cpMark elements. First, Weber inserts characters from "a" to "f" in red ink to identify filled measures. Then, he repeats the same characters in empty measures, which indicates that the content from the filled measures should be copied here. While one could try to encode this with just one cpMark element, it is both clearer and easier to process when using two elements.

-

The second and third shorthand indications are written in the second violin (lower staff). Here, Weber writes "unis.[ono]", silently omitting the reference to the first violin. His next shorthand ("in 8va") additionally instructs the copyist to double the written material in another octave. This information can be captured using the dis and dis.place attributes on cpMark.

-

-

- - <cpMark origin.tstamp="-6m+1" staff="8" tstamp="1" tstamp2="5m+4">a. b. c. d. e. f. g.</cpMark> -<cpMark origin.tstamp="-6m+1" staff="9" tstamp="1" tstamp2="5m+4">a. b. c. d. e. f. g.</cpMark> -<cpMark origin.staff="8" staff="9" tstamp="1.5" tstamp2="1m+3.5">unis:</cpMark> -<cpMark dis="8" dis.place="below" origin.staff="8" staff="9" tstamp="2" tstamp2="2m+3.5">in 8va</cpMark> -
-
- A transcription of the example above with all shorthand resolved and colored - -
-

-

Text used as a copy mark, like the letters in the Weber example, may be encoded as content of the cpMark element. In the case of non-text marks, the altsym and facs attributes may be used to refer to a graphical surrogate.

-

Depending on the purpose of the encoding, the omitted parts in the score may be filled with space and mSpace elements of appropriate duration or silently overwritten with the content that the cpMark identifies. Also, these two options may be combined through the use a choice element whose abbr and expan children explicitly encode a transcription of the original ‘gap’ (in abbr) and the result of the insertion of the indicated material (in expan, see ).

-
-
-
- Apparent Errors -

When the source material to be encoded is manifestly faulty, an encoder or transcriber may elect simply to correct it without comment, although for scholarly purposes it will often be more generally useful to record both the correction and the original state of the text. The elements described here enable all three approaches, and allows the last to be done in a way that makes it easy for software to present either the original or the correction.

-

- - - - -

-

The following examples show alternative treatment of the same material. The text to be encoded contains a chord (c4, e4, g4, a4), where c4, e4, and a4 are quarter notes, but g4 is incorrectly written as a half note.

-

An encoder may choose to silently correct the engraver’s error:

-

-

- - <chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <note dur="4" oct="4" pname="g"/> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

or the correction may be made explicit:

-

-

- - <chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <corr> - <note dur="4" oct="4" pname="g"/> - </corr> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

Alternatively, the encoder may simply record the typographic error without correcting it, either without comment or with a sic element to indicate the error is not a transcription error in the encoding:

-

-

- - <chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <sic> - <note dur="2" oct="4" pname="g"/> - </sic> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

If the encoder elects to record the original source text and provide a correction for the sake of transparency, both sic and corr may be used, wrapped in a choice element. The order of the sic and corr elements is not significant:

-

-

- - <chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <choice> - <sic> - <note dur="2" oct="4" pname="g"/> - </sic> - <corr> - <note dur="4" oct="4" pname="g"/> - </corr> - </choice> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

An indication of the person or agency responsible for the emendation can be provided as follows:

-

-

- - -<!-- within the header for this document: --> -<respStmt> - <name role="editor" xml:id="editTrans.JK">Johannes Kepper</name> -</respStmt> -<!-- … --> -<chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <choice> - <sic> - <note dur="2" oct="4" pname="g"/> - </sic> - <corr resp="#editTrans.JK"> - <note dur="4" oct="4" pname="g"/> - </corr> - </choice> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

Here the resp attribute has been used to indicate responsibility for the correction. Its value (#editTrans.JK) is an example of the pointer values discussed in section . In this case, the resp attribute points to a name element within the metadata header, but any element might be indicated in this way, if the correction has been taken from some other source. The resp attribute is available for all elements which are members of the att.common class (through att.responsibility). The att.edit class makes available a cert attribute (through att.evidence), which may be used to indicate the degree of editorial confidence in a particular correction, as in the following example:

-

-

- - <chord> - <note dur="4" oct="4" pname="c"/> - <note dur="4" oct="4" pname="e"/> - <choice> - <sic> - <note dur="2" oct="4" pname="g"/> - </sic> - <corr cert="high"> - <note dur="4" oct="4" pname="g"/> - </corr> - </choice> - <note dur="4" oct="4" pname="a"/> -</chord> - -
-

-

Where, as here, the correction takes the form of amending information present in the text being encoded, the encoder should use the corr element. Where the correction is present in the text being encoded, and consists of some combination of visible additions and deletions, the elements add and / or del should be used. For additional information on the use of add and del, see section . Where the correction takes the form of an addition of material not present in the original because of physical damage or illegibility, the supplied element may be used. Where the ‘correction’ is simply a matter of expanding abbreviated notation, the expan element may be used.

-
-
- Regularization and Normalization -

When the musical source makes extensive use of unusual symbol shapes or non-standard notation features, it may be desirable for a number of reasons to regularize it; that is, provide ‘standard’ or ‘regularized’ forms that are equivalent to the non-standard forms.

-

As with other such changes to the source text, the changes may be made silently (in which case the MEI header should still specify the types of silent changes made) or may be explicitly marked using the following elements:

-

- - - - - -

-

Consider this traditional soprano clef appearing somewhere in the course of a musical piece:

-

-

- Soprano clef from the begin of Heinrich Schütz’ St. Matthew’s Passion. - -
-

-

An encoder may choose to preserve this original clef, but flag it as nonstandard from the perspective of current practice by using the orig element with no attributes specified, as follows:

-

-

- - <orig> - <clef line="1" shape="C"/> -</orig> - -
-

-

Alternatively, the encoder may indicate that the clef has been modernized into a G-clef by using the reg element with no attributes specified, as follows:

-

-

- - <reg> - <clef line="2" shape="G"/> -</reg> - -
-

-

As another alternative, the encoder may encode both the old and modernized shapes, so that applications may render both at the reader’s will:

-

-

- - <choice> - <orig> - <clef line="1" shape="C"/> - </orig> - <reg> - <clef line="2" shape="G"/> - </reg> -</choice> - -
-

-

As described above, the resp attribute may be used to specify the agent responsible for the regularization.

-
-
- Additions, Deletions, and Omissions -

The following elements are used to indicate when single notational symbols have been omitted from, added to, or marked for deletion from, a musical text. Like the other editorial elements described in this chapter, they allow for a wide range of editorial practices:

-

- - - - - - - -

-
- Omissions, Unclear Readings, Damage, and Supplied Readings -

Encoders may choose to omit parts of the source for reasons ranging from illegibility, (making transcription difficult or impossible), to editorial policy, e.g., systematic exclusion of poetry or prose from an encoding. The full details of the policy decisions concerned should be documented in the MEI header (see section ). Each place in the text at which omission has taken place should be marked with a gap element, optionally with further information about the reason for the omission, its extent, and the person or agency responsible for it, as in the following examples:

-

-

- - <gap extent="2" reason="illegible" unit="quarter_note"/> - -
-
- - <gap extent="several notes" reason="overwriting illegible"/> - -
-

-

Note that the extent of the gap may be marked precisely using attributes unit and extent.

-

Unlike TEI, MEI does not offer a desc element for further description of the reason for a gap. Instead, an annot may refer to the gap via its startid, endid, or plist attributes and provide additional information.

-

The unclear element is used to mark passages in the original which cannot be read with confidence, or about which the transcriber is uncertain for other reasons, as for example when transcribing an illegible source. Its reason and resp attributes are used, as with the gap element, to indicate the cause of uncertainty and the person responsible for the conjectured reading.

-

-

- - <note dur="4" oct="4" pname="c"> - <unclear reason="ink blot"> - <artic artic="acc"/> - </unclear> -</note> - -
-

-

Where the difficulty in transcription arises from an identifiable cause, the agent attribute signifies the causative agent. The cert attribute signifies the degree of certainty ascribed to the transcription of the text contained within the unclear element. Where the difficulty in transcription arises from action (partial deletion, etc.) assignable to an identifiable hand, the hand attribute may record the hand responsible for the action.

-

When the reason for a gap in the encoding is damage of the document carrier (the paper on which the document is written, for example), the damage element should be used instead of the gap element. In the case of damage resulting from an identifiable cause, the agent attribute signifies the causative agent. The degree attribute signifies the degree of damage according to a convenient scale. A damage tag with this attribute should only be used where the text may be read with some confidence; data supplied from other sources should be tagged as supplied. The extent attribute indicates approximately how much text is in the damaged area, in notes, measures, inches, or any appropriate unit, where this cannot be deduced from the contents of the tag. For example, the damage may span structural divisions in the text so that the tag must then be empty of content. In the case of damage (deliberate defacement, etc.) assignable to an identifiable hand, the hand attribute signifies the hand responsible for the damage.

-

Sometimes the editor provides information not present in the source material. These conjectures or emendations are marked up in MEI using the supplied element.

-

The following example demonstrates the use of the supplied element in combination with gap within subst:

-

-

- - <beam> - <note dur="4" oct="3" pname="c"/> - <note dur="4" oct="3" pname="d"/> - <subst> - <gap extent="two eighth notes" reason="missing notes"/> - <supplied> - <note dur="4" oct="3" pname="e"/> - <note dur="4" oct="3" pname="f"/> - </supplied> - </subst> - <note dur="4" oct="3" pname="g"/> - <note dur="4" oct="3" pname="a"/> -</beam> - -
-

-

When the presumed loss of text arises from an identifiable cause, agent signifies the causative agent. When the presumed loss of text arises from action (partial deletion, etc.) assignable to an identifiable hand, the hand attribute signifies the hand responsible for the action. The reason attribute indicates why the text has to be supplied, e.g., 'overbinding', 'faded ink', 'lost folio', 'omitted in original', etc. The source attribute contains the source of the supplied text. The editor(s) responsible for supplied material may be recorded in the resp attribute. The value of resp must point to one or more identifiers declared in the document header. The cert attribute signifies the degree of certainty ascribed to the supplied material.

-
-
- Visual appearance of editorial decisions -

Material added by the editors is often highlighted in the sheet music, either by brackets or small print. In addition to the semantic markup by elements like supplied, the visual appearance can be encoded using the attributes enclose and fontsize, which are available on many elements.

-

-

- Different appearances of editorial articulation - -
-

-

-

- - <supplied> - <artic enclose="paren" artic="acc" place="above" /> -</supplied> - -
-

-

-

- - <supplied> - <artic fontsize="small" artic="acc" place="above" /> -</supplied> - -
-

-
-
- Additions and Deletions -

The add and del elements may be used to record where material has been added or deleted in the source material.

-

The following example demonstrates the usage of add to mark up a note being added to an existing chord:

-

-

- - <chord> - <note pname="c"/> - <note pname="e"/> - <note pname="g"/> - <add> - <note accid="f" pname="b"/> - </add> -</chord> - -
-

-

The next example shows how del may be used to capture the information that two measures have been cancelled. As seen in this example, the rend attribute is used to specify the method of deletion.

-

-

- - <section> - <measure> - <!-- … --> - </measure> - <measure> - <!-- … --> - </measure> - <del rend="strike"> - <measure> - <!-- … --> - </measure> - <measure> - <!-- … --> - </measure> - </del> - <measure> - <!-- … --> - </measure> -</section> - -
-

-

Additional information for both elements may be specified using attributes. Whereas the hand attribute marks responsibility for the textual change, the resp attribute is used to refer to the editor who identified this textual change as such. The cert attribute signifies the degree of certainty ascribed to the identification of the hand of the deletion or addition.

-

The add element should not be used to mark editorial changes, such as supplying a note omitted by mistake from the source text or a passage present in another source. In these cases, either the corr or supplied tags should be used instead.

-
-
- Substitutions, Restorations, and Handshifts -

When several interventions to the musical text are to be regarded as a single action, they may be grouped using the subst element. The most common combination is a replacement of portions of the musical text using both the add and del element, as seen in the following example:

-

-

- - <layer> - <!-- preceding content --> - <subst> - <del> - <note dur="4" oct="4" pname="c"/> - </del> - <add> - <beam> - <note dur="8" oct="4" pname="c"/> - <note dur="8" oct="4" pname="d"/> - </beam> - </add> - </subst> - <!-- subsequent content --> -</layer> - -
-

-

An intervention closely related to substitution is the restoration of a previously deleted section. For this purpose MEI offers the restore element, which may contain a del or other content directly.

-

The following example illustrates an instance where a lyric was cancelled and later restored by overwriting it:

-

-

- - <note dur="4" oct="4" pname="c"> - <syl> - <restore desc="overwritten"> - <del>God</del> - </restore> - </syl> -</note> - -
-

-

The desc attribute gives a prose description of the means of restoration. The cert attribute signifies the degree of certainty ascribed to the identification of the hand of the restoration. The type attribute may be used to indicate the action cancelled by the restoration. The resp attribute contains an ID reference to an element containing the name of the editor or transcriber responsible for identifying the hand of the restoration. The hand attribute signifies the hand of the agent which made the restoration.

-

MEI offers a handShift milestone element that can be used to mark a change of scribe or scribal style.

-

The character attribute describes characteristics of the hand, particularly those related to the quality of the writing, e.g., 'shaky', 'thick', regular'. A description of the tint or type of ink, e.g., 'brown' or the writing medium, e.g., 'pencil', may be placed in the medium attribute.

-

-

- - <layer> - <note pname="f"/> - <note pname="a"/> - <handShift medium="blue ink"/> - <note pname="c"/> - <note pname="e"/> -</layer> - -
-

-

The new hand may be identified using the new attribute, while the previous hand may be recorded in the old attribute. The resp attribute contains an ID reference to an element containing the name of the editor or transcriber responsible for identifying the change of hand. The cert attribute signifies the degree of certainty ascribed to the identification of the new hand.

-

When using this element within a layer, it is important to ensure that all layers and staves are considered. Every handShift affects only the content of its own layer and staff, even in the following measures. Therefore, there must be a separate handShift for every staff and layer. This mechanism allows the description of shifts at timestamps that differ between each staff.

-
-
-
-
- Genetic Markup -

Genetic editions try to trace the creation of a (musical) work in all its recorded details, from the first sketches to the ‘final’ complete text. The aim of genetic textual criticism is to investigate compositional working and thinking processes - the genesis of compositions. In contrast to traditional scholarly editions, which focus on the constitution of a performable text of a work, Genetic Textual Criticism focuses on the process of production, the gradual elaboration of musical thoughts while writing. It is dependent on the availability of comprehensible traces of these writing processes. Genetic editions often have to deal with significant uncertainties, and they require a considerable amount of markup, as detailed below.

-
- Encoding Genetic States -

Leaving aside temporary breaks, a compositional process is continuous: the composer’s writing operations have happened in a strict order, which could be specified if his working would have been filmed. However, this exact order is rarely ever recoverable from the surviving manuscripts, prints or other materials. Instead, relative statements can be made – the red pencil must have been written after the brown ink etc. Instead of a continuous movie, scholars are often only able to reconstruct a slide show, reflecting certain recoverable states of the composition. Very often, those states have a local range only – the order of two states on one page may be known, as is the order of two other states on a second page. This doesn't necessarily allow to identify the succession of all four states.

-

MEI utilizes the genDesc element to describe the recoverable genetic states of a work. It is nested inside music and may contain a number of genState elements.

-

- - - - -

-

A genetic description is used to bundle all known states of a work. The ordered attribute may be used to specify whether the order of child elements of the genDesc matches their temporal order, or if their temporal order is unknown. As genDesc may be self-nested, it is possible to specify the order of some states within a larger unordered set of genetic states, or to position a set of states with unknown temporal order in a larger ordered set.

-

-

- - <genDesc ordered="false"> - <genState label="State A"/> - <genState label="State B"/> - <genDesc ordered="true"> - <genState label="State C1"/> - <genState label="State C2"/> - <genState label="State C3"/> - </genDesc> -</genDesc> - -
-

-

In the above example, the temporal relation of states A, B and all of C is not known, but it is known that C1 precedes C2 and C3.

-

Even when the temporal order of a set of states is not fully recoverable, some arguments about relative chronology may be available. It is possible to encode these statements with the precision the editor feels comfortable with, utilizing the attributes next and prev (for immediate successors / predecessors), and precedes and follows (for relative successors / predecessors).

-

Genetic states can be further described by using any combination of the desc, date, and respStmt children of genState.

-
-
- Referencing Genetic States -

While the (relative) chronology of genetic states may be encoded using the genDesc element (see ), the textual operations they manifest in are encoded using the regular add, del, etc. elements are used (see ). However, for a genetic edition these elements are linked to their corresponding genState element using the state attribute.

-

-

- - <!-- definition of a state within genDesc --> -<genState xml:id="genetic.stateX"/> - -<!-- somewhere later in the musical text: --> -<subst state="#genetic.stateX"> - <del> - <clef shape="C" line="1"/> - </del> - <add> - <clef shape="G" line="2"/> - </add> -</subst> - -
-

-

In the example above, state X of the encoded work is established by the change from a C clef to a G clef. Other states preceding state X will read a C clef, while state X and succeeding states read a G clef. A genetic state of the work is constituted by performing all textual operations referencing that state, i.e., by carrying out all additions, deletions and restorations.

-

The instant attribute on del etc. allows to specify that corresponding modification has been carried out immediately after writing the original text, so that no separate genetic state has been established.

-

It is up to encoder to identify the appropriate level of granularity: In an ideal world, the writing or cancellation of a single note would constitute a new state. In practice, this level of detail isn't feasible, and the combination of multiple writing operations into larger logical operations seems inevitable. However, this may range from very large tasks (‘replacing the second movement of a symphony’) to very small ones (‘adding the slurs for the viola in measures 22 and 23’), depending on the intentions and scope of the encoding.

-
-
- Encoding Metatexts -

The arguments used to establish a chronological order of genetic states are sometimes found in external sources like letters, but very often they are to be found in the witnesses holding the musical text, even though they are typically not part of the text itself. Examples for such arguments are the writing medium, spacing, marginal notes, among others.

-

Some of these so-called ‘metatexts’ can be encoded using MEI, namely those that are written into the relevant sources. For this purpose, MEI offers the metaMark element, as known from the TEI.

-

- - - -

-

A metaMark is provided as a ‘controlEvent’ (see ); as such, by convention, it should be encoded at the end of the measure where it first occurs. It is highly recommended to specify the function of the metaMark using its function attribute, which may take the following values:

- - - confirmation: confirmation of a previous textual decision; i.e., cancellation of a deleted passage in a different writing medium. - - addition: denoted material is to be inserted in the musical text. - - deletion: denoted material is no longer part of the musical text. - - substitution: denoted material is replaced, either by the musical text pointed at with the target attribute or the musical content of the metaMark element itself. - - clarification: attempt to clarify a potentially illegible or otherwise unclear part of the musical text. - - question: marks a section of the musical text which is to be considered further. - - investigation: marks a section of the musical text as an investigation of the consequences of certain compositional decisions or potential alternatives. - - restoration: declares a formerly cancelled part of the musical text as valid again. - - navigation: clarification of the reading order of the musical text. - -

Some metaMarks may have actual content, like marginal notes. This content may be transcribed inside the metaMark element. It also has a facs attribute to refer back to the corresponding sections of a facsimile.

-

It is important to keep in mind that metaMark elements do not encode the textual consequences they transport – this is an encoding of the sign, not of its meaning, which can be encoded in other elements like restore.

-

-

- metaMarks in Beethoven’s op.59.3, p.18 - -
-

-

The above excerpt from a Beethoven manuscript holds a number of different metaMarks, some of which are encoded in the following examples:

-

-

- - <metaMark staff="1" place="below" function="restoration">gut</metaMark> - -
-

-

The metaMark above captures the word ‘gut’ (good) Beethoven wrote below the red pencil, which indicates that the formerly deleted text of the two measures shown shall be kept.

-

-

- - <metaMark function="clarification"> - Nb: diese<lb/>Zwei Täkte<lb/>sind gut, und<lb/>bleiben -</metaMark> - -
-

-

This metaMark transcribes Beethoven’s marginal note explaining the same situation as above.

-

-

- - <metaMark staff="3" place="above" tstamp="4" function="clarification">g</metaMark> - -
-

-

This third metaMark covers one of the letters Beethoven inserted to clarify the pitch of that given note.

-
-
- Genetic Changes at the Page Level -

In genetic editions, it may also be of interest to trace when pages are added and / or removed from manuscripts. The general information about pages can be encoded using the foliaDesc element, as described in . It is possible to wrap the elements used there, including patch and cutout with editorial markup like add and del. These elements can then be used to reference genState as described in .

-
-
-
-
- Facsimiles and Recordings -

MEI can be used to connect an encoding of some sort – either a transcription of existing material, or the specification of some expected output in some form – with existing sources. This existing material may be in different formats – music notation in any combination of print and manuscript, or audio or video footage. The concepts for establishing such connections between encoded music and source material is described in the following chapters.

-
- Facsimiles -

Most often, MEI is used for the preparation of a digital musical text based on an existing music document, or with the intention of rendering the encoded notation into a document or audio rendition. MEI can, however, be used to provide a different kind of digital reproduction of a source document, which relies on the description and provision of digital imagery. Both approaches may be combined, so that the encoding of the musical content and digital facsimiles may add different facets to the same MEI document.

-
- Elements of the Facsimile Module -

This module makes available the following elements for encoding facsimiles:

-

- - - - - -

-

These element are used to add a separate subtree to MEI, starting with the facsimile element inside music, as seen in the following example:

-

-

- - <mei> - <meiHead> - <!-- metadata header --> - </meiHead> - <music> - <facsimile> - <!-- The facsimile subtree starts here. --> - </facsimile> - <body> - <!-- The encoding of the musical content goes here. --> - </body> - </music> -</mei> - -
-

-

It is possible to have more than one facsimile element in this location. This is especially useful when multiple sources are encoded in the same file using the mechanisms described in chapter of these Guidelines. In this case, the decls (declarations) attribute of facsimile may be used to refer to a source defined in the document’s header, as seen in the following example:

-

-

- - <mei> - <meiHead> - <fileDesc> - <sourceDesc> - <source xml:id="facsimile.source1"> - <!-- description of source --> - </source> - </sourceDesc> - </fileDesc> - </meiHead> - <music> - <facsimile decls="#facsimile.source1"> - <!-- facsimile content --> - </facsimile> - </music> -</mei> - -
-

-

When using the FRBR model (see ), it is equally possible to reference a manifestation element instead of source.

-

Within a facsimile element, each page of the source is represented by a surface element. Each surface may be assigned an identifying string utilizing the label attribute. In addition, it may encapsulate more detailed metadata about itself in a figDesc element. The coordinate space of the surface may be recorded in abstract terms in the ulx, uly, lrx, and lry attributes. For navigation purposes, surface has a startid attribute that accommodates pointing to the first object appearing on this particular writing surface.

-

-

- - <facsimile> - <surface label="page 1" - lrx="2000" - lry="3000" - startid="#measure1" - ulx="0" - uly="0"/> -</facsimile> - -
-

-

Within surface elements, one may nest one or more graphic elements, each providing a reference to an image file that represents the writing surface. Multiple graphic elements are permitted in order to accommodate alternative versions (different resolutions or formats, for instance) of the surface image. In spite of changes in resolution or format, all images must contain the same content, i.e., the entire writing surface. A graphic may refer to a single page within a multi-page document, which is – at least for Adobe PDF documents – available through a #page=X suffix to the target attribute.

-

-

- - <facsimile> - <surface> - <graphic height="2000px" target="image1.jpg" width="3000px"/> - <graphic height="1000px" target="image1smaller.jpg" width="1500px"/> - <graphic height="200px" target="image1smallest.png" width="300px"/> - </surface> -</facsimile> -<facsimile> - <surface> - <graphic height="297mm" target="source1.pdf#page=1" width="210mm"/> - </surface> - <surface> - <graphic height="297mm" target="source1.pdf#page=2" width="210mm"/> - </surface> -</facsimile> - -
-

-

The preceding markup will provide the basis for most page-turning applications. Often, however, it is desirable to focus attention on particular areas of the graphical representation of the surface. The zone element fulfills this purpose:

-

-

- - <surface lrx="3000" lry="2000" ulx="0" uly="0"> - <graphic height="2000px" target="image1.jpg" width="3000px"/> - <zone lrx="370" lry="410" ulx="300" uly="200"/> - <zone lrx="439" lry="410" ulx="367" uly="200"/> - <zone lrx="512" lry="410" ulx="436" uly="200"/> -</surface> - -
-

-

The coordinates of each zone define a space relative to the coordinate space of its parent surface. Note that this is not necessarily the same coordinate space defined by the width and height attributes of the graphic that represents the surface. The zone coordinates in the preceding example do not represent regions within the graphic, but rather regions of the writing surface.

-

Because the coordinate space of a zone is defined relative to that of a surface, it is possible to provide multiple graphic elements and multiple zone elements within a single surface. In the following example, two different images representing the entire surface are provided alongside specification of two zones of interest within the surface:

-

-

- - <surface lrx="3000" lry="2000" ulx="0" uly="0"> - <graphic height="2000px" target="image1.jpg" width="3000px"/> - <graphic height="1995px" target="image1cropped.jpg" width="2995px"/> - <zone lrx="370" lry="410" ulx="300" uly="200"/> - <zone lrx="30" lry="30" ulx="0" uly="0"/> -</surface> - -
-

-

A zone element may contain figDesc or graphic elements that provide detailed descriptive information about the zone and additional images, e.g., at a different/higher resolution, of the rectangle defined by the zone. The data objects contained within the zone may also be specified through the use of the data attribute, which contains ID references to one more elements in the content tree of the MEI file, such as a note, measure, etc.

-

-

- - -<!-- In the facsimile subtree: --> -<zone data="#facsimile.measure1" xml:id="facsimile.zone1"/> - -<!-- somewhere in the content: --> -<measure xml:id="facsimile.measure1"> - <!-- measure content --> -</measure> - -
-

-

Conversely, an element in the content may refer to the facsimile subtree using its facs attribute, which is made available by the att.facsimile attribute class. The last example could therefore be encoded with pointers in the other direction:

-

-

- - -<!-- In the facsimile subtree: --> -<zone xml:id="facsimile.zone2"/> - -<!-- somewhere in the content: --> -<measure facs="#facsimile.zone2" xml:id="facsimile.measure2"> - <!-- measure content --> -</measure> - -
-

-

The pb element defined in the makes special use of the facs attribute, in that it does not point to a zone, but a surface element instead. A pb marks the beginning of a page, so it can be concluded that all elements in the content tree which are encoded between any two pb elements encode musical symbols written on the page (surface) referenced by the first of these two pb element’s facs attribute.

-

The encoding of facsimile elements is intended to support sequential display of page images. If an encoder wants to describe the physical setup of a source document, the foliaDesc element is more appropriate. The difference of both approaches, and how to combine them, is described in chapter .

-
-
-
- Performances -

This chapter describes the ‘performance’ module, which can be used for organizing audio and video files of performances of a musical work. The elements provided allow the encoder to group different recordings of the same performance, identify temporal segments within the recordings, and encode simple alignments with a music text.

-
- Overview -

The following elements are available to encode information about a recorded performance:

-

- - - - - - - -

-

The performance element begins a subtree of the music element and appears alongside with, or instead of, body (described in ) and facsimile (described in ). A performance element represents one recorded performance event. As a performance may be recorded in multiple formats or by different personnel or using different equipment, the performance element may group one or more recordings of the event.

-

The decls attribute can be used to point to performance medium metadata for the performed work. See and for more details.

-

The recording element identifies a single recording event taking place within an absolute temporal space. The class att.mediaBounds contains attributes that can be used to define this space:

-

- - - -

-

The avFile element identifies an external file associated with a recording act. In the simplest case, the recording element will contain one avFile element identifying a file that represents it. The target attribute contains the URI of the digital media file. Use of the mimetype attribute is recommended for the avFile element. Its value should be a valid MIME media type defined by the Internet Engineering Task Force in RFC 2046. It is also recommended that all avFile elements have a recording or clip parent which bears the begin, end, and betype attributes.

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:03:10.00"> - <avFile mimetype="audio/wav" - target="http://example.com/path/to/audio/recording"/> - </recording> -</performance> - -
-

-

Sometimes, multiple digital files are created in order to provide greater flexibility in redistribution and playback capabilities. In this case, multiple avFile elements may occur, each with a different mimetype. Keep in mind, however, that each file still represents the complete temporal extent of the recording act in spite of the change of file format:

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:03:10.00"> - <avFile mimetype="audio/wav" - target="http://example.com/path/to/audio/recording/wav"/> - <avFile mimetype="audio/mpeg" - target="http://example.com/path/to/audio/recording/mpeg"/> - </recording> -</performance> - -
-

-

The clip element identifies a temporal segment of a recording act. In the following example, the clip begins two minutes into the timeframe of the recording and ends 20 seconds later:

-

-

- - <recording begin="00:00:00.00" betype="time" end="00:03:10.00"> - <clip begin="00:02:00.00" betype="time" end="00:20:20.00"/> -</recording> - -
-

-

Beyond these relatively simple uses, complex situations may occur that require equally complex markup. For example, a single performance may be represented by multiple digital media files. Because they have differing durations, the media files must be the result of separate recording acts, even if these recording acts took place at the same time:

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:03:10.00"> - <avFile mimetype="audio/wav" - target="http://example.com/path/to/audio/recording/wav"/> - </recording> - <recording begin="00:00:00.00" betype="time" end="00:03:15.00"> - <avFile mimetype="audio/mpeg" - target="http://example.com/path/to/audio/recording/mpg"/> - </recording> -</performance> - -
-

-

A single performance may also be represented by multiple, sequential digital files, as when a complete work is recorded in several so-called ‘takes’. In this case, the files may be considered to be parts of a single recording act, the extent of which is the combined extent of the individual clips. For example, a series of clip elements may be used to identify each movement of a piece and give start and end times for the movements in relation to the overall temporal space of the complete work:

-

-

- - <performance> - <recording> - <clip begin="00:00:00.00" betype="time" end="00:07:00.00" n="mov1"> - <avFile mimetype="audio/aiff" target="movement01.aiff"/> - </clip> - <clip begin="00:07:01.00" betype="time" end="00:12:03.00" n="mov2"> - <avFile mimetype="audio/aiff" target="movement02.aiff"/> - </clip> - </recording> -</performance> - -
-

-

Similar markup is also applicable when a single file representing the entirety of a recording act is broken into segments later, as is often done for practical storage and distribution reasons. The file from which the clips are derived is indicated using an avFile element:

-

-

- - <performance> - <recording begin="00:00:00.00" - betype="time" - end="00:12:03.00" - n="completeWork"> - <avFile mimetype="audio/aiff" target="completeWork.aiff"/> - <clip begin="00:00:00.00" betype="time" end="00:07:00.00" n="mov1"> - <avFile mimetype="audio/aiff" target="movement01.aiff"/> - </clip> - <clip begin="00:07:02.00" betype="time" end="00:12:03.00" n="mov2"> - <avFile mimetype="audio/aiff" target="movement02.aiff"/> - </clip> - </recording> -</performance> - -
-

-

A clip may be used to define any region of interest, such as a cadenza or a modulation, a song verse, etc. The following example shows the use of clip and its attributes to identify significant sections of a recording:

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:05:21.00"> - <!-- Exposition --> - <clip begin="00:00:00.00" betype="time" end="00:01:41.00"/> - <!-- Development --> - <clip begin="00:01:41.00" betype="time" end="00:03:14.00"/> - <!-- Recapitulation --> - <clip begin="00:03:14.00" betype="time" end="00:04:28.00"/> - <!-- Coda --> - <clip begin="00:04:28.00" betype="time" end="00:05:21.00"/> - </recording> -</performance> - -
-

-

The preceding example also demonstrates that media files are not required in order to define the temporal space of a recording act or clip. This makes it possible to set the boundaries of these features, then use the content of the performance element as a rudimentary "edit decision list" to create the matching digital files.

-

If an encoding of the notated text with which the media files are associated is included in the MEI file, the startid attribute can be used to indicate the first element in the sequence of events to which the recording corresponds:

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:07:00.00" n="mov1" startid="#performance.m1_1"> - <avFile mimetype="audio/aiff" target="fullpiece.aiff"/> - </recording> -</performance> -<!-- ... --> -<body> - <mdiv> - <score> - <section> - <measure n="1" xml:id="performance.m1_1"> - <!-- ... --> - </measure> - </section> - </score> - </mdiv> -</body> - -
-

-

Clips can also be aligned with components of the musical text encoded in the body. The startid attribute can be used to specify the starting element in the sequence of events to which the clip corresponds. The following example shows the use of clip elements to identify the exposition of the first movement from Beethoven’s piano sonata Op. 14, no. 2 and its concluding ‘codetta’.

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:05:21.00"> - <avFile mimetype="audio/aiff" target="BeethovenOp14N2-Mov1.aiff"/> - <!-- Exposition --> - <clip begin="00:00:0.00" betype="time" end="00:01:41.00" startid="#performance.m1"/> - <!-- Exposition's "codetta" --> - <clip begin="00:01:31.00" betype="time" end="00:01:41.00" startid="#performance.m48"/> - </recording> -</performance> -<!-- ... --> -<body> - <mdiv> - <score> - <section> - <measure n="1" xml:id="performance.m1"> - <!-- ... --> - </measure> - <!-- ... --> - <measure n="48" xml:id="performance.m48"> - <!-- ... --> - </measure> - </section> - </score> - </mdiv> -</body> - -
-

-

Please note that the begin and end times of clips may overlap. In the preceding example, the extent of the codetta is contained within that of the exposition. Overlapping beginning and ending points may also be used to provide additional performance context for a segment or because there is uncertainty with regard to precise values for these points.

-

-

- - <performance> - <recording begin="00:00:00.00" betype="time" end="00:03:06.54"> - <!-- a section of interest --> - <clip begin="00:00:00.00" betype="time" end="00:00:41.00"/> - <!-- the following section starts a little before the end of the - previous one to give some "adjustment" time --> - <clip begin="00:00:31.00" betype="time" end="00:01:07.00"/> - <!-- the boundaries of the following section are "fuzzy" --> - <clip begin="00:02:18.00" betype="time" end="00:02:49.85"/> - </recording> -</performance> - -
-

-

A bibliographic description of a recording or metadata explaining how clip boundaries were determined may be associated with the recording and clip elements via the decls attribute:

-

-

- - <performance> - <recording begin="00:00:00.00" - betype="time" - decls="#performance.recBibDesc" - end="00:03:06.54"> - <!-- a section of interest --> - <clip begin="00:00:00.00" betype="time" end="00:00:41.00"/> - <!-- the following section starts a little before the end of the - previous one to give some "adjustment" time --> - <clip begin="00:00:31.00" - betype="time" - decls="#performance.clipDesc" - end="00:01:07.00"/> - <!-- the boundaries of the following section are "fuzzy" --> - <clip begin="00:02:18.00" betype="time" end="00:02:49.85"/> - </recording> -</performance> - -
-

-

Associations between a feature of the encoding, such as a note, dynamic mark, or annotation, and a time point, may be created using when elements and when attributes.

-

The when element identifies a particular point in time during the playback of a media file, such as an audio recording.

-

-

- - <when absolute="00:00:01.915291666" abstype="time" xml:id="t1"/> - -
-

-

Time points may be identified in absolute terms as above; that is, in hours, minutes, and seconds since the beginning of the recording, or in relative terms using the interval, inttype, and since attributes. In the following example, the time point of interest happens 48 frames after the occurrence of the point labelled as "t1".

-

-

- - <when interval="48" - inttype="smpte-ndf29.97" - since="#t1" - xml:id="t1.1"/> - -
-

-

Having identified a point of interest, another feature of the encoding may be associated with this point using its when attribute:

-

-

- - <annot resp="#LvB" when="#t1"> - <p>I like this part!</p> -</annot> - -
-

-

One use of the association created between the annotation and the time point is to display the text of the annotation as the recording or clip is played.

-

The when attributes allows only a single value, so only one-to-one relationships can be created using this mechanism. However, one-to-many relationships are accommodated in the opposite direction; that is, from a time point to other features of the markup. For example,

-

-

- - <when xml:id="t1.2" - absolute="00:00:01.915291666" - abstype="time" - data="#feature1 #feature2 #feature3"/> - -
-

-

indicates that the entities identified in data all occur at the same instant.

-

extData is a container for holding non-MEI data formats, similar to extMeta but available in when rather than in meiHead. extData allows for data from audio or other sources to be linked to notes or other score events. Data should be enclosed in a CDATA tag.

-

The following example shows JSON formatted performance data encoded with extMeta for a single note (presumed to be defined elsewhere in the document as with the ID "note_1"). Both single-value summaries (e.g., pitch) and time series values (e.g., contF0) are encoded.

-

-

- - <when absolute="00:00:00.00" xml:id="when_1" data="#note_1"> - <extData> - &lt;![CDATA[ - {"offset": "00:00:02.9005", - "pitch": "455.98", - "contF0": [454.3737606, 454.7165531, 455.2337513, 455.4622624, 456.0605954]} - ]]&gt; - </extData> -</when> -
-

-
-
-
-
- Linking Data -

This chapter describes the use of elements in MEI for linking and referencing. This includes the elements, models, and attributes that are part of the 'MEI.ptrref' module. This module contains declarations, techniques and approaches to establish references within a single MEI document, or to link out from one MEI document to another or to other external sources. This chapter also addresses possibilities to link into an MEI document from external sources which makes MEI highly interoperable and serviceable in the context of Linked (Open) Data approaches.

-
- Links -

An element is a ‘link’ when it has an attribute whose value is a reference to the ID of one or more other elements (cross-reference). These link elements indicate an association between themselves (or one of their ancestors) and one or more other entities, either inside the same document or elsewhere. An association between two elements in the same document is said to be an ‘internal’ link, while an association that involves an entity outside the current document is called an ‘external’ link. However, either of the elements discussed in the following section can be used for either purpose.

-
- General Relationships Between Elements -

MEI offers several attributes in the att.linking class for the description of basic relationships:

-

- - - -

-

The att.alignment class contains an attribute for describing temporal relationships:

-

- - - -

-

The att.dataPointing class provides an attribute for pointing from the header into the music content:

-

- - - -

-

To reference images, the att.facsimile class provides an attribute for pointing to surface and zone elements:

-

- - - -

- -

These attributes accommodate the encoding of linkages between the element carrying the attribute and one or more other elements. All of them use URIs to establish the connection. While the examples below illustrate relationships between musical events, the use of the aforementioned attributes is not restricted to musical events. On the contrary, these attributes can be used to capture information about relations between any elements.

-

Using the attributes above makes it possible to create relationships between events, which are often widely-spaced in both encoded order and time. The attributes allow a large number of connections, enhancing the informational content, and therefore the potential usefulness, of the encoding.

-

The copyof attribute points to an element of which the current element is a copy. It can be used to repeat a note, for example, without encoding the whole note element again. The copy is a ‘deep’ one; that is, the copyof attribute copies all attributes and child elements which belong to the copied element, such as the dur and oct attributes of a copied note. The value of the copyof attribute must be a URI, which usually refers to an element in the current document. The following example demonstrates use of the copyof attribute:

-

-

- - <section> - <measure n="1"> - <staff n="1"> - <layer> - <note xml:id="analysis.note1_1" dur="4" oct="4" pname="g"/> - </layer> - </staff> - </measure> - <measure n="2"> - <staff n="1"> - <layer> - <note copyof="#analysis.note1_1"/> - </layer> - </staff> - </measure> -</section> - -
-

-

In this example, the note in the second measure has exactly the same characteristics as the note in the first measure.

-

Using copyof is not limited to copying events. The copyof attribute can also be used to copy an entire measure or staff. When there are many repeated features, the use of the copyof greatly reduces encoding effort. The image and the following encoding of the beginning of Schubert’s Erlkönig illustrates the benefit of using the copyof attribute.

-

-

- First measure of Schubert’s Erlkönig - -
-
- - <measure> - <staff n="1"> - <layer> - <tuplet num="3" num.visible="true" xml:id="analysis.tup1"> - <chord dur="8"> - <note oct="3" pname="g"/> - <note oct="4" pname="g"/> - </chord> - <chord dur="8"> - <note oct="3" pname="g"/> - <note oct="4" pname="g"/> - </chord> - <chord dur="8"> - <note oct="3" pname="g"/> - <note oct="4" pname="g"/> - </chord> - </tuplet> - <tuplet copyof="#analysis.tup1" xml:id="analysis.tup2"/> - <tuplet copyof="#analysis.tup1" xml:id="analysis.tup3"/> - <tuplet copyof="#analysis.tup1" xml:id="analysis.tup4"/> - </layer> - </staff> -</measure> - -
-

-

This example can be reduced further by using copyof inside the initial tuplet to represent the repeated chords:

-

-

- - <measure> - <staff n="1"> - <layer> - <mRest/> - </layer> - </staff> - <staff n="2"> - <layer> - <tuplet num="3" num.visible="true" xml:id="analysis.tup5"> - <chord dur="8" xml:id="analysis.t1c1"> - <note oct="3" pname="g"/> - <note oct="4" pname="g"/> - </chord> - <chord copyof="#analysis.t1c1"/> - <chord copyof="#analysis.t1c1"/> - </tuplet> - <tuplet copyof="#analysis.tup5" xml:id="analysis.tup6"/> - <tuplet copyof="#analysis.tup5" xml:id="analysis.tup7"/> - <tuplet copyof="#analysis.tup5" xml:id="analysis.tup8"/> - </layer> - </staff> - <staff n="3"> - <layer> - <mRest/> - </layer> - </staff> -</measure> - -
-

-

While copyof signifies a duplicate copy of an element, the sameas indicates that the current element represents exactly the same entity as the one referenced in sameas. Use of sameas is used for describing the same entity from multiple perspectives, e.g., the same event in two layers.

-

While copyof and sameas have defined semantics, the corresp may be used to create user-defined relationships between elements. The example below demonstrates the encoding of a relationship between the third note and the fermata, even though the fermata is not placed directly above the note.

-

-

- - <measure n="1" right="end"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="c" xml:id="analysis.note1"/> - <note dur="4" oct="4" pname="d" xml:id="analysis.note2"/> - <note dur="2" oct="4" pname="e" xml:id="analysis.note3"/> - </layer> - </staff> - <fermata corresp="#analysis.note3" place="above" tstamp="4.75"/> -</measure> - -
-

-

The corresp attribute only marks the correspondence between the current element and one or more other entities. To describe the nature of the correspondence, one must use annot.

-

One possible usage of corresp is to link related editorial markup. Because of the hierarchical nature of XML it may be necessary to split related editorial markup into multiple elements. In the following example, corresp is used to encode the relationship between those elements.

-
- - <?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> -<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> -<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.1-dev"> - <meiHead> - <fileDesc> - <titleStmt> - <title>Example of attribute corresp</title> - </titleStmt> - <pubStmt> - <date isodate="2024">2024</date> - <respStmt> - <corpName>Music Encoding Initiative (MEI)</corpName> - </respStmt> - <availability> - <useRestrict label="license" auth="https://spdx.org/licenses/" codedval="ECL-2.0"> - <p>Educational Community License v2.0</p> - </useRestrict> - </availability> - </pubStmt> - <seriesStmt> - <title>MEI guidelines examples</title> - </seriesStmt> - <notesStmt> - <annot>Usage of attribute corresp with editorial markup.</annot> - </notesStmt> - </fileDesc> - </meiHead> - <music> - <body> - <mdiv> - <score xml:id="score-1286820719"> - <scoreDef xml:id="scoredef-1058976644" key.mode="major" keysig="1s" meter.count="6" meter.unit="8"> - <staffGrp xml:id="staffgrp-0664100862" bar.thru="true"> - <staffDef xml:id="staffdef-1106436456" n="1" lines="5" clef.shape="F" clef.line="4"> - <instrDef xml:id="instrdef-0137914882" midi.channel="0" midi.instrnum="0" midi.volume="68.00%" /> - </staffDef> - </staffGrp> - </scoreDef> - <section xml:id="Tema"> - <measure xml:id="measure-2058315290" n="1"> - <staff xml:id="staff-0363750297" n="1"> - <layer xml:id="layer-1609584463" n="1"> - <note xml:id="note-0434568382" dur="8" oct="3" pname="g" stem.dir="down"/> - <unclear xml:id="uu01ius1" corresp="#uvvet6x2"> - <note xml:id="note-1576381641" dur="4" oct="4" pname="d" stem.dir="down"/> - </unclear> - <note xml:id="note-0740487248" dur="8" oct="3" pname="a" stem.dir="down"/> - <note xml:id="note-2110615453" dur="4" oct="4" pname="d" stem.dir="down"/> - </layer> - </staff> - <slur xml:id="slur-0198912827" startid="#note-0434568382" endid="#note-1576381641" curvedir="above"/> - <unclear xml:id="uvvet6x2" corresp="#uu01ius1"> - <dynam xml:id="dynam-1643328657" place="below" staff="1" tstamp="2.000000" vgrp="40">sf</dynam> - </unclear> - <slur xml:id="slur-0701442771" startid="#note-0740487248" endid="#note-2110615453" curvedir="above"/> - <dynam xml:id="dynam-1610913814" place="below" staff="1" tstamp="5.000000" vgrp="40">sf</dynam> - </measure> - </section> - </score> - </mdiv> - </body> - </music> -</mei> -
-
- - <measure n="1"> - <staff n="1"> - <layer n="1"> - <note xml:id="note-0000000434568382" dur="8" oct="3" pname="g" stem.dir="down"/> - <unclear xml:id="uu01ius1" corresp="#uvvet6x2"> - <note xml:id="note-0000001576381641" dur="4" oct="4" pname="d" stem.dir="down"/> - </unclear> - <note xml:id="note-0000000740487248" dur="8" oct="3" pname="a" stem.dir="down"/> - <note xml:id="note-0000002110615453" dur="4" oct="4" pname="d" stem.dir="down"/> - </layer> - </staff> - <slur startid="#note-0000000434568382" endid="#note-0000001576381641" curvedir="above"/> - <unclear xml:id="uvvet6x2" corresp="#uu01ius1"> - <dynam place="below" staff="1">sf</dynam> - </unclear> - <slur startid="#note-0000000740487248" endid="#note-0000002110615453" curvedir="above"/> - <dynam place="below" staff="1">sf</dynam> -</measure> -
-

The next and prev attributes point to elements which follow or precede the current element in some fashion other than that indicated by encoding order. The use of these attributes helps to avoid confusion in the sequence of events, for example, in voice leading across layers or staves, when the encoding reflects the physical arrangement of voices. In the second measure of the following example, the target of the next attribute occurs after the pointing element in time, but before it in encoding order:

-

-

- Bach Chorale, Ach Gott, vom Himmel sieh' darein, m. 6-7 - -
-
- - <measure n="6" xml:id="analysis.m_sc_62"> - <staff n="1"> - <layer n="1"> - <note dur="4" oct="4" pname="g" xml:id="analysis.n_sc_63_3"/> - <note dur="4" oct="4" pname="a" xml:id="analysis.n_sc_65_3"/> - <note dur="4" fermata="above" oct="4" pname="b" xml:id="analysis.n_sc_67_3"/> - <note dur="4" oct="4" pname="g" xml:id="analysis.n_sc_68_3"/> - </layer> - <layer n="2"> - <beam> - <note dur="8" oct="4" pname="e" xml:id="analysis.n_sc_63_2"/> - <note dur="8" oct="4" pname="g" xml:id="analysis.n_sc_64_2"/> - </beam> - <beam> - <note dur="8" oct="4" pname="f" xml:id="analysis.n_sc_65_2"/> - <note dur="8" oct="4" pname="e" xml:id="analysis.n_sc_66_2"/> - </beam> - <note accid="s" dur="4" next="#analysis.n_sc_68_2" oct="4" pname="d" xml:id="analysis.n_sc_67_2"/> - <beam> - <note dur="8" oct="4" pname="e" xml:id="analysis.n_sc_68_1"/> - <note accid="n" dur="8" oct="4" pname="d" xml:id="analysis.n_sc_69_1"/> - </beam> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="4" oct="3" pname="b" xml:id="analysis.n_sc_63_1"/> - <note dur="4" oct="4" pname="c" xml:id="analysis.n_sc_65_1"/> - <note dur="4" oct="3" pname="f" xml:id="analysis.n_sc_67_1"/> - <note dur="4" oct="3" pname="b" xml:id="analysis.n_sc_68_2"/> - </layer> - <layer n="1"> - <beam> - <note dur="8" oct="3" pname="e" xml:id="n_sc_63_0"/> - <note dur="8" oct="3" pname="d" xml:id="n_sc_64_0"/> - </beam> - <note dur="4" oct="3" pname="c" xml:id="n_sc_65_0"/> - <note dur="4" fermata="below" oct="2" pname="b" xml:id="n_sc_67_0"/> - <note dur="4" oct="3" pname="e" xml:id="n_sc_68_0"/> - </layer> - </staff> -</measure> -<measure n="7" xml:id="m_sc_70"> - <staff n="1"> - <layer n="1"> - <beam> - <note dur="8" oct="4" pname="a" xml:id="analysis.n_sc_71_3"/> - <note dur="8" oct="4" pname="b" xml:id="analysis.n_sc_72_3"/> - </beam> - <note dur="4" oct="5" pname="c" xml:id="analysis.n_sc_73_3"/> - <note dur="4" oct="4" pname="b" xml:id="analysis.n_sc_75_3"/> - <beam> - <note dur="8" oct="5" pname="c" xml:id="analysis.n_sc_76_3"/> - <note dur="8" oct="4" pname="b" xml:id="analysis.n_sc_77_3"/> - </beam> - </layer> - <layer n="2"> - <space dur="4"/> - <note dur="4" oct="4" pname="a" xml:id="analysis.n_sc_73_2"/> - <note accid="s" dur="4" oct="4" pname="g" xml:id="analysis.n_sc_75_2"/> - <note dur="4" oct="4" pname="a" xml:id="analysis.n_sc_76_2"/> - </layer> - <layer n="3"> - <beam> - <note dur="8" oct="4" pname="c" xml:id="analysis.n_sc_71_1"/> - <note dur="8" oct="4" pname="d" xml:id="analysis.n_sc_72_1"/> - </beam> - <note dur="4" oct="4" pname="e" xml:id="analysis.n_sc_73_1"/> - <note dur="4" oct="4" pname="e" xml:id="analysis.n_sc_75_1"/> - <beam> - <note dur="8" oct="4" pname="e" xml:id="analysis.n_sc_76_1"/> - <note dur="8" oct="4" pname="d" xml:id="analysis.n_sc_77_1"/> - </beam> - </layer> - </staff> - <staff n="2"> - <layer n="1"> - <note dur="4" next="#analysis.n_sc_73_2" oct="3" pname="a" xml:id="analysis.n_sc_71_2"/> - </layer> - <layer n="2"> - <note accid="n" dur="4" oct="3" pname="f" xml:id="n_sc_71_0"/> - <beam> - <note dur="8" oct="3" pname="c" xml:id="n_sc_73_0"/> - <note dur="8" oct="3" pname="d" xml:id="n_sc_74_0"/> - </beam> - <note dur="4" oct="3" pname="e" xml:id="n_sc_75_0"/> - <beam> - <note dur="8" oct="2" pname="a" xml:id="n_sc_76_0"/> - <note dur="8" oct="2" pname="b" xml:id="n_sc_77_0"/> - </beam> - </layer> - </staff> -</measure> - -
-

-

This attribute may also be useful to clarify a sequence of entities which occurs across some form of interruption, in this case, notes before and after a system or page break where there is no custos or direct in the source:

-

-

- - <measure n="1"> - <staff n="1"> - <layer> - <note dur="4" - next="#analysis.m1s1e2" - oct="4" - pname="f" - stem.dir="up" - xml:id="analysis.m1s1e1"/> - <pb/> - <note dur="8" - next="#analysis.m1s1e3" - oct="3" - pname="b" - prev="#analysis.m1s1e1" - stem.dir="up" - xml:id="analysis.m1s1e2"/> - <note dur="8" - oct="4" - pname="c" - prev="#analysis.m1s1e2" - stem.dir="up" - xml:id="analysis.m1s1e3"/> - </layer> - </staff> -</measure> - -
-

-

A one-to-many relationship between the current element and the entities being referred to can be expressed by using a list of space-separated URIs in corresp.

-

The synch attribute points to an element that is synchronous with; that is, begins at the same moment in time, as the current element. It is useful when the encoding order differs from the order in which entities occur in time.

-

The when attribute may be used to indicate the point of occurrence of the feature bearing this attribute along a time line. Its value must be the ID of a when element. For more detailed information regarding the use of when, please see .

-
-
-
- Linking from MEI -

This section describes techniques and approaches to establish references within a single MEI document, or to link out from one MEI document to another or to other external sources.

-
- Pointers and References -

The link elements discussed in this section are the ptr and the ref elements which are declared in the MEI.ptrref module.

-

- - - - -

-

- The ptr element is a traversible pointer to another location. It is an empty linking element that uses only attributes to describe its link destination. It cannot contain text or sub-elements to describe the referenced object. The next example shows the use of the ptr element to target a certain identifier (here e.g., a page number, or more precisely, page break elements, pb, bearing these identifiers) from within a list of item descriptions: -

-

-

- - <list> - <li> - <!-- item description --> - <ptr target="#p123"/> - </li> - <li> - <!-- item description --> - <ptr target="#p124"/> - </li> -</list> - -
-

-

- The ref element defines a traversible reference to another location. While ptr cannot contain other markup, the ref element can include text or sub-elements that further specify the link destination: -

-

-

- - <repository> - <ref target="http://path.to.target/repo1.xml"> - <title>…</title> - <address> - <addrLine>…</addrLine> - </address> - <identifier>…</identifier> - </ref> -</repository> - -
-

-
-
- Specifying Link Elements -

- The ptr and ref elements share a set of common attributes that are inherited from the att.pointing class (a more detailed explanation is provided below): -

-

- - - -

-

- In addition to the attributes in the att.pointing class, the mimetype attribute from the att.internetMedia class is also available on ptr and ref (a more detailed explanation is provided below): -

-

- - - -

-

- The att.linking class provides another set of common attributes for linking (see ): -

-

- Additionally, the following attributes are also available on ptr and ref: -

-

- Via the att.metadataPointing class: -

-

- - - -

-

- Via the att.classed class: -

-

- - - -

-

- Via the att.responsibility class: -

-

- - - -

-
- Define the link element’s target (XPointer mechanism) -

- The target attribute specifies the destination of a pointer or reference using a method standardized by the W3C consortium, known as the XPointer mechanism. The XPointer framework is described at http://www.w3.org/TR/xptr-framework/. This mechanism permits a range of complexity, from the very simple (a reference to the value of the target element’s xml:id attribute) to the more complex usage of a full URI with embedded XPointers: -

-

-

- - <!-- element ID --> -<ptr target="#SA"/> - -
-

-

-

- - <!-- relative URL --> -<ptr target="myFile.xml"/> - -
-

-

-

- - <!-- absolute URL --> -<ptr target="http://www.w3.org/TR/xptr-framework/"/> - -
-

-

-

- - <!-- URL with fragment identifier --> -<ptr target="http://www.w3.org/TR/xptr-xpointer/#xpointer(id('chum')/quote)"/> - -
-

-

-

- - <!-- URN --> -<ref target="urn:isan:0000-0000-9E59-0000-O-0000-0000-2">Spider-Man</ref> - -
-

-

- A target attribute is not required in order to mark the textual content as a cross-reference, as demonstrated in the example below; however, without this attribute the reference will not be resolvable. -

-

-

- - <p>See <ref>Hankinson, Roland, Fujinaga (2011)</ref>.</p> - -
-

-
-
- Define the type of a link element’s target -

- The targettype attribute allows the target resource to be characterized using any convenient classification scheme or typology. This is often useful when the target requires special processing, e.g., for display purposes. The pointers in the examples below may be formatted differently, e.g., the bibliographic citation may result in special typography while the pointer to the audio file may be used to embed an audio player: -

-

-

- - <ptr target="#cit1" targettype="biblioCitation"/> - -
-

-

-

- - <ptr target="http://path.to.resource/myAudio.aiff" targettype="audioClip"/> - -
-

-
-
- Define the mimetype of a link element’s target -

- The function of the mimetype attribute is similar to that of targettype in that they both allow classification of the destination. Unlike targettype, however, mimetype explicitly defines the destination type using a standard taxonomy. Its value should be a valid MIME (Multimedia Internet Mail Extension) type as defined by the Internet Engineering Task Force (IETF) in RFC 2046, available at http://www.ietf.org/rfc/rfc2046.txt. The following are all valid mimetype values: -

-

-

- - <ptr mimetype="application/pdf" target="my.pdf"/> -<ptr mimetype="text/xml" target="my.xml"/> -<ptr mimetype="image/png" target="my.png"/> - -
-

-

- As shown above, the ptr element can be used to ‘point to’ a digital image (target="my.png"). However, when the intention is to display a digital image as part of the rendering of an MEI file, the graphic element provides a convenient and recommended alternative: -

-

-

- - <graphic mimetype="image/png" target="my.png"/> - -
-

-

- The mimetype attribute is particularly useful for documenting the nature of the destination when the value of target does not provide a filename extension or when the destination is a non-standard file type: -

-

-

- - <ptr mimetype="application/pdf" target="myFile1"/> -<ptr mimetype="application/x-myApplicationSpecificFile" target="myFile2"/> - -
-

-
-
- Determine the link element’s behaviour -

- The xlink:actuate and xlink:show attributes are used in conjunction to determine the link’s behavior. -

-

- The xlink:actuate attribute defines whether the resolution of a link occurs automatically or must be requested by the user. -

-

- The following values are allowed for the xlink:actuate attribute: -

-

- - - load the target resource(s) immediately - - load the target resource(s) upon user request, e.g., after a mouse click - - do not permit loading of the target resource(s); no other markup is provided to determine appropriate behavior - - behavior other than permitted by the other values of this attribute; application should look for other markup to determine appropriate behavior - -

-

- The value none may be used to indicate that the link is un-traversable and no other markup is provided to determine appropriate behavior; it may or may not render the link invisible to the user. When the value of xlink:actuate is other, an application must base a determination of appropriate behavior on factors other than the value of xlink:actuate. -

-

- The xlink:show attribute defines how a remote resource is to be rendered. The following values are permitted: -

-

- - - target of the link appears in a new window - - target of the link replaces the current resource in the same window - - the content of the target appears at the point of the link - - do not permit traversal to the target resource(s); no other markup is provided to determine appropriate behavior - - behavior other than permitted by the other values of this attribute; application should look for other markup to determine appropriate behavior - -

-

- The value none may be used to indicate a link that is not displayed or is not displayable and no other markup is provided to determine appropriate behavior. When the value of xlink:show is other, an application must base a determination of appropriate behavior on factors other than the value of xlink:show. -

-

- The following example illustrates a pointer that results in the automatic creation of a new window with the content of the target loaded in it: -

-

-

- - <ptr xmlns="http://www.tei-c.org/ns/Examples" - xmlns:xlink="http://www.w3.org/1999/xlink" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron" - mimetype="text" - target="http://www.ietf.org/rfc/rfc2046.txt" - xlink:actuate="onLoad" - xlink:show="new"/> - -
-

-
-
- Determine the link element’s role -

- The xlink:role attribute describes the meaning of resources within the context of a link. It is used to label or describe a link or resource in a human- and machine-readable fashion. The value of xlink:role must be an absolute URI (Uniform Resource Identifier) reference as defined by the Internet Engineering Task Force (IETF) in RFC 3986, available at http://tools.ietf.org/html/rfc3986. The URI reference identifies a resource that describes the intended property. When no value is supplied, no particular role value is to be inferred. -

-

-

- - <ptr xmlns="http://www.tei-c.org/ns/Examples" - xmlns:xlink="http://www.w3.org/1999/xlink" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron" - target="joe.xml" - xlink:role="http://www.example.com/linkprops/student" /> - -
-

-

-

- - <ptr xmlns="http://www.tei-c.org/ns/Examples" - xmlns:xlink="http://www.w3.org/1999/xlink" - xmlns:rng="http://relaxng.org/ns/structure/1.0" - xmlns:sch="http://purl.oclc.org/dsdl/schematron" - target="joe.xml" - xlink:role="http://www.example.com/linkprops/instructor" /> - -
-

-

- In the preceding examples, the value of the xlink:role attribute may be used to specify the value of the link target’s role. -

-
-
-
-
- Linking and Alignment -

The linkAlign module has been deprecated in MEI v3.

-
-
-
- Integrating MEI with other Standards and Formats -

In this chapter, the combination of MEI with other relevant formats in the field is - covered. Here, the MEI Guidelines try to serve as Best Practice Recommendations; they - don't claim to provide full and / or authoritative documentation for those other - formats. The intention is to provide good starting points and share experience across - various projects, trying to unify both tools and workflows for better efficiency. - Accordingly, if the information found here provides as outdated or incomplete, please - get in - touch.

-
- TEI -

The TEI’s Special Interest Group on Music has come up with an ODD customization - for TEI, which allows to embed MEI excerpts into TEI. However, the SIG Music is - officially considered dormant, so the information provided - is somewhat outdated. The most recent resources are available from GitHub.

-

As of yet, no official MEI customization to include elements from the TEI - namespace into MEI has been written, even though this is definitely wanted.

-
-
- IIIF -

This chapter will explain how to use MEI in an IIIF-compatible way.

-
-
- SMuFL -

This section describes how to use MEI with the Standard Music Font Layout (SMuFL, - https://www.smufl.org/) - specification.

-
-
- SVG -

In order to use Scalable Vector Graphics (SVG) in MEI, a new module needs to be - compiled into ODD (see for an - introduction on how to do that). In order to do that, you need to enter the - following moduleRef into the schemaSpec of your ODD file:

-

-

- - - - - - - - - - - - -
-

-

With this addition, which can be added to any of the provided customizations of - MEI (see ), the <svg> - element becomes available everywhere `model.graphicLike` (i.e., the graphic element) is currently allowed, that is: inside of fig, incip, surface, and zone.

-

In the following example, an <svg:path> element is inserted into a surface. It would now be possible for measures or other music features to - point to the rectangular zone in MEI namespace, or the fancy - shaped <svg:path> using their facs attribute (see for that mechanism). It’s equally possible to use - SVG content inside figures on title pages or anywhere else.

-

-

- - - - - - - - - - - - - - -
-

-

Of course it’s possible to allow elements in SVG namespace in other places in MEI - as well, by adjusting the model classes that the SVG namespace shall join.

-
-
- Musical Instrument Digital Interface (MIDI) -

This chapter describes the MIDI encoding functionality present in MEI. The purpose - of this module is to allow for integrating MIDI data into MEI-encoded notation, to - both aid software in translating MEI to MIDI, and to permit the capture of - information in files that have been translated from MIDI to MEI. The MIDI model in - MEI is similar to that of Mup, and the user is directed to the Mup User Guide for further - reading.

-

The MIDI module defines certain generally-accepted MIDI units that may be used - outside of a MIDI context. For example, the dur.ppq attribute accepts - MIDI ppq (Pulses Per Quarter) as a valid measurement of - duration. Similarly, the pnum attribute allows MIDI note numbers for - specifying a pitch value.

-
- PPQ in scoreDef and staffDef -

To define the MIDI resolution of a score, the ppq attribute may be - used on the scoreDef element. This value can be used to - interpret the values found in the dur.ppq attribute on elements in - the att.duration.ges class.

-

-

- - <scoreDef keysig="1f" meter.count="4" meter.sym="common" meter.unit="4" ppq="48"> - <staffGrp> - <staffDef clef.line="2" clef.shape="G" keysig="1f" lines="5" n="1" xml:id="midi.P1"></staffDef> - <staffDef clef.line="4" clef.shape="F" keysig="1f" lines="5" n="2" xml:id="midi.P2"></staffDef> - <staffDef clef.line="4" clef.shape="F" keysig="1f" lines="5" n="3" xml:id="midi.P3"></staffDef> - </staffGrp> -</scoreDef> -<!-- snip --> -<note dur="8" dur.ges="24p" oct="5" pname="a" stem.dir="up" xml:id="midi.d1e40"></note> -<!-- 8th note --> -<rest dur="32" dur.ges="6p" vo="4" xml:id="midi.d1e58"></rest> -<!-- 32nd note --> -<!-- snip --> -
-

-

The ppq attribute is also available on the staffDef element in order to aid in the conversion to MEI from other - representations that allow a different time base for each staff. However, these - independent values for ppq are only interpretable in terms of a - common time base. Therefore, the ppq attribute is required on scoreDef when the values of ppq on the staff - definitions differ. In the following example, the values of the ppq - attributes on the staffDef elements are all factors of - the value of ppq attached to scoreDef.

-

-

- - <scoreDef keysig="1f" - meter.count="4" - meter.sym="common" - meter.unit="4" - ppq="48"> - <staffGrp> - <staffDef clef.line="2" - clef.shape="G" - keysig="1f" - lines="5" - n="1" - ppq="2" - xml:id="midi.P1"/> - <staffDef clef.line="4" - clef.shape="F" - keysig="1f" - lines="5" - n="2" - ppq="16" - xml:id="midi.P2"/> - <staffDef clef.line="4" - clef.shape="F" - keysig="1f" - lines="5" - n="3" - ppq="24" - xml:id="midi.P3"/> - </staffGrp> -</scoreDef> - -
-

-
-
- Recording General MIDI Instrumentation -

The instrDef element can be used to record MIDI - instrument names or numbers using the midi.instrname and - midi.instrnum attributes. The midi.instrname attribute - must contain an instrument name from the list provided by the data.MIDINAMES - data type. By default, data.MIDINAMES contains General MIDI Instrument - designations.

-

-

- - <scoreDef keysig="1f" - meter.count="4" - meter.sym="common" - meter.unit="4" - ppq="48"> - <staffGrp> - <staffDef clef.line="2" - clef.shape="G" - lines="5" - n="1" - xml:id="midi.P5"> - <instrDef midi.instrname="Violin"/> - </staffDef> - <staffDef clef.line="2" - clef.shape="G" - lines="5" - n="2" - xml:id="midi.P6"> - <instrDef midi.instrname="Violin"/> - </staffDef> - <staffDef clef.line="3" - clef.shape="C" - lines="5" - n="3" - xml:id="midi.P7"> - <instrDef midi.instrname="Viola"/> - </staffDef> - <staffDef clef.line="4" - clef.shape="F" - lines="5" - n="3" - xml:id="midi.P8"> - <instrDef midi.instrname="Cello"/> - </staffDef> - </staffGrp> -</scoreDef> - -
-

-

The midi.instrnum is provided for those cases when an instrument - number is needed. It must contain valid MIDI values; that is, 0-127. In these - cases, a General MIDI Instrument name is redundant.

-

-

- - <scoreDef keysig="1f" - meter.count="4" - meter.sym="common" - meter.unit="4" - ppq="48"> - <staffGrp> - <staffDef clef.line="2" - clef.shape="G" - lines="5" - n="1" - xml:id="midi.P5"> - <instrDef midi.instrnum="41"/> - </staffDef> - <staffDef clef.line="2" - clef.shape="G" - lines="5" - n="2" - xml:id="midi.P6"> - <instrDef midi.instrnum="41"/> - </staffDef> - <staffDef clef.line="3" - clef.shape="C" - lines="5" - n="3" - xml:id="midi.P7"> - <instrDef midi.instrnum="42"/> - </staffDef> - <staffDef clef.line="4" - clef.shape="F" - lines="5" - n="3" - xml:id="midi.P8"> - <instrDef midi.instrnum="43"/> - </staffDef> - </staffGrp> -</scoreDef> - -
-

-
-
- Recording MIDI Event Data -

MIDI messages are encapsulated in the midi element, which - is typically used in contexts like layer and measure. In earlier versions of MEI, the noteOn and noteOff elements were used to record - MIDI note on/off events. The use of these elements is now discouraged in favor - of using the note element directly. MIDI duration should - be recorded using the dur.ges attribute, and MIDI pitch information - should be recorded using the pnum attribute.

-

MIDI control changes (cc) are encoded using the - num and val attributes. Control change numbers are - specified in the General MIDI documentation. In the example below, the cc elements encode increasing controller event 7 (volume) - values, or in musical terms, a crescendo. Other MIDI event messages follow this - same pattern, using the num and val attributes to record - the raw MIDI data.

-

-

- - <measure> - <staff> - <layer> - <note dur.ges="8" pnum="45"/> - <note dur.ges="8" pnum="42"/> - <note dur.ges="8" pnum="43"/> - <note dur.ges="8" pnum="44"/> - </layer> - </staff> - <midi layer="1" staff="1"> - <cc num="7" tstamp=".5" val="50"/> - <cc num="7" tstamp="1.5" val="55"/> - <cc num="7" tstamp="2" val="60"/> - <cc num="7" tstamp="2.5" val="65"/> - </midi> -</measure> - -
-

-

In the preceding example, each control change is associated with a time stamp. - The tstamp attribute is required in order to indicate when the MIDI - event should take place. It is often necessary to indicate a time stamp - slightly earlier than the affected notes to compensate for MIDI delay.

-

For better legibility and error checking, the midi - element may be used, as in the following example, to group MIDI parameter - changes. Even so, the tstamp attribute is required on all parameters - in order to associate them with their point of actuation:

-

-

- - <midi layer="1" staff="1"> - <cc num="7" tstamp=".5" val="50"/> - <cc num="64" tstamp=".5" val="64"/> -</midi> - -
-

-
-
- MIDI in Mensural and Neume Notation -

In mensural, neume, and other historical or non-Western repertoires, there is - often no measure-based time stamp with which to associate MIDI controller data. - Therefore, in these notations MIDI controller data is assumed to be associated - with the event that immediately follows in the same layer. Thus, a crescendo in - mensural notation may be encoded like so:

-

-

- - <staff> - <layer> - <midi> - <cc num="7" val="50"/> - </midi> - <note dur="fusa" dur.ges="8p" pnum="42"/> - <midi> - <cc num="7" val="55"/> - </midi> - <note dur="fusa" dur.ges="8p" pnum="43"/> - <midi> - <cc num="7" val="60"/> - </midi> - <note dur="fusa" dur.ges="8p" pnum="44"/> - <midi> - <cc num="7" val="65"/> - </midi> - <note dur="fusa" dur.ges="8p" pnum="45"/> - </layer> -</staff> - -
-

-
-
-
- - -
- - - - Data type definitions. - - - Written accidental values. - - - - - - - - - -

- -

- - - - Written standard accidental values. - - - - Sharp. - - - Flat. - - - Double sharp (written as 2 sharps). - - - Double sharp (written using croix). - - - Double flat. - - - Triple sharp (written as a croix followed by a sharp). - - - Triple sharp (written as a sharp followed by a croix). - - - Triple sharp (written as 3 sharps). - - - Triple flat. - - - Natural. - - - Natural + flat; used to cancel preceding double flat. - - - Natural + sharp; used to cancel preceding double sharp. - - - - - - Written quarter-tone accidental values. - - - - - Sharp note raised by quarter tone (sharp modified by arrow). - - - Sharp note lowered by quarter tone (sharp modified by arrow). - - - Flat note raised by quarter tone (flat modified by arrow). - - - Flat note lowered by quarter tone (flat modified by arrow). - - - Natural note raised by quarter tone (natural modified by arrow). - - - Natural note lowered by quarter tone (natural modified by arrow). - - - Double sharp note raised by quarter tone (double sharp modified by arrow). - - - Double sharp note lowered by quarter tone (double sharp modified by arrow). - - - Double flat note raised by quarter tone (double flat modified by arrow). - - - Double flat note lowered by quarter tone (double flat modified by arrow). - - - - 1/4-tone flat accidental. - - - 3/4-tone flat accidental. - - - 1/4-tone sharp accidental. - - - 3/4-tone sharp accidental. - - - - - - Arel-Ezgi-Uzdilek (AEU) accidental values (written and gestural/performed). - - - - Büyük mücenneb (sharp). - - - Küçük mücenneb (sharp). - - - Bakiye (sharp). - - - Koma (sharp). - - - Koma (flat). - - - Bakiye (flat). - - - Küçük mücenneb (flat). - - - Büyük mücenneb (flat). - - - - -

- -

- - - - Persian accidental values (written and gestural/performed). - - - - Koron (quarter tone flat). - - - Sori (quarter tone sharp). - - - - - - Gestural/performed standard accidental values. - - - - - - - - - - - Gestural/performed accidental values. - - - - Sharp. - - - Flat. - - - Double sharp. - - - Double flat. - - - Triple sharp. - - - Triple flat. - - - Natural. - - - - - - Gestural/performed quarter-tone accidental values. - - - - Three quarter-tones sharp. - - - Quarter-tone sharp. - - - Quarter-tone flat. - - - Three quarter-tones flat. - - - Five quarter-tones sharp. - - - Five quarter-tones flat. - - - - - - The following list of articulations mostly corresponds to symbols from the Western Musical - Symbols portion of the Unicode Standard. The dot and stroke values may be used in cases where - interpretation is difficult or undesirable. - - - - Accent (Unicode 1D17B). - - - Inverted accent. - - - Long accent, used to indicate an elongated accent mark. It is the responsibility of the encoder to distinguish between accents and hairpins. - - - Soft accent, see SMuFL Articulation supplement (U+ED40–U+ED4F). - - - Staccato (Unicode 1D17C). - - - Tenuto (Unicode 1D17D). - - - Staccatissimo (Unicode 1D17E). - - - Marcato (Unicode 1D17F). - - - Spiccato. - - - Stress (Unicode 00B4). - - - Unstress (Unicode 02D8). - - - Main note followed by short slide to higher, indeterminate pitch (Unicode - 1D185). - - - Main note preceded by short slide from lower, indeterminate pitch (Unicode - 1D186). - - - Main note preceded by long slide from lower, often indeterminate pitch; also known - as "squeeze". - - - Main note preceded by "slide" from higher, indeterminate pitch. - - - Main note followed by short "slide" to lower, indeterminate pitch. - - - Main note followed by long "slide" to lower, indeterminate pitch. - - - "lip slur" to lower pitch, then return to written pitch. - - - Main note followed by quick upward rise, then descent in pitch (Unicode - 1D187). - - - (Unicode 1D188). - - - Alternation between written pitch and next highest overtone (brass instruments) or - note minor third higher (woodwinds). - - - Down bow (Unicode 1D1AA). - - - Up bow (Unicode 1D1AB). - - - Harmonic (Unicode 1D1AC). - - - Snap pizzicato (Unicode 1D1AD). - - - Fingernail (Unicode 1D1B3). - - - Stop harp string from sounding (Unicode 1D1B4). - - - Stop all harp strings from sounding (Unicode 1D1B5). - - - Full (as opposed to stopped) tone. - - - "muffled" tone. - - - Double tongue (Unicode 1D18A). - - - Triple tongue (Unicode 1D18B). - - - Use heel (organ pedal). - - - Use toe (organ pedal). - - - Percussive effect on guitar string(s). - - - Left-hand pizzicato. - - - Uninterpreted dot. - - - Uninterpreted stroke. - - - - - - - "" contains a deprecated value. - - - "" contains a deprecated value. - - - - - - Dots attribute values (number of augmentation dots) (Read, 113-119, ex. 8-21). - - - 4 - - - - - Records where bar lines are drawn. The value 'staff' describes the traditional placement - of bar lines. - - - - Between staves only. - - - Between and across staves as necessary. - - - Short bar line through a subset of staff lines. - - - - - - Renderings of bar lines. Some values correspond to the Western Musical Symbols portion of - the Unicode Standard. - - - - Dashed line (SMuFL E036 and Unicode 1D104). - - - Dotted line (SMuFL E037). - - - Double bar line (SMuFL E031 and Unicode 1D101). - - - Double dashed line. - - - Double dotted line. - - - Heavy double bar line (SMuFL E035). - - - Segno serpent with vertical lines (SMuFL E04B). - - - End bar line (SMuFL E032 and Unicode 1D102). - - - Heavy bar line (SMuFL E034). - - - Bar line not rendered. - - - Repeat start (SMuFL E040 and Unicode 1D106). - - - Repeat start and end (SMuFL E042). - - - Repeat end (SMuFL E041 and Unicode 1D107). - - - Segno serpent. - - - Single bar line (SMuFL E030 and Unicode 1D100). - - - - - - Beam attribute values: initial, medial, terminal. Nested beaming is permitted. - - - [i|m|t][1-6] - - - - - Location of a beam relative to the events it affects. - - - - The beam is above the events it affects. - - - The beam is below the events it affects. - - - The beam is above and below the events it affects. - - - - - - A beat location, i.e., [0-9]+(\.?[0-9]*)? The value must fall between 0 and the numerator - of the time signature + 1, where 0 represents the left bar line and the upper boundary - represents the right bar line. For example, in 12/8 the value must be in the range from 0 to - 13. - - - 0 - - - - - Visual and performance information for a repeated beat symbol. - - - - 1|2|3|4|5 - - - mixed - - - - - - Either an integer value, a decimal value, or a token. Fractional values are limited to - .25, .5, .75, while the token value is restricted to 'full'. - - - - \.25|\.5|\.75 - - - [0-9](\.25|\.5|\.75)? - - - full - - - - - - Boolean attribute values. - - - - True. - - - False. - - - - - - Indicates where cancellation accidentals are shown in a key signature. - - - - Do not show cancellation accidentals. - - - Show cancellation accidentals before the new key accidentals. - - - Show cancellation accidentals after the new key accidentals ("Old style" or "French") - - - Show cancellation accidentals before the barline (also known as "Russian"). - - - - - - Values for certainty attribute. Certainty may be expressed by one of the predefined symbolic values high, - medium, or low. The value unknown should be used in cases where the encoder - does not wish to assert an opinion about the matter. - - - - High certainty. - - - Medium certainty. - - - Low certainty. - - - An unknown level of certainty. - - - - - - Clef line attribute values. The value must be in the range between 1 and the number of - lines on the staff. The numbering of lines starts with the lowest line of the staff. - - - - - - Clef shape attribute values (Read, p.53-56). Some values correspond to the Unicode - Standard. - - - - G clef (Unicode 1D11E). - - - Double G clef. Sounds one octave lower than G clef. (See remarks on usage below.) - - - F clef (Unicode 1D122). - - - C clef (Unicode 1D121). - - - Drum clef (Unicode 1D125 or Unicode 1D126). - - - Tablature "clef"; i.e., usually "TAB" rendered vertically. - - - - -

Double-G clefs sound one octave lower, so do not combine with dis/ - dis.place/clef.dis/clef.dis.place. In some cases - the double G clef may be used to indicate that two voices share one staff and - does not sound one octave lower. In this case the oct attribute may be - used to clarify the sounding octave of the instruments for the clef. -

- - - - Tone-cluster rendition. - - - - White keys. - - - Black keys. - - - Mixed black and white keys. - - - - - - Confidence is expressed as a real number between 0 and 1; 0 representing certainly false - and 1 representing certainly true. - - - 0 - 1 - - - - - List of named colors from CSS Color Module Level 4. - - - - Hex: #f0f8ff / RGB: 240,248,255 - - - Hex: #faebd7 / RGB: 250,235,215 - - - Hex: #00ffff / RGB: 0,255,255 - - - Hex: #7fffd4 / RGB: 127,255,212 - - - Hex: #f0ffff / RGB: 240,255,255 - - - Hex: #f5f5dc / RGB: 245,245,220 - - - Hex: #ffe4c4 / RGB: 255,228,196 - - - Hex: #000000 / RGB: 0,0,0 - - - Hex: #ffebcd / RGB: 255,235,205 - - - Hex: #0000ff / RGB: 0,0,255 - - - Hex: #8a2be2 / RGB: 138,43,226 - - - Hex: #a52a2a / RGB: 165,42,42 - - - Hex: #deb887 / RGB: 222,184,135 - - - Hex: #5f9ea0 / RGB: 95,158,160 - - - Hex: #7fff00 / RGB: 127,255,0 - - - Hex: #d2691e / RGB: 210,105,30 - - - Hex: #ff7f50 / RGB: 255,127,80 - - - Hex: #6495ed / RGB: 100,149,237 - - - Hex: #fff8dc / RGB: 255,248,220 - - - Hex: #dc143c / RGB: 220,20,60 - - - Hex: #00ffff / RGB: 0,255,255 - - - Hex: #00008b / RGB: 0,0,139 - - - Hex: #008b8b / RGB: 0,139,139 - - - Hex: #b8860b / RGB: 184,134,11 - - - Hex: #a9a9a9 / RGB: 169,169,169 - - - Hex: #006400 / RGB: 0,100,0 - - - Hex: #a9a9a9 / RGB: 169,169,169 - - - Hex: #bdb76b / RGB: 189,183,107 - - - Hex: #8b008b / RGB: 139,0,139 - - - Hex: #556b2f / RGB: 85,107,47 - - - Hex: #ff8c00 / RGB: 255,140,0 - - - Hex: #9932cc / RGB: 153,50,204 - - - Hex: #8b0000 / RGB: 139,0,0 - - - Hex: #e9967a / RGB: 233,150,122 - - - Hex: #8fbc8f / RGB: 143,188,143 - - - Hex: #483d8b / RGB: 72,61,139 - - - Hex: #2f4f4f / RGB: 47,79,79 - - - Hex: #2f4f4f / RGB: 47,79,79 - - - Hex: #00ced1 / RGB: 0,206,209 - - - Hex: #9400d3 / RGB: 148,0,211 - - - Hex: #ff1493 / RGB: 255,20,147 - - - Hex: #00bfff / RGB: 0,191,255 - - - Hex: #696969 / RGB: 105,105,105 - - - Hex: #696969 / RGB: 105,105,105 - - - Hex: #1e90ff / RGB: 30,144,255 - - - Hex: #b22222 / RGB: 178,34,34 - - - Hex: #fffaf0 / RGB: 255,250,240 - - - Hex: #228b22 / RGB: 34,139,34 - - - Hex: #ff00ff / RGB: 255,0,255 - - - Hex: #dcdcdc / RGB: 220,220,220 - - - Hex: #f8f8ff / RGB: 248,248,255 - - - Hex: #ffd700 / RGB: 255,215,0 - - - Hex: #daa520 / RGB: 218,165,32 - - - Hex: #808080 / RGB: 128,128,128 - - - Hex: #008000 / RGB: 0,128,0 - - - Hex: #adff2f / RGB: 173,255,47 - - - Hex: #808080 / RGB: 128,128,128 - - - Hex: #f0fff0 / RGB: 240,255,240 - - - Hex: #ff69b4 / RGB: 255,105,180 - - - Hex: #cd5c5c / RGB: 205,92,92 - - - Hex: #4b0082 / RGB: 75,0,130 - - - Hex: #fffff0 / RGB: 255,255,240 - - - Hex: #f0e68c / RGB: 240,230,140 - - - Hex: #e6e6fa / RGB: 230,230,250 - - - Hex: #fff0f5 / RGB: 255,240,245 - - - Hex: #7cfc00 / RGB: 124,252,0 - - - Hex: #fffacd / RGB: 255,250,205 - - - Hex: #add8e6 / RGB: 173,216,230 - - - Hex: #f08080 / RGB: 240,128,128 - - - Hex: #e0ffff / RGB: 224,255,255 - - - Hex: #fafad2 / RGB: 250,250,210 - - - Hex: #d3d3d3 / RGB: 211,211,211 - - - Hex: #90ee90 / RGB: 144,238,144 - - - Hex: #d3d3d3 / RGB: 211,211,211 - - - Hex: #ffb6c1 / RGB: 255,182,193 - - - Hex: #ffa07a / RGB: 255,160,122 - - - Hex: #20b2aa / RGB: 32,178,170 - - - Hex: #87cefa / RGB: 135,206,250 - - - Hex: #778899 / RGB: 119,136,153 - - - Hex: #778899 / RGB: 119,136,153 - - - Hex: #b0c4de / RGB: 176,196,222 - - - Hex: #ffffe0 / RGB: 255,255,224 - - - Hex: #00ff00 / RGB: 0,255,0 - - - Hex: #32cd32 / RGB: 50,205,50 - - - Hex: #faf0e6 / RGB: 250,240,230 - - - Hex: #ff00ff / RGB: 255,0,255 - - - Hex: #800000 / RGB: 128,0,0 - - - Hex: #66cdaa / RGB: 102,205,170 - - - Hex: #0000cd / RGB: 0,0,205 - - - Hex: #ba55d3 / RGB: 186,85,211 - - - Hex: #9370db / RGB: 147,112,219 - - - Hex: #3cb371 / RGB: 60,179,113 - - - Hex: #7b68ee / RGB: 123,104,238 - - - Hex: #00fa9a / RGB: 0,250,154 - - - Hex: #48d1cc / RGB: 72,209,204 - - - Hex: #c71585 / RGB: 199,21,133 - - - Hex: #191970 / RGB: 25,25,112 - - - Hex: #f5fffa / RGB: 245,255,250 - - - Hex: #ffe4e1 / RGB: 255,228,225 - - - Hex: #ffe4b5 / RGB: 255,228,181 - - - Hex: #ffdead / RGB: 255,222,173 - - - Hex: #000080 / RGB: 0,0,128 - - - Hex: #fdf5e6 / RGB: 253,245,230 - - - Hex: #808000 / RGB: 128,128,0 - - - Hex: #6b8e23 / RGB: 107,142,35 - - - Hex: #ffa500 / RGB: 255,165,0 - - - Hex: #ff4500 / RGB: 255,69,0 - - - Hex: #da70d6 / RGB: 218,112,214 - - - Hex: #eee8aa / RGB: 238,232,170 - - - Hex: #98fb98 / RGB: 152,251,152 - - - Hex: #afeeee / RGB: 175,238,238 - - - Hex: #db7093 / RGB: 219,112,147 - - - Hex: #ffefd5 / RGB: 255,239,213 - - - Hex: #ffdab9 / RGB: 255,218,185 - - - Hex: #cd853f / RGB: 205,133,63 - - - Hex: #ffc0cb / RGB: 255,192,203 - - - Hex: #dda0dd / RGB: 221,160,221 - - - Hex: #b0e0e6 / RGB: 176,224,230 - - - Hex: #800080 / RGB: 128,0,128 - - - Hex: #663399 / RGB: 102,51,153 - - - Hex: #ff0000 / RGB: 255,0,0 - - - Hex: #bc8f8f / RGB: 188,143,143 - - - Hex: #4169e1 / RGB: 65,105,225 - - - Hex: #8b4513 / RGB: 139,69,19 - - - Hex: #fa8072 / RGB: 250,128,114 - - - Hex: #f4a460 / RGB: 244,164,96 - - - Hex: #2e8b57 / RGB: 46,139,87 - - - Hex: #fff5ee / RGB: 255,245,238 - - - Hex: #a0522d / RGB: 160,82,45 - - - Hex: #c0c0c0 / RGB: 192,192,192 - - - Hex: #87ceeb / RGB: 135,206,235 - - - Hex: #6a5acd / RGB: 106,90,205 - - - Hex: #708090 / RGB: 112,128,144 - - - Hex: #708090 / RGB: 112,128,144 - - - Hex: #fffafa / RGB: 255,250,250 - - - Hex: #00ff7f / RGB: 0,255,127 - - - Hex: #4682b4 / RGB: 70,130,180 - - - Hex: #d2b48c / RGB: 210,180,140 - - - Hex: #008080 / RGB: 0,128,128 - - - Hex: #d8bfd8 / RGB: 216,191,216 - - - Hex: #ff6347 / RGB: 255,99,71 - - - Hex: #40e0d0 / RGB: 64,224,208 - - - Hex: #ee82ee / RGB: 238,130,238 - - - Hex: #f5deb3 / RGB: 245,222,179 - - - Hex: #ffffff / RGB: 255,255,255 - - - Hex: #f5f5f5 / RGB: 245,245,245 - - - Hex: #ffff00 / RGB: 255,255,0 - - - Hex: #9acd32 / RGB: 154,205,50 - - - - -

Color names are taken from the list at https://www.w3.org/TR/css-color-4/.

-

All of these keywords are case-insensitive.

- - - - Parameterized color values - - - - - #[0-9A-Fa-f]{6,6} - - - - #[0-9A-Fa-f]{8,8} - - - - rgb\((\s*(([01]?[0-9]?[0-9])|2[0-4][0-9]|25[0-5])\s*,\s*){2}([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\s*\) - - - - rgba\(\s*(([01]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\s*,\s*){3}(0(\.\d+)?|1(\.0+)?)\s*\)|rgba\(\s*(((\d{1,2})?%|100%)\s*,\s*){2}(\d{1,2}%|100%)\s*,\s*(0(\.\d+)?|1(\.0+)?)\s*\) - - - - hsl\(\s*((\d{1,2})|[12]\d{2}|3[0-5]\d|360)\s*,\s*(\d{1,2}%|100%)\s*,\s*(\d{1,2}%|100%)\s*\) - - - - hsla\(\s*(\d{1,2}|[12]\d{2}|3[0-5]\d|360)\s*,\s*(\d{1,2}%|100%)\s*,\s*(\d{1,2}%|100%)\s*,\s*(0(\.\d+)?|1(\.0+)?)\s*\) - - - - - - A value in one of the following forms is expected: 1) hexadecimal RRGGBB, 2) hexadecimal - RRGGBBAA, 3) CSS RGB, 4) CSS RGBA, 5) HSL, 6) HSLA, or 7) CSS color name. - - - - - - - - - Description of direction with respect to an imaginary compass. - - - - - - - - - Basic compass directions. - - - - In a northern direction. - - - In an eastern direction. - - - In a southern direction. - - - In a western direction. - - - - - - Additional compass directions. - - - - In a north-eastern direction. - - - In a north-western direction. - - - In a south-eastern direction. - - - In a south-western direction. - - - - - - 360th-unit measure of a circle’s circumference; optionally signed decimal number between - -360 and 360. - - - 360.0 - -360.0 - - - - - Divisio values. - - - - Divisio ternaria. Three semibreves in a breve. - - - Divisio quaternaria. Foursemibreves in a breve. - - - Divisio senaria imperfecta. Six semibreves in a breve (breve is divided into two, then into three). Aka senaria gallica. - - - Divisio senaria perfecta. Six semibreves in a breve (breve is divided into three, then into two). Aka senaria italica. - - - Divisio octonaria. Eight semibreves in a breve. - - - Divisio novenaria. Nine semibreves in a breve. - - - Divisio duodenaria. Twelve semibreves in a breve. - - - - - - Logical, that is, written, duration attribute values. - - - - - - - - - Logical, that is, written, duration attribute values for rests. - - - - - - - - - Performed duration attribute values. - - - - - - - - - Enclosures for editorial notes, accidentals, articulations, etc. - - - - Parentheses: ( and ). - - - Square brackets: [ and ]. - - - Box. - - - None. - - - - - - Location of musical material relative to a symbol on a staff instead of the staff. - - - - - - - - - Location of musical material relative to a symbol other than a staff. - - - - Above. - - - Below. - - - Left. - - - Right. - - - - - - Location of musical material relative to a symbol other than a staff. - - - - Above and left; north-west. - - - Above and right; north-east. - - - Below and left; south-west. - - - Below and right; south-east. - - - - - - Describes how a graphical object, such as a note head, should be filled. The relative - values — top, bottom, left, and right — indicate these locations *after* rotation is - applied. - - - - Unfilled - - - Filled - - - Top half filled - - - Bottom half filled - - - Left half filled - - - Right half filled - - - - - - In a guitar chord diagram, a label indicating which finger, if any, should be used to play - an individual string. The index, middle, ring, and little fingers are represented by the - values 1-4, while 't' is for the thumb. The values 'x' and 'o' indicate stopped and open - strings, respectively. - - - - 1 - 4 - - - x|o|t - - - - - - Font family (for text) attribute values. - - - - - - Font name (for text) attribute values. - - - - - - Font size expressions. - - - - - - - - - - Font size expressed as numbers; i.e., points or virtual units. - - - \d*(\.\d+)?(pt|vu) - - - - - (pt|vu) - - - 0+(pt|vu) - - - 0+(\.0+)?(pt|vu) - - - \.0+(pt|vu) - - - - - - - - Relative size of symbol that may begin/end a line. - - - 1 - 9 - - - - - Font size expressed as relative term. - - - - Smaller than x-small. - - - Smaller than small, larger than xx-small. - - - Smaller than normal, larger than x-small. - - - Smaller than large, larger than small. - - - Smaller than x-large, larger than normal. - - - Smaller than xx-large, larger than large. - - - Larger than x-large. - - - One size smaller than the current size. - - - One size larger than the current size. - - - - - - Font style (for text) attribute values. - - - - Text slants to right. - - - Unadorned. - - - Text slants to the left. - - - - - - Font weight (for text) attribute values. - - - - Bold or heavy. - - - Not bold. - - - - - - In string tablature, the fret number. The value 0 (zero) indicates the open - string. - - - - - - - Analytical glissando attribute values. - - - - First note/chord in glissando. - - - Note/chord that’s neither first nor last in glissando. - - - Last note in glissando. - - - - - - Do grace notes get time from the current (acc) or previous (unacc) one? - - - - Time "stolen" from following note. - - - Time "stolen" from previous note. - - - No interpretation regarding performed value of grace note. - - - - - - Note head shapes. - - - - - - - - - - Enumerated note head shapes. - - - - Filled, rotated oval (Unicode 1D158). - - - Unfilled, rotated oval (Unicode 1D157). - - - Unfilled, rotated oval (Unicode 1D15D). - - - Unfilled backslash (~ reflection of Unicode 1D10D). - - - Unfilled circle (Unicode 25CB). - - - Plus sign (Unicode 1D144). - - - Unfilled diamond (Unicode 1D1B9). - - - Unfilled isosceles triangle (Unicode 1D148). - - - Unfilled, unrotated oval (Unicode 2B2D). - - - Unfilled downward-pointing wedge (Unicode 1D154). - - - Unfilled rectangle (Unicode 25AD). - - - Unfilled right triangle (Unicode 1D14A). - - - Unfilled semi-circle (Unicode 1D152). - - - Unfilled slash (~ Unicode 1D10D). - - - Unfilled square (Unicode 1D146). - - - X (Unicode 1D143). - - - - - - Hexadecimal number. - - - (#x|U\+)[A-F0-9]+ - - - - - Data values for attributes that capture horizontal alignment. - - - - Left aligned. - - - Right aligned. - - - Centered. - - - Left and right aligned. - - - - - - - - A token indicating diatonic interval quality and size. - - - - [AdMmP][0-9]+ - - - - - - A token indicating direction of the interval but not its precise value, a diatonic - interval (with optional direction and quality), or a decimal value in half steps. Decimal - values are permitted to accommodate micro-tuning. - - - - u|d|s|n|sd|su - - - (\+|\-)?([AdMmP])?[0-9]+ - - - (\+|\-)?\d+(\.\d+)?hs - - - - -

- - Interval direction only: - u = up/higher, - d = down/lower, - s = same, - n = neutral/unknown, - sd = same or lower (but not higher), - su = same or higher (but not lower) - -

-

- - Interval direction, quality, and size: - optional sign, - - - optional quality indicator: - A = augmented, - d = diminished, - M = major, - m = minor, - P = perfect - - - integer value - -

-

- - Interval in half steps: - optional sign, - decimal value - "hs" - -

- - - - ISO date formats. - - - - - - - - - - - - [0-9.,DHMPRSTWYZ/:+\-]+ - - - - - - ISO 24-hour time format: HH:MM:SS.ss, i.e., - [0-9][0-9]:[0-9][0-9]:[0-9][0-9](\.?[0-9]*)?. - - - - - - Indicates the location of the tonic in the circle of fifths. - - - mixed|0|([1-9]|1[0-2])[f|s] - - - - - Indicates how stems should be drawn when more than one layer is present and stem - directions are not indicated on the notes/chords themselves. '1' indicates that there is only - a single layer on a staff. '2o' means there are two layers with opposing stems. '2f' indicates - two 'free' layers; that is, opposing stems will be drawn unless one of the layers has 'space'. - In that case, stem direction in the remaining layer will be determined as if there were only - one layer. '3o' and '3f' are analogous to '2o' and '2f' with three layers allowed. - - - - Single layer. - - - Two layers with opposing stems. - - - Two layers with 'floating' stems. - - - Three layers with opposing stems. - - - Three layers with 'floating' stems. - - - - - - Ligature forms. - - - - Notes are "squeezed" together. - - - Individual notes are replaced by an oblique figure. - - - - - - Visual form of a line. - - - - Dashed line. - - - Dotted line. - - - Straight, uninterrupted line. - - - Undulating line. - - - - - - Symbol that may begin/end a line. - - - - 90 degree turn down (similar to Unicode 231D at end of line, 231C at start). - - - 90 degree turn up (similar to Unicode 231F at end of line, 231E at start). - - - 90 degree turn right (syntactic sugar for "angledown" for vertical or angled - lines). - - - 90 degree turn left (syntactic sugar for "angleup" for vertical or angled - lines). - - - Filled, triangular arrowhead (similar to Unicode U+25C0 or SMuFL U+EB78). - - - Open triangular arrowhead (similar to Unicode U+02C3 or SMuFL U+EB8A). - - - Unfilled, triangular arrowhead (similar to Unicode U+25C1 or SMuFL U+EB82). - - - Harpoon-shaped arrowhead left of line (similar to arrowhead of Unicode - U+21BD). - - - Harpoon-shaped arrowhead right of line (similar to arrowhead of Unicode - U+21BC). - - - Hauptstimme (Unicode U+1D1A6 or SMuFL U+E860). - - - Nebenstimme (Unicode U+1D1A7 or SMuFL U+E861). - - - Theme (SMuFL U+E864). - - - Theme, retrograde (SMuFL U+E865). - - - Theme, retrograde inversion (SMuFL U+E866). - - - Theme, inverted (SMuFL U+E867). - - - Theme (SMuFL U+E868). - - - Theme, inverted (SMuFL U+E869). - - - Choralemelodie (SMuFL U+E86A). - - - Hauptrhythmus (SMuFL U+E86B). - - - No start/end symbol. - - - - - - Datatype of line width measurements. - - - - - - - - - Relative width of a line. - - - - Default line width. - - - Twice as wide as narrow. - - - Twice as wide as medium. - - - - - - A count of measures plus a beat location, i.e., [0-9]+m *\+ *[0-9]+(\.?[0-9]*)?. The - measure count is the number of bar lines crossed by the event, while the beat location is a - timestamp expressed as a beat with an optional fractional part. For example, "1m+3.5" - indicates a point in the next measure on the second half of beat 3. The measure number must be - in the range of 0 to the number of remaining measures, while the beat number must be in the - range from 0 to the numerator of the time signature plus 1. For example, in 6/8 the beat - number must be within the range from 0 (the left bar line) to 7 (the right bar line). A value - with a measure number of "0", such as "0m+2", indicates a point within the current - measure. - - - ([0-9]+m\s*\+\s*)?[0-9]+(\.?[0-9]*)? - - - - - A count of measures plus a beat location, i.e., (\+|-)?[0-9]+m\+[0-9]+(\.?[0-9]*)?. The - measure count is the number of bar lines crossed by the event, while the beat location is a - timestamp expressed as a beat with an optional fractional part. The measure number must be in - the range of preceding measures to the number of remaining measures. A value with a positive - measure number, such as "1m+3", indicates a point in the following measure, while a value with - a negative measure number, such as "-1m+3", marks a point in the preceding measure. The beat - number must be in the range from 0 to the numerator of the time signature plus 1. For example, - in 6/8 the beat number must be within the range from 0 (the left bar line) to 7 (the right - bar line). A value with a measure number of "0", such as "0m+2", indicates a point within the - current measure. - - - (\+|-)?[0-9]+m\+[0-9]+(\.[0-9]*)? - - - - - Measurement expressed in real-world (e.g., centimeters, millimeters, inches, points, - picas, or pixels) or virtual units (vu). 'vu' is the default value. Unlike - data.MEASUREMENTSIGNED, only positive values are allowed. - - - (\+)?\d+(\.\d+)?(cm|mm|in|pt|pc|px|vu)? - - - - - Measurement expressed in real-world (e.g., centimeters, millimeters, inches, points, - picas, or pixels) or virtual units (vu). 'vu' is the default value. Unlike - data.MEASUREMENTUNSIGNED, in which only positive values are allowed, both positive and negative - values are permitted. - - - (\+|-)?\d+(\.\d+)?(cm|mm|in|pt|pc|px|vu)? - - - - - Measurement expressed relative to properties of the current font, in analogy to the - respective CSS length units. Unlike data.MEASUREMENTFONTUNSIGNED, only positive values are - allowed. - - - \d+(\.\d+)?(ch|em|ex)? - - - - - Measurement expressed relative to properties of the current font, in analogy to the - respective CSS length units. Unlike data.MEASUREMENTFONTUNSIGNED, both positive and negative values - are allowed. - - - (\+|-)?\d+(\.\d+)?(ch|em|ex)? - - - - - Measurements used for typographical features. Unlike data.MEASUREMENTTYPOGRAPHYSIGNED, only - positive values are allowed. - - - - - - - - - Measurements used for typographical features. Unlike data.MEASUREMENTTYPOGRAPHYSIGNED, both - positive and negative values are allowed. - - - - - - - - - Indication of melodic function, i.e., anticipation, lower neighbor, escape tone, - etc. - - - - Accented lower neighbor. - - - Anticipation. - - - Appogiatura. - - - Accented passing tone. - - - Arpeggio tone (chordal tone). - - - Arpeggio tone (7th added to the chord). - - - Accented upper neighbor. - - - Changing tone. - - - Chromatic lower neighbor. - - - Chord tone (i.e., not an embellishment). - - - Chord tone (7th added to the chord). - - - Chromatic upper neighbor. - - - Chromatic unaccented passing tone. - - - Escape tone. - - - Lower neighbor. - - - Pedal tone. - - - Repeated tone. - - - Retardation. - - - 2-3 retardation. - - - 7-8 retardation. - - - Suspension. - - - 4-3 suspension. - - - 9-8 suspension. - - - 7-6 suspension. - - - Upper neighbor. - - - Upper neighbor (7th added to the chord). - - - Unaccented passing tone. - - - Unaccented passing tone (7th added to the chord). - - - - - - Mensuration signs attribute values. - - - - Sign for tempus imperfectum. - - - Sign for tempus perfectum. - - - Sign for divisio ternaria. - - - Sign for divisio quaternaria. - - - Sign for divisio senaria imperfecta. - - - Sign for divisio senaria imperfecta. - - - Sign for divisio senaria gallica. - - - Sign for divisio senaria gallica. - - - Sign for divisio senaria perfecta. - - - Sign for divisio senaria perfecta. - - - Sign for divisio senaria ytalica. - - - Sign for divisio senaria ytalica. - - - Sign for divisio novenaria. - - - Sign for divisio octonaria. - - - Sign for divisio duodenaria. - - - - - - Contains an indication of how a meter signature should be rendered. - - - - Show only the number of beats. - - - The lower number in the meter signature is replaced by a note symbol. - - - Meter signature rendered using traditional numeric values. - - - Meter signature rendered using both the symbol and the traditional numeric values. - - - - - - Meter.sym attribute values for CMN. - - - - Common time; i.e., 4/4. - - - Cut time; i.e., 2/2. - - - Open time signature, i.e., Senza misura. See Gould pp. 611–615. - - - - - - MIDI channel number. One-based values must be followed by a lower-case letter "o". - - - 0|([1-9]|1[0-5])o?|16o - - - - - Tempo expressed as "beats" per minute, where "beat" is always defined as a quarter note, - *not the numerator of the time signature or the metronomic indication*. - - - 0 - - - - - Tempo expressed as microseconds per "beat", where "beat" is always defined as a quarter - note, *not the numerator of the time signature or the metronomic indication*. - - - - - - General MIDI instrument names. - - - - Acoustic Grand Piano, Program #0. - - - Bright Acoustic Piano, Program #1. - - - Electric Grand Piano, Program #2. - - - Honky-tonk Piano, Program #3. - - - Electric Piano 1, Program #4. - - - Electric Piano 2, Program #5. - - - Harpsichord, Program #6. - - - Clavi, Program #7. - - - Celesta, Program #8. - - - Glockenspiel, Program #9. - - - Music Box, Program #10. - - - Vibraphone, Program #11. - - - Marimba, Program #12. - - - Xylophone, Program #13. - - - Tubular Bells, Program #14. - - - Dulcimer, Program #15. - - - Drawbar Organ, Program #16. - - - Percussive Organ, Program #17. - - - Rock Organ, Program #18. - - - Church Organ, Program #19. - - - Reed Organ, Program #20. - - - Accordion, Program #21. - - - Harmonica, Program #22. - - - Tango Accordion, Program #23. - - - Acoustic Guitar (nylon), Program #24. - - - Acoustic Guitar (steel), Program #25. - - - Electric Guitar (jazz), Program #26. - - - Electric Guitar (clean), Program #27. - - - Electric Guitar (muted), Program #28. - - - Overdriven Guitar, Program #29. - - - Distortion Guitar, Program #30. - - - Guitar harmonics, Program #31. - - - Acoustic Bass, Program #32. - - - Electric Bass (finger), Program #33. - - - Electric Bass (pick), Program #34. - - - Fretless Bass, Program #35. - - - Slap Bass 1, Program #36. - - - Slap Bass 2, Program #37. - - - Synth Bass 1, Program #38. - - - Synth Bass 2, Program #39. - - - Violin, Program #40. - - - Viola, Program #41. - - - Cello, Program #42. - - - Contrabass, Program #43. - - - Tremolo Strings, Program #44. - - - Pizzicato Strings, Program #45. - - - Orchestral Harp, Program #46. - - - Timpani, Program #47. - - - String Ensemble 1, Program #48. - - - String Ensemble 2, Program #49. - - - SynthStrings 1, Program #50. - - - SynthStrings 2, Program #51. - - - Choir Aahs, Program #52. - - - Voice Oohs, Program #53. - - - Synth Voice, Program #54. - - - Orchestra Hit, Program #55. - - - Trumpet, Program #56. - - - Trombone, Program #57. - - - Tuba, Program #58. - - - Muted Trumpet, Program #59. - - - French Horn, Program #60. - - - Brass Section, Program #61. - - - SynthBrass 1, Program #62. - - - SynthBrass 2, Program #63. - - - Soprano Sax, Program #64. - - - Alto Sax, Program #65. - - - Tenor Sax, Program #66. - - - Baritone Sax, Program #67. - - - Oboe, Program #68. - - - English Horn, Program #69. - - - Bassoon, Program #70. - - - Clarinet, Program #71. - - - Piccolo, Program #72. - - - Flute, Program #73. - - - Recorder, Program #74. - - - Pan Flute, Program #75. - - - Blown Bottle, Program #76. - - - Shakuhachi, Program #77. - - - Whistle, Program #78. - - - Ocarina, Program #79. - - - Lead 1 (square), Program #80. - - - Lead 2 (sawtooth), Program #81. - - - Lead 3 (calliope), Program #82. - - - Lead 4 (chiff), Program #83. - - - Lead 5 (charang), Program #84. - - - Lead 6 (voice), Program #85. - - - Lead 7 (fifths), Program #86. - - - Lead 8 (bass + lead), Program #87. - - - Pad 1 (new age), Program #88. - - - Pad 2 (warm), Program #89. - - - Pad 3 (polysynth), Program #90. - - - Pad 4 (choir), Program #91. - - - Pad 5 (bowed), Program #92. - - - Pad 6 (metallic), Program #93. - - - Pad 7 (halo), Program #94. - - - Pad 8 (sweep), Program #95. - - - FX 1 (rain), Program #96. - - - FX 2 (soundtrack), Program #97. - - - FX 3 (crystal), Program #98. - - - FX 4 (atmosphere), Program #99. - - - FX 5 (brightness), Program #100. - - - FX 6 (goblins), Program #101. - - - FX 7 (echoes), Program #102. - - - FX 8 (sci-fi), Program #103. - - - Sitar, Program #104. - - - Banjo, Program #105. - - - Shamisen, Program #106. - - - Koto, Program #107. - - - Kalimba, Program #108. - - - Bag pipe, Program #109. - - - Fiddle, Program #110. - - - Shanai, Program #111. - - - Tinkle Bell, Program #112. - - - Agogo, Program #113. - - - Steel Drums, Program #114. - - - Woodblock, Program #115. - - - Taiko Drum, Program #116. - - - Melodic Tom, Program #117. - - - Synth Drum, Program #118. - - - Reverse Cymbal, Program #119. - - - Guitar Fret Noise, Program #120. - - - Breath Noise, Program #121. - - - Seashore, Program #122. - - - Bird Tweet, Program #123. - - - Telephone Ring, Program #124. - - - Helicopter, Program #125. - - - Applause, Program #126. - - - Gunshot, Program #127. - - - Acoustic Bass Drum, Key #35. - - - Bass Drum 1, Key #36. - - - Side Stick, Key #37. - - - Acoustic Snare, Key #38. - - - Hand Clap, Key #39. - - - Electric Snare, Key #40. - - - Low Floor Tom, Key #41. - - - Closed Hi Hat, Key #42. - - - High Floor Tom, Key #43. - - - Pedal Hi-Hat, Key #44. - - - Low Tom, Key #45. - - - Open Hi-Hat, Key #46. - - - Low-Mid Tom, Key #47. - - - Hi-Mid Tom, Key #48. - - - Crash Cymbal 1, Key #49. - - - High Tom, Key #50. - - - Ride Cymbal 1, Key #51. - - - Chinese Cymbal, Key #52. - - - Ride Bell, Key #53. - - - Tambourine, Key #54. - - - Splash Cymbal, Key #55. - - - Cowbell, Key #56. - - - Crash Cymbal 2, Key #57. - - - Vibraslap, Key #58. - - - Ride Cymbal 2, Key #59. - - - Hi Bongo, Key #60. - - - Low Bongo, Key #61. - - - Mute Hi Conga, Key #62. - - - Open Hi Conga, Key #63. - - - Low Conga, Key #64. - - - High Timbale, Key #65. - - - Low Timbale, Key #66. - - - High Agogo, Key #67. - - - Low Agogo, Key #68. - - - Cabasa, Key #69. - - - Maracas, Key #70. - - - Short Whistle, Key #71. - - - Long Whistle, Key #72. - - - Short Guiro, Key #73. - - - Long Guiro, Key #74. - - - Claves, Key #75. - - - Hi Wood Block, Key #76. - - - Low Wood Block, Key #77. - - - Mute Cuica, Key #78. - - - Open Cuica, Key #79. - - - Mute Triangle, Key #80. - - - Open Triangle, Key #81. - - - - -

Instrument names are based on the official list in the General MIDI Specifications.

-

MEI uses 0-based program numbers.

-

Percussion sounds are available when the MIDI channel is set to "10".

- - - - Generic MIDI value. One-based values must be followed by a lower-case letter "o". - - - 0|([1-9]|[1-9][0-9]|1([0-1][0-9]|2[0-7]))o?|128o - - - - - data.MIDIVALUE or data.NCName values. - - - - - - - - - data.MIDIVALUE or data.PERCENT.LIMITED.SIGNED values. - - - - - - - - - data.MIDIVALUE or data.PERCENT.LIMITED values. - - - - - - - - - Modes. - - - - - - - - - - Common modes. - - - - Major mode. - - - Minor mode. - - - - - - Gregorian modes. - - - - Dorian mode (the first mode). - - - Hypodorian mode (the second mode). - - - Phrygian mode (the third mode). - - - Hypophrygian mode (the fourth mode). - - - Hypolydian mode (the fifth mode). - - - Lydian mode (the sixth mode). - - - Mixolydian mode (the seventh mode). - - - Hypomixolydian mode (the eighth mode). - - - Tonus peregrinus (the ninth mode). - - - - - - Modern modes. - - - - Ionian mode. - - - Hypoionian mode. - - - Aeolian mode. - - - Hypoaeolian mode. - - - Locrian mode. - - - Hypolocrian mode. - - - - - - Bibliographic relationship values based on MODS version 3.4. - - - - Temporal predecessor of the resource. - - - Temporal successor to the resource. - - - Original form of the resource. - - - Parent containing the resource. - - - Intellectual or physical component of the resource. - - - Version of the resource’s intellectual content not changed enough to be a different - work. - - - Version of the resource in a different physical format. - - - Published bibliographic description, review, abstract, or index of the resource's - content. - - - Cited or referred to in the resource. - - - - - - Maxima-long relationship values. - - - 2 - 3 - - - - - Long-breve relationship values. - - - 2 - 3 - - - - - Music font family. - - - - - - "Convenience" datatype that permits combining enumerated values with a user-supplied - name. - - - - - - "Convenience" datatype that permits combining enumerated values with user-supplied - values. - - - - - - Non-staff location. - - - - At the foot of the page. - - - At the top of the page. - - - At the left of the page. - - - At the right of the page. - - - On the opposite, i.e., facing, page. - - - On the other side of the leaf. - - - At the end of this division; e.g., chapter, volume, etc. - - - Within a line text; i.e., an insertion. - - - Between the lines of text, less exact than "sub" or "super". - - - Above a line of text, more exact than "intra(linear)". Do not confuse with - superscript rendition. - - - Below a line of text, more exact than "intra(linear)". Do not confuse with subscript - rendition. - - - In a predefined space; i.e., that left by an earlier scribe. - - - Obscures original text; e.g., via overstrike, addition of new writing surface - material, etc. - - - - - - Notation type and subtype - - - - Common Music Notation. - - - Mensural notation. - - - Black mensural notation. - - - White mensural notation. - - - Neumatic notation. - - - - Tablature notation. - - - - - - Captures any notehead "modifiers"; that is, symbols added to the notehead, such as - slashes, lines, text, and enclosures, etc. - - - - - - - - - Enumerated note head modifier values. - - - - Slash (upper right to lower left). - - - Backslash (upper left to lower right). - - - Vertical line. - - - Horizontal line. - - - Center dot. - - - Enclosing parentheses. - - - Enclosing square brackets. - - - Enclosing box. - - - Enclosing circle. - - - Enclosing "fences". - - - - - - Captures text rendered in the center of the notehead. - - - - centertext\((A|B|C|D|E|F|G)(f|♭|n|♮|s|♯)?\) - - - centertext\(H(s|♯)?\) - - - - - - Octave number. The default values conform to the Scientific Pitch Notation (SPN). - - - 9 - - - - - The amount of octave displacement; that is, '8' (as in '8va' for 1 octave), '15' (for 2 - octaves), or rarely '22' (for 3 octaves). - - - 8|15|22 - - - - - Rotation or reflection of base symbol values. - - - reversed|90CW|90CCW - - - - - For musical material designated to appear on an adjacent layer or staff, the location of the layer - relative to the current one; i.e., the layer above or the layer below. - - - - The layer immediately above. - - - The layer immediately below. - - - - - - The number of panels per page. - - - 1 - 2 - - - - - Styling of piano pedal marks. - - - - Continuous line with start and end positions rendered by vertical bars and bounces - shown by upward-pointing "blips". - - - Pedal down and half pedal rendered with "Ped." followed by a line with - end position rendered by vertical bars and bounces shown by upward-pointing "blips". - - - Pedal down and half pedal rendered with "Ped.", pedal up rendered by "*", pedal - "bounce" rendered with "* Ped.". - - - Pedal up and down indications same as with "pedstar", but bounce is rendered with - "Ped." only. - - - - - - Positive decimal number plus '%', i.e., [0-9]+(\.[0-9]*)?%. - - - [0-9]+(\.[0-9]*)?% - - - - - Decimal number between 0 and 100, followed by a percent sign "%". - - - (([0-9]|[1-9][0-9])(\.[0-9]*)?|100(\.0*)?)% - - - - - Decimal number between -100 and 100, followed by a percent sign "%". - - - (\+|-)?(([0-9]|[1-9][0-9])(\.[0-9]*)?|100(\.0*)?)% - - - - - Page header and footer function; a value that defines the function (i.e., the placement) of the header or the footer. - - - - Header or footer for all pages, including the first and the last page, unless a page header or footer for the first or the last page is provided. - - - Header or footer for the first page only. - - - Header or footer for the last page only. - - - The first of an alternating pattern of headers or footers. - - - The second of an alternating pattern of headers or footers. - - - - -

An alternating pattern with "alt1" and "alt2" starts from the first page. However, if header or footer with a func="first" is also defined, it will shift the pattern by one page. A header or footer with func="last" will interupt the pattern.

- - - - Page scale factor; a percentage of the values in page.height and page.width. - - - - - - - - Pclass (pitch class) attribute values. - - - 11 - - - - - The pitch names (gamut) used within a single octave. The default values conform to - Acoustical Society of America representation. - - - [a-g] - - - - - Gestural pitch names need an additional value for when the notated pitch is not to be - sounded. - - - [a-g]|none - - - - - Pnum (pitch number, e.g., MIDI) attribute values. - - - - - - Location information. - - - - - - - - - - - Other values not permitted when 'above', 'below', 'between' or 'within' is - present. - - - - - - Semibreve-minim relationship values. - - - 2 - 3 - - - - - - General-purpose relationships - - - - - - - - - - Rotation. - - - - - - - - - Rotation term. - - - - No rotation. - - - Rotated 180 degrees. - - - Rotated 270 degrees clockwise. - - - Rotated 45 degrees clockwise. - - - Rotated 315 degrees clockwise. - - - Rotated 135 degrees clockwise. - - - Rotated 225 degrees clockwise. - - - - - - Scale degree values. - - - (\^|v)?[1-7](\+|\-)? - - - - - The number of slashes to be rendered for tremolandi. - - - 1 - 6 - - - - - i=initial, m=medial, t=terminal. Number is used to match endpoints of the slur when slurs - are nested or overlap. - - - [i|m|t][1-6] - - - - - - - - - - - - Items that may be printed above, below, or between staves. - - - - - - - - - - - Items in all repertoires that may be printed near a staff. - - - - Accidentals. - - - Annotations. - - - Articulations. - - - Directives. - - - Dynamics. - - - Harmony indications. - - - Ornaments. - - - - - Spoken text. - - - Stage directions. - - - Tempo markings. - - - - - - Staff location. The value 0 indicates the bottom line of the current staff; positive - values are used for positions above the bottom line and negative values for the positions - below. For example, in treble clef, 1 = F4, 2 = G4, 3 = A4, etc. and -1 = D4, -2 = C4, and so - on. - - - - - - Location of musical material relative to a staff. - - - - - - - - - - The @staff - attribute must contain 2 numerically-adjacent integer values. - - - - Staves and - are not adjacent. - - - - - - Location of symbol relative to a staff. - - - - Above the staff. - - - Below the staff. - - - - - - Location of symbol relative to a staff. - - - - Between staves. - - - Within/on the staff. - - - - - - Stem direction. - - - - - - - - - Common stem directions. - - - - Stem points upwards. - - - Stem points downwards. - - - - - - Additional stem directions. - - - - Stem points left. - - - Stem points right. - - - Stem points up and right. - - - Stem points down and right. - - - Stem points up and left. - - - Stem points down and left. - - - - - - Stem modification. - - - - No modifications to stem. - - - 1 slash through stem. - - - 2 slashes through stem. - - - 3 slashes through stem. - - - 4 slashes through stem. - - - 5 slashes through stem. - - - 6 slashes through stem. - - - X placed on stem. - - - Z placed on stem. - - - - - - Position of a note’s stem relative to the head of the note. - - - - Stem attached to left side of note head. - - - Stem attached to right side of note head. - - - Stem is originates from center of note head. - - - - - - In string tablature, the number of the string to be played, i.e., [1-9]+. - - - - - - Temperament or tuning system. - - - - Equal or 12-tone temperament. - - - Just intonation. - - - Meantone intonation. - - - Pythagorean tuning. - - - - - - Beats (meter signature denominator) per minute, e.g., 120. - - - - - - Breve-semibreve relationship values. - - - 2 - 3 - - - - - Closed list of text rendition values. - - - - Surrounded by single quotes. - - - Surrounded by double quotes. - - - Italicized (slanted to right). - - - Oblique (slanted to left). - - - Small capitals. - - - Relative font weight. - - - Relative font weight. - - - Relative font weight. - - - Enclosed in box. - - - Enclosed in ellipse/circle. - - - Enclosed in diamond. - - - Enclosed in triangle. - - - Struck through by '\' (back slash). - - - Struck through by '/' (forward slash). - - - Struck through by '-'; may be qualified to indicate multiple parallel lines, e.g., - line-through(2). - - - Not rendered, invisible. - - - Line above the text; may be qualified to indicate multiple parallel lines, e.g., - overline(3). - - - Use for deleted text fully or partially obscured by other text (such as 'XXXXX') or - musical symbols (such as notes, rests, etc.). - - - Struck through by '-'; equivalent to line-through; may be qualified to indicate - multiple parallel lines, e.g., strike(3). - - - Subscript. - - - Superscript. - - - Use for added text or musical symbols that fully or partially obscure text from an - earlier writing stage. - - - Underlined; may be qualified to indicate multiple parallel lines, e.g., - underline(2). - - - Crossed-out; equivalent to 'bslash' (\) plus 'fslash' (/); that is, a hand-written - 'X'; may be qualified to indicate multiple parallel lines, e.g., x-through(2). - - - Left-to-right (BIDI embed). - - - Right-to-left (BIDI embed). - - - Left-to-right (BIDI override). - - - Right-to-left (BIDI override). - - - - - - Parameterized text rendition values. - - - (underline|overline|line-through|strike|x-through)\(\d+\) - - - - - Text rendition values. - - - - - - - - - Tie attribute values: initial, medial, terminal. - - - [i|m|t] - - - - - A positive or negative offset from the value given in the tstamp attribute in terms of - musical time, i.e., beats[.fractional beat part]. - - - - - - Tuplet attribute values: initial, medial, terminal. - - - [i|m|t][1-6] - - - - - - - A Uniform Resource Identifier, see [RFC2396]. - - - - - - Data values for attributes that capture vertical alignment. - - - - Top aligned. - - - Middle aligned. - - - Bottom aligned. - - - Baseline aligned. - - - - - - A single "word" that contains only letters, digits, punctuation characters, or symbols. It - cannot contain whitespace. - - - (\p{L}|\p{N}|\p{P}|\p{S})* - - - - - Attributes that provide for classification of notation. - - - Contains classification of the notation contained or described by the element bearing - this attribute. - - - - - - Provides any sub-classification of the notation contained or described by the element, - additional to that given by its notationtype attribute. - - - - - - - An element with a notationsubtype attribute must have - a notationtype attribute. - - - - - - - - - - Analytical component declarations. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Indicates to what degree the harmonic label is supported by the notation. - - - The notation contains all the notes necessary for the harmonic label, e.g., the - notes "D F♯ A" for the harmonic label "D". - - - The harmonic label relies on notes implied, but not actually present, in the - notation, e.g., the notes "D F♯ C" for the harmonic label "D7". The note "A" is - missing from the notation, but can be implied. - - - - - - - Analytical domain attributes. - - - Attributes describing the harmonic function of a single pitch. - - - degree - Captures scale degree information using Humdrum **deg syntax -- an optional indicator - of melodic approach (^ = ascending approach, v = descending approach), a scale degree - value (1 = tonic ... 7 = leading tone), and an optional indication of chromatic - alteration, 1, v7, ^1, or v5+, for example. - The amount of chromatic alternation is not indicated. - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Attributes that describe harmonic intervals. - - - interval harmonic - Encodes the harmonic interval between pitches occurring at the same time. - - - - - - - - Attributes that provide for description of intervallic content. - - - interval melodic - Encodes the melodic interval from the previous pitch. The value may be a general - directional indication (u, d, s, etc.), an indication of diatonic interval direction, - quality, and size, or a precise numeric value in half steps. - - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the analytical - domain that are related to key signatures. - - - Contains an accidental for the tonic key, if one is required, e.g., if key.pname - equals c and key.accid equals s, then a tonic of C# is indicated. - - - - - - Indicates major, minor, or other tonality. - - - - - - Holds the pitch name of the tonic key, e.g., c for the key of C. - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Attributes describing melodic function. - - - Describes melodic function using Humdrum **embel syntax. - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes in the CMN repertoire. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes in the CMN repertoire. Use the n attribute to explicitly - encode this measure’s position in a string of measures containing only mRest elements. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - - - - - - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Attributes that describe pitch class. - - - pitch class - Holds pitch class information. - - - - - - - - Analytical domain attributes that describe the properties of a plica in the mensural repertoire. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Attributes that specify pitch using sol-fa. - - - pitch sol-fa - Contains sol-fa designation, e.g., do, re, mi, etc., in either a fixed or movable Do - system. - - - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes that describe the properties of a stem in the mensural repertoire. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - - Analytical domain attributes. - - - Analytical domain attributes. - - - Analytical domain attributes. - - - - - Common Music Notation (CMN) repertoire component declarations. - - - Logical, that is, written, duration attribute values for the CMN repertoire. - - - - Quadruple whole note. - - - Double whole note. - - - Whole note. - - - Half note. - - - Quarter note. - - - 8th note. - - - 16th note. - - - 32nd note. - - - 64th note. - - - 128th note. - - - 256th note. - - - 512th note. - - - 1024th note. - - - 2048th note. - - - - - - Items in the CMN repertoire that may be printed near a staff. - - - - Beams. - - - - - Bend indications. - - - Brackets, e.g., for transcribed ligatures. - - - Breath marks. - - - Copy marks. - - - Fermatas. - - - Fingerings. - - - - - Hairpin dynamics. - - - Harp pedals. - - - Laissez vibrer indications, sometimes called "open ties". - - - Mordents. - - - Octaviation marks. - - - Piano pedal marks. - - - Rehearsal marks. - - - - - Ties. - - - Trills. - - - Tuplets. - - - - - Turns. - - - - - - Logical domain attributes. - - - - - - - Describes the direction in which an arpeggio is to be performed. - - - Lowest to highest pitch. - - - Highest to lowest pitch. - - - Non-arpeggiated style (usually rendered with a preceding bracket instead of a wavy - line). - - - - - - - Logical domain attributes. - - - - - - - Attributes indicating cross-staff beaming. - - - In the case of cross-staff beams, the beam.with attribute is used to indicate which - staff the beam is connected to; that is, the staff above or the staff below. - - - - - - - - Used by layerDef, staffDef, and scoreDef to provide default values for attributes in the - logical domain related to beaming. - - - Provides an example of how automated beaming (including secondary beams) is to be - performed. - - - - - - Indicates whether automatically-drawn beams should include rests shorter than a - quarter note duration. - - - - - - -

The beam.group attribute can be used to set a default beaming pattern to be used - when no beaming is indicated at the event level. beam.group must contain a - comma-separated list of time values that add up to a measure, e.g., in 4/4 time '4,4,4,4' - indicates each quarter note worth of shorter notes would be beamed together. Parentheses can - be used to indicate sub-groupings of secondary beams. For example, '(4.,4.,4.)' in 9/8 meter - indicates one outer beam per measure with secondary beams broken at each dotted quarter - duration, while a measure of 16th notes in 4/4 with beam.group equal to - '(4,4),(4,4)' will result in a primary beam covering all the notes and secondary beams for - each group of 4 notes. This beaming "directive" can be overridden by using beam elements. If neither beam elements or the - beam.group attribute is used, then no beaming is rendered. Beaming can be - explicitly 'turned off' by setting beam.group to an empty string.

- - - - Attributes that indicate whether an event lies under a beam. - - - Indicates that this event is "under a beam". - - - - - - - - Attributes that record the visual rendition of beams. - - - Captures whether a beam is "feathered" and in which direction. - - - accelerando - means that the secondary beams become progressively more distant - toward the end of the beam. - - - mixed acc and rit - for beams that are "feathered" in both directions. - - - ritardando - indicates that the secondary beams get progressively closer together - toward the end of the beam. - - - normal - indicates that the secondary beams are equidistant along the course of - the beam. - - - - - Records the placement of the beam relative to the events it affects. - - - - - - - Stem directions should be specified for all notes and chords under the - beam. - Opposing stem directions are required for a beam with @place="mixed". - - - Opposing stem directions are required for a beam with @place="mixed". - - - - - - Indicates presence of slash through the beam. - - - - - - Records the slope of the beam. - - - - - - - - Attributes that capture information about secondary beaming. - - - Presence of this attribute indicates that the secondary beam should be broken - following this note/chord. The value of the attribute records the number of beams which - should remain unbroken. - - - - - - - - Logical domain attributes. - - - - - - - - - - Logical domain attributes. - - - - - - Indicates the performed duration represented by the beatRpt symbol; expressed in time - signature denominator units. - - - \d+(\.\d+)? - - - - - - - Logical domain attributes. - - - - - - - - - Logical domain attributes. - - - - - - - - - function - Describes the function of the bracketed event sequence. - - - - - - Represents coloration in the mensural notation source material. - - - Marks a sequence which does not match the current meter. - - - Represents a ligature in the mensural notation source material. - - - - - - - Logical domain attributes. - - - - - - - - - - - Logical domain attributes. - - - - - - - - - - Analytical domain attributes in the CMN repertoire. - - - - - - - - - - - - Gestural domain attributes for CMN features. - - - Logical domain attributes in the CMN repertoire. - - - - - - Visual domain attributes for chord. The slur, slur.dir, slur.rend, tie, tie.dir, and - tie.rend attributes here are "syntactic sugar" for these attributes on each of the chord's - individual notes. The values here apply to all the notes in the chord. If some notes are - slurred or tied while others aren't, then the individual note attributes must be used. - - - - - - Attributes that indicate how to render the staff lines of the measure containing an - element belonging to this attribute class. - - - "Cut-out" style. - - - The staff lines should not be drawn. - - - - - - - Logical domain attributes. - - - Attributes that indicate whether to render a repeat symbol or the source material to which - it refers. - - - Indicates whether to render a repeat symbol or the source material to which it refers. - A value of 'true' renders the source material, while 'false' displays the repeat - symbol. - - - - - - - - Logical domain attributes. - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that indicate whether an event participates in a glissando. - - - glissando - Indicates that this element participates in a glissando. If visual information about - the glissando needs to be recorded, then a gliss element should be - employed instead. - - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that mark a note or chord as a "grace", how it should "steal" time, and how - much time should be allotted to the grace note/chord. - - - Marks a note or chord as a "grace" (without a definite performed duration) and records - from which other note/chord it should "steal" time. - - - - - - Records the amount of time to be "stolen" from a non-grace note/chord. - - - - - - - - Logical domain attributes. - - - - - - - Records whether the grace note group is attached to the following event or to the - preceding one. The usual name for the latter is "Nachschlag". - - - Attached to the preceding event. - - - Attached to the following event. - - - Attachment is ambiguous. - - - - - - - Logical domain attributes. - - - - - - - - - Captures the visual rendition and function of the hairpin; that is, whether it - indicates an increase or a decrease in volume. - - - Crescendo; i.e., louder. - - - Diminuendo; i.e., softer. - - - - - Indicates that the hairpin starts from or ends in silence. Often rendered as a small - circle attached to the closed end of the hairpin. See Gould, p. 108. - - - - - - - - Logical domain attributes. - - - - - - - Logical domain attributes. The pedal setting, i.e., flat, natural, or sharp, for each - diatonic pitch name is indicated by the seven letter-named attributes. - - - - - - - Indicates the pedal setting for the harp’s C strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s D strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s E strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s F strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s G strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s A strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - Indicates the pedal setting for the harp’s B strings. - n - - - Flat. - - - Natural. - - - Sharp. - - - - - - - Logical domain attributes. - - - - - - Logical domain attributes. - - - - - - - - Attributes that indicate the presence of an l.v. (laissez vibrer) marking attached to a - feature. If visual information about the lv sign needs to be recorded, then an lv element should be employed. - - - Indicates the attachment of an l.v. (laissez vibrer) sign to this element. - - - - - - - - Logical domain attributes. The n attribute contains a name or number associated with the - measure (Read, p. 445). Often, this is an integer, but not always. For example, some measures, - especially incomplete measures or those under an ending mark, may have labels that contain an - integer plus a suffix, such as '12a'. Measures may even have labels, especially in editorial - or analytical uses of MEI, that are entirely non-numeric strings. Measure numbers may be - machine-generated instead of encoding them in the markup. However, an explicit measure number - should restart numbering with the given value. The join attribute may be used to indicate - another measure which metrically completes the current, incomplete one. - - - - - - - Indicates the visual rendition of the left bar line. It is present here only for - facilitation of translation from legacy encodings which use it. Usually, it can be safely - ignored. - - - - - - Indicates the function of the right bar line and is structurally important. - - - - - - - - Logical domain attributes. - - - function - Function of the meter signature group. - - - Meter signatures apply to alternating measures. - - - Meter signatures are interchangeable, e.g., 3/4 and 6/8. - - - Meter signatures with different unit values are used to express a complex metrical - pattern that is not expressible using traditional means, such as 2/4+1/8. - - - Meter signatures in a relationship not covered by the values alternating, interchanging or mixed. - - - - - - - Logical domain attributes. - - - - - - - - Logical domain attributes. - - - - - - - Logical domain attributes. - - - - - - Logical domain attributes in the CMN repertoire. - - - - - - - Logical domain attributes. - - - - - - - Logical domain attributes. - - - - - - - Analytical domain attributes in the CMN repertoire. - - - - - - - - - - - - - Logical domain attributes. - - - - - - Visual domain attributes. - - - - - - Attributes that record numbers to be displayed with a feature. - - - number - Records a number or count accompanying a notational feature. - - - - - - - - Attributes that record the placement and visibility of numbers that accompany a bowed - tremolo or tuplet. - - - number placement - States where the tuplet number will be placed in relation to the note heads. - - - - - - Determines if the tuplet number is visible. - - - - - - - - Logical domain attributes. - - - - - - - - - - Indicates whether the octave displacement should be performed simultaneously with the - written notes, i.e., "coll' ottava". Unlike other octave signs which are indicated by - broken lines, coll' ottava typically uses an unbroken line or a series of longer broken - lines, ending with a short vertical stroke. See Read, p. 47-48. - - - Coll' ottava (with the octave). - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - - - direction - Records the position of the piano damper pedal. - - - Depress the pedal. - - - Release the pedal. - - - Half pedal. - - - Release then immediately depress the pedal. - - - - - function - Indicates the function of the depressed pedal, but not necessarily the text associated - with its use. Use the dir element for such text. - - - - - - The sustain pedal, also referred to as the "damper" pedal, allows the piano - strings to vibrate sympathetically with the struck strings. It is the right-most and - the most frequently used pedal on modern pianos. - - - The soft pedal, sometimes called the "una corda", "piano", or "half-blow" pedal, - reduces the volume and modifies the timbre of the piano. On the modern piano, it is - the left-most pedal. - - - The sostenuto or tone-sustaining pedal allows notes already undamped to continue - to ring while other notes are damped normally; that is, on their release by the - fingers. This is usually the center pedal of the modern piano. - - - The silent or practice pedal mutes the volume of the piano so that one may - practice quietly. It is sometimes a replacement for the sostenuto pedal, especially on - an upright or vertical instrument. - - - - - - - Visual domain attributes. - - - - - - - Used by scoreDef and staffDef to provide default description of piano pedal - rendition. - - - Determines whether piano pedal marks should be rendered as lines or as terms. - - - - - - - - Logical domain attributes. - - - - - - - - - - - Attributes used by scoreDef and staffDef to provide default information about rehearsal - numbers/letters. - - - Describes the enclosing shape for rehearsal marks. - - - Enclosed by box. - - - Enclosed by circle. - - - No enclosing shape. - - - - - - - Analytical domain attributes in the CMN repertoire. - - - - - - - - Logical domain attributes in the CMN repertoire. - - - Visual domain attributes. - - - - - - Logical domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that describe the rendition of slurs. - - - - - - - - - - - - - - - Analytical domain attributes in the CMN repertoire. - - - - - - - - Logical domain attributes in the CMN repertoire. - - - Logical domain attributes for staffDef in the CMN repertoire. - - - - - - Visual domain attributes for staffDef in the CMN repertoire. - - - - - - - - - - Attributes that describe the properties of stemmed features; that is, chords and - notes. - - - Contains an indication of which staff a note or chord that logically belongs to the - current staff should be visually placed on; that is, the one above or the one - below. - - - - - - - - Logical domain attributes. - - - - - - - - Attributes that describe the rendition of ties. - - - - - - - - - - - - - - - Attributes describing the form of a tremolo. - - - Describes the style of the tremolo. - - - Measured tremolo. - - - Unmeasured tremolo. - - - - - - - Attributes that describe measured tremolandi. - - - The performed duration of an individual note in a measured tremolo. - - - - - - - - Logical domain attributes. - - - - - - - - - - Logical domain attributes. - - - - - - - - - - - Groups control events that appear in CMN. - - - - - - - - Groups events that appear in CMN. - - - - - - Groups events that completely fill a CMN measure. - - - - - - Groups notated events that may appear at the layer level in CMN. - - - - - - Groups CMN measure-like elements. - - - - - - Groups elements that may appear within a CMN measure. - - - Groups elements that function like ossia. - - - - - - - Groups elements that may appear as part of a section. - - - - - - arpeggiation - Indicates that the notes of a chord are to be performed successively - rather than simultaneously, usually from lowest to highest. Sometimes called a "roll". - - - - - - - - - - - - - -

The modern arpeggiation symbol is a vertical wavy line preceding the chord. When the notes - of the chord are to be performed from highest to lowest, an arrowhead may be added to the - lower end of the line. Even though it is redundant, an arrowhead is sometimes added to the - upper end of the line for the sake of consistency or when the direction of successive - arpeggios alternates. In music for keyboard instruments, sometimes a distinction is made - between a single arpeggio in which both hands play successively and simultaneous arpeggios - in two hands. In the case of the former, multiple values may be required in the - staff and layer attributes. Arpeggios that do not cross staves, but - still involve more than one layer require multiple values for the layer - attribute.

- - - - An instruction to begin the next section or movement of a composition without - pause. - - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

As a specialized directive, attacca is a control element. That is, it - can be linked via its attributes to other events. The starting point of the attacca - directive may be indicated by either a startid, tstamp, - tstamp.ges, or tstamp.real attribute, while the ending point may be - recorded by either a dur, dur.ges, endid, or - tstamp2 attribute. It is a semantic error not to specify a starting point - attribute.

- - - - A container for a series of explicitly beamed events that begins and ends entirely within - a measure. - - - - - - - - - - - - - - - - - - - - - - - - A beam that contains neither a copyof nor sameas attribute must have at least 2 note, rest, chord, or space - descendants. - - - - -

For beams that cross the bar line, use the beamSpan element. - Secondary beams may be broken explicitly using the breaksec attribute on the - notes or chords under the beam. Automated beaming, as opposed to explicitly marked beams, - may be indicated for an entire score, part or section by using the beam.group and - beam.rests attributes on these elements.

- - - - beam span - Alternative element for explicitly encoding beams, particularly those which - extend across bar lines. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

The starting point of the beam may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify one - starting and one ending type of attribute.

- - - - beat repeat - An indication that material on a preceding beat should be repeated. - - - - - - - - - - - - - - - -

beatRpt may also be used in guitar or rhythm parts to indicate where - chord changes occur. When these parts require durations longer or shorter than a beat; - however, note elements with appropriately-shaped note heads should be - employed.

- - - - A variation in pitch (often micro-tonal) upwards or downwards during the course of a - note. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - - - Marks a sequence of notational events grouped by a bracket. - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

Text that interrupts the bracket used to mark the event group may be captured as the - content of bracketSpan. The starting point of the group/bracket may be - indicated by either a startid, tstamp, tstamp.ges, or - tstamp.real attribute, while the ending point may be recorded by either a - dur, dur.ges, endid, or tstamp2 attribute. It is - a semantic error not to specify one starting and one ending type of attribute.

- - - - breath mark - An indication of a point at which the performer on an instrument requiring - breath (including the voice) may breathe. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

This element may also indicate a short pause or break for instruments *not* requiring - breath. In such cases, it functions as a guide to phrasing. The starting point of the breath - mark may be indicated by either a startid, tstamp, - tstamp.ges, or tstamp.real attribute. It is a semantic error not to - specify a starting point attribute.

-

Since the breath mark does not disrupt the normal tempo of a performance, it has no - directly encode-able duration.

-

The default value for place for a breath mark is "above". Unless indicated by - other attributes, a breath mark will be rendered as a comma-like symbol above the top line - of the staff.

- - - - bowed tremolo - A rapid alternation on a single pitch or chord. - - - - - - - - - - - - - - - - - - An indication placed over a note or rest to indicate that it should be held longer than - its written value. May also occur over a bar line to indicate the end of a phrase or section. - Sometimes called a 'hold' or 'pause'. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The shape attribute may be used to record whether the fermata is curved, square, - or triangular, while form may be used to capture whether the fermata is - "upright", i.e., has the curve or bracket above the dot, or inverted, i.e., has the curve or - bracket below the dot. Other visual forms of a fermata may be indicated via the - altsym attribute. The starting point of the fermata may be indicated by either a - startid, tstamp, tstamp.ges, or tstamp.real - attribute. It is a semantic error not to specify a starting point attribute.

- - - - fingered tremolo - A rapid alternation between a pair of notes (or chords or perhaps - between a note and a chord) that are (usually) farther apart than a major second. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - glissando - A continuous or sliding movement from one pitch to another, usually - indicated by a straight or wavy line. - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

Commonly also called a 'slide'. The term 'glissando' is frequently used to indicate both - the case where distinct intermediate pitches are produced (as on the piano) and the case - where they are not (as on the trombone), though the latter is sometimes referred to as - 'portamento'. The visual appearance of the indicating line may be recorded in the - lform and lwidth attributes. The starting point of the glissando may - be indicated by either a startid, tstamp, tstamp.ges, or - tstamp.real attribute, while the ending point may be recorded by either a - dur, dur.ges, endid, or tstamp2 attribute. It is - a semantic error not to specify one starting and one ending type of attribute.

- - - - grace group - A container for a sequence of grace notes. - - - - - - - - - - - - - - - - - - - - - - - - A graceGrp without a copyof attribute must have at least 1 note, rest, chord, or space - descendants. - - - - - - - The grace attribute is not allowed on - descendants of a graceGrp with a grace attribute. - - - - - - Indicates continuous dynamics expressed on the score as wedge-shaped graphics, e.g., < - and >. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

The hairpin element is used for graphical, i.e., - crescendo and diminuendo, dynamic markings. For instantaneous or continuous - textual dynamics, such as 'p', 'mf', or 'cres. poco a poco', the dynam element should be used. The starting point of the hairpin marking - may be indicated by either a startid, tstamp, tstamp.ges, - or tstamp.real attribute, while the ending point may be recorded by either a - dur, dur.ges, endid, or tstamp2 attribute. It is - a semantic error not to specify one starting and one ending type of attribute. MIDI values - associated with the graphical dynamic sign may be recorded in the val and - val2 attributes.

- - - - half-measure repeat - A half-measure repeat in any meter. - - - - - - - - - - - - - - - harp pedal - Harp pedal diagram. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The starting point of the harp pedal diagram may be indicated by either a - tstamp, tstamp.ges, tstamp.real or startid - attribute. It is a semantic error not to specify a starting point attribute.

- - - - laissez vibrer - A "tie-like" indication that a note should ring beyond its written duration. - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - The visual attributes of the lv element (@bezier, @bulge, @curvedir, - @lform, @lwidth, @ho, @startho, @endho, @to, @startto, @endto, @vo, @startvo, @endvo, - @x, @y, @x2, and @y2) will be overridden by visual attributes of the contained curve - elements. - - - - -

The lv element captures the graphical, "tie-like" symbol. Any associated text, such as - "l.v.", must be captured using a dir element.

- - - - Unit of musical time consisting of a fixed number of note values of a given type, as - determined by the prevailing meter, and delimited in musical notation by bar lines. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

In MEI, the measure element is a grouping mechanism for events and - control events. Pointing attributes make it possible to connect this element to other - internal or external entities, such as media objects or annotations. The width - attribute may be used to capture the width of the measure for interchange with music - printing systems that utilize this information for printing.

- - - - meter signature - Written meter signature. - - - - - - - - - - - - - - - meter signature group - Used to capture alternating, interchanging, mixed or other non-standard meter signatures. - - - - - - - - - - - - - - - - - - meterSigGrp must have at least 2 child - meterSig elements. - - - - - - measure number - Designation, name, or label for a measure, often but not always - consisting of digits. Use this element when the n attribute on measure does not adequately capture the appearance or placement of the measure - number/label. - - - - - - - - - - - - - - - - - - - -

mNum uses a subset of model.textPhraseLike.limited.

- - - - measure rest - Complete measure rest in any meter. - - - - - - - - - - - - - -

Automatically-generated numbering of consecutive measures of rest may be controlled via the - multi.number attribute on the scoreDef or staffDef elements.

- - - - measure repeat - An indication that the previous measure should be repeated. - - - - - - - - - - - - - -

The automated numbering of consecutive measures of rest may be controlled via the - multi.number attribute on the scoreDef or staffDef elements.

- - - - 2-measure repeat - An indication that the previous two measures should be - repeated. - - - - - - - - - - - - - - - measure space - A measure containing only empty space in any meter. - - - - - - - - - - - - - -

The automated numbering of consecutive measures of space may be controlled via the - multi.number attribute on the scoreDef or staffDef elements.

- - - - multiple rest - Multiple measures of rest compressed into a single symbol, frequently - found in performer parts. - - - - - - - - - - - - - - - - multiple repeat - Multiple repeated measures. - - - - - - - - - - - - - -

In modern publishing practice, repeats of more than two measures should be written out - using repeat signs. This element, however, is provided for handling non-standard practices - often found in manuscript. The num attribute records the number of measures to be - repeated.

- - - - An indication that a passage should be performed one or more octaves above or below its - written pitch. - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

The dis and dis.place attributes record the amount and direction of - displacement, respectively. The lform and lwidth attributes capture - the appearance of the continuation line associated with the octave displacement. The - starting point of the octave displacement may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify one - starting and one ending type of attribute. Also, note that the dur attribute is - not required because the octave displacement can be visually instantaneous.

- - - - ossia layer - A layer that contains an alternative to material in another layer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Captures original notation and a differently notated version *present in - the source being transcribed*. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - In a measure, ossia - may only contain staff and oStaff elements. - - - In a staff, ossia - may only contain layer and oLayer elements. - - - - - -

The alternative material in an ossia often provides a simpler, easier-to-perform option, - while at other times the alternate material provides indications of performance practice, - such as ornamentation. Often an ossia is rendered above the main staff on a reduced-size - staff. Sometimes the alternate material occurs on the same staff as the primary text, but in - a separate layer. In this case, the alternative material is often rendered in small-sized - notation.

- - - - ossia staff - A staff that holds an alternative passage which may be played instead of - the original material. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Piano pedal mark. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The starting point of the pedal mark may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute. It is a - semantic error not to specify one of these attributes.

- - - - rehearsal mark - In an orchestral score and its corresponding parts, a mark indicating a - convenient point from which to resume rehearsal after a break. - - - - - - - - - - - - - - - - - - - - -

It may also be called a "rehearsal figure", or when numbers are used instead of letters, a - "rehearsal number". See Read, p. 443. reh uses a subset of - model.textPhraseLike.limited.

- - - - repetition mark - - An instruction expressed as a combination of text and symbols – segno and coda – typically above, - below, or between staves, but not on the staff. - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - When @glyph.name or @glyph.num is present, repeatMark must not have content. - - - - -

When only func is provided to describe the function of the repeat mark (i.e., without glyph information and no textual content), then a renderer - can rely on it to display the appropriate symbol. When textual content is provided, it will take precedence over the symbol implied by the function. Generic repeat marks where - no function can be determined, then generic dir elements should be used. -

- - - - Indication of 1) a "unified melodic idea" or 2) performance technique. - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - - - - The visual attributes of the slur (@bezier, @bulge, @curvedir, @lform, - @lwidth, @ho, @startho, @endho, @to, @startto, @endto, @vo, @startvo, @endvo, @x, @y, - @x2, and @y2) will be overridden by visual attributes of the contained curve - elements. - - - - -

Historically, the term "slur" indicated two notes performed legato, while the term "phrase" - was used for a "unified melodic idea". Nowadays, however, "slur" often has the same meaning - as "phrase" (See Read, p. 265-266), since the visual rendition of the two concepts is the - same. MEI provides two distinct elements so that those users wishing to maintain a - distinction for historical reasons may do so. If the user does not want to maintain the - distinction, then the more generic slur element should be employed. - The starting point of the phrase/slur may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify one - starting and one ending type of attribute. Either place, bulge, or - bezier attributes may be used to record the curvature of the phrase/slur. The slur and tie elements may be used instead of the - slur.* and tie.* attributes provided on chord and note elements when 1) they are required by software, or 2) multiple, alternative slurs - are needed.

- - - - An indication that two notes of the same pitch form a single note with their combined - rhythmic values. - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - - - - The visual attributes of the tie (@bezier, @bulge, @curvedir, @lform, - @lwidth, @ho, @startho, @endho, @to, @startto, @endto, @vo, @startvo, @endvo, @x, @y, - @x2, and @y2) will be overridden by visual attributes of the contained curve - elements. - - - - -

Most often, a tie is rendered as a curved line connecting the two notes. See Read, p. - 110-111, 122.

- - - - A group of notes with "irregular" (sometimes called "irrational") rhythmic values, for - example, three notes in the time normally occupied by two or nine in the time of five. - - - - - - - - - - - - - - - - - - - - - -

The beam sub-element is allowed so that custom beaming may be - indicated, e.g., a septuplet may be divided into a group of three plus a group of four - notes. See Read, p. 187-215. The tuplet element may also used for - bowed tremolo (Read, p. 394) and double, triple, or flutter tonguing (Read, p. 348-349); - that is, for repetition of the same pitch. In the case of irrational durations, such as such - as two quarter notes in the time of five 8th notes in a measure of 5/8 time, decimal values - may be used in the dur.ges attribute. For example, the dur.ges - attribute would take the value 2.5 if the midi.div attribute’s value was 1. - The num and numbase attributes may be used for explicit labelling of a - tuplet, such as, '3' with an 8th-note triplet, '3:2' over a quarter-note triplet, etc. The - rendering of the ratio, however, is dependent on the num.format attribute found - in the att.vis.tuplet attribute class.

- - - - tuplet span - Alternative element for encoding tuplets, especially useful for tuplets - that extend across bar lines. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - -

The starting point of the tuplet may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify one - starting and one ending type of attribute.

- - - - - - CMN ornament component declarations. - - - CMN ornam attribute values: A = appogiatura (upper neighbor); a = acciaccatura (lower - neighbor); b = bebung; I = ascending slide; i = descending slide; k = delayed turn; K = 5-note - turn; m = mordent (alternation with lower neighbor); M = inverted mordent (alternation with - upper neighbor); N = Nachschlag (upper neighbor); n = Nachschlag (lower neighbor); S = turn; s - = inverted turn; t = trill commencing on auxiliary note; T = trill commencing on principal - note; O = generic / unspecified ornament. - - - [A|a|b|I|i|K|k|M|m|N|n|S|s|T|t|O]|(A|a|S|s|K|k)?(T|t|M|m)(I|i|S|s)? - - - - - Logical domain attributes. - - - - - - - - Records semantic meaning, i.e., intended performance, of the mordent. The - altsym, glyph.name, or glyph.num attributes may be used - to specify the appropriate symbol. - - - Starts with the written note, followed by its lower neighbor, with a return to the - written note. In modern practice, this is called an "inverted mordent" and indicated - by a short wavy line with a vertical line through it. - - - Starts with the written note, followed by its upper neighbor, with a return to the - principal note. In modern practice, the symbol lacks the vertical line used for the - inverted form. - - - - - When set to 'true', a double or long mordent, sometimes called a "pincé double", - consisting of 5 notes, is indicated. - - - - - - - - Accidentals associated with ornaments. - - - - - - Records the written accidental associated with an upper neighboring note. - - - - - - Records the written accidental associated with a lower neighboring note. - - - - - - - - Attributes for marking the presence of an ornament. - - - ornament - Indicates that this element has an attached ornament. If visual information about the - ornament is needed, then one of the elements that represents an ornament (mordent, trill, - or turn) should be employed. - - - - - - - - Logical domain attributes. - - - - - - - - - - Logical domain attributes. - - - - - - - - When set to 'true', the turn begins on the second half of the beat. - - - - - - Records meaning; i.e., intended performance, of the turn. The altsym, - glyph.name, or glyph.num attributes may be used to specify the - appropriate symbol. - - - Begins on the note below the written note. - - - Begins on the note above the written note. - - - - - - - Groups CMN ornament elements. - - - - - - An ornament indicating rapid alternation of the main note with a secondary note, usually a - step below, but sometimes a step above. - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The starting point of the mordent may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute. It is a - semantic error not to specify one of these attributes.

- - - - Rapid alternation of a note with another (usually at the interval of a second - above). - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The interval between the main and auxiliary notes is usually understood to be diatonic - unless altered by an accidental. The starting note of the trill; i.e., the written one or - the ornamenting one, and the speed of alternation depends on performance practice. The - starting point of the trill may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify a - starting point attribute.

- - - - An ornament consisting of four notes — the upper neighbor of the written note, the written - note, the lower neighbor, and the written note. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

See Read, p. 246-247. Whether the turn is accented or unaccented may be inferred from the - timestamp — accented turns occur directly on the affected beat, unaccented ones do not.

- - - - - - Corpus component declarations. - - - Groups elements that may be document elements when the corpus module is invoked. - - - MEI corpus - A group of related MEI documents, consisting of a header for the group, and - one or more mei elements, each with its own complete header. - - - - - - - - - - - - -

The model of this element is based on the teiCorpus element of the Text Encoding Initiative (TEI). The MEI instances making up the corpus may be related in a number of ways, for - example, by composer, by similar instrumentation, by holding institution, etc. This - element’s name should not be changed in order to assure an absolute minimum level of MEI - compliance.

- - - - - - Critical apparatus component declarations. - - - Attributes common to all elements representing variant readings. - - - - - - - - Classifies the cause for the variant reading, according to any appropriate typology of - possible origins. - - - - - - - - Logical domain attributes. - - - Groups elements that contain a critical apparatus entry. - - - Groups elements that may appear as part of a textual or musical variant. - - - Groups elements that may appear as part of a musical variant. - - - - - - Groups elements that may appear as part of a textual variant. - - - - - - apparatus - Contains one or more alternative encodings. - - - - - - - - - - - - - - -

The alternatives provided in lem and/or rdg - sub-elements may be thought of as exclusive or as parallel. The type attribute - may contain any convenient descriptive word, describing the extent of the variation (e.g., - note, phrase, measure, etc.), its text-critical significance (e.g., significant, accidental, - unclear), or the nature of the variation or the principles required to understand it (e.g., - lectio difficilior, usus auctoris, etc.).

- - -

The model of this element is based on the app element of the Text Encoding Initiative (TEI).

- - - - lemma - Contains the lemma, or base text, of a textual variation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The lem element may also be used, under some circumstances, to record - the base text of the source edition, to mark the readings of a base witness, to indicate the - preference of an editor or encoder for a particular reading, or to make clear, in cases of - ambiguity, precisely which portion of the main text the variation applies to. Those who - prefer to work without the notion of a base text may prefer not to use it at all. An integer - indicating the position of this reading in a sequence, when there is reason to presume a - sequence of the variant readings, may be captured in the seq attribute.

-

In no case should lem contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, lem - should only contain those elements allowed within verse.

- - -

The model of this element is based on the lem element of the Text Encoding Initiative (TEI).

- - - - reading - Contains a single reading within a textual variation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Since a reading can be a multi-measure section, the scoreDef element - is allowed so that a reading may have its own meta-data without incurring the overhead of - child section elements. The app sub-element is - permitted in order to allow nested sub-variants.

- - -

In no case should rdg contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, rdg - should only contain those elements allowed within verse.

- - -

The model of this element is based on the rdg element of the Text Encoding Initiative (TEI).

- - - - - - Dramatic text component declarations. - - - Logical domain attributes. - - - - - - - - Logical domain attributes. - - - - - - - - Groups elements containing stage directions in performance texts. - - - - - - - speech - Contains an individual speech in a performance text. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - Must not have any of the attributes: startid, endid, tstamp, tstamp2, tstamp.ges, - tstamp.real, startho, endho, to, startto, endto, staff, layer, place, or - plist. - - - - -

In a musical context sp must have a start-type attribute when it's - not a descendant of sp. In a textual content sp - must NOT have any musical attributes.

- - -

The model of this element is based on the sp element of the Text Encoding Initiative (TEI).

- - - - stage direction - Contains any kind of stage direction within a dramatic text or - fragment. - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - Must not have any of the attributes: startid, endid, tstamp, tstamp2, tstamp.ges, - tstamp.real, startho, endho, to, startto, endto, staff, layer, place, or - plist. - - - - -

In a musical context stageDir must have a start-type attribute when - it’s not a descendant of sp. In a textual content stageDir must NOT have any musical attributes.

- - -

The model of this element is based on the stage element of the Text Encoding Initiative (TEI).

- - - - - - Editorial and transcriptional component declarations. - - - Attributes for the identification of a causative agent. - - - Signifies the causative agent of damage, illegibility, or other loss of original - text. - - - - - - - - Logical domain attributes. - - - - - - - - - - - - - Attributes describing the nature of an encoded scholarly intervention or - interpretation. - - - - - - - Logical domain attributes. - - - - - - - - - - Attributes that identify the reason why an editorial feature is used. - - - Holds a short phrase describing the reason for missing textual material (gap), why - material is supplied (supplied), or why transcription is difficult (unclear). - - - - - - - - Attributes for elements encoding authorial or scribal intervention when transcribing - manuscript or similar sources. - - - - - - - - - Groups elements that may appear as part of the content of a choice element. - - - Groups elements for editorial interventions that may be useful both in transcribing and in - authoring processes. - - - - - - - Groups elements that may appear as part of editorial and transcription elements. - - - Groups elements that may appear as part of editorial and transcription elements in music - notation. - - - - - - Groups elements that may appear as part of editorial and transcription elements in - prose. - - - - - - Groups elements used for editorial transcription of pre-existing source materials. - - - - - - abbreviation - A generic element for 1) a shortened form of a word, including an acronym - or 2) a shorthand notation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Records the expansion of a text abbreviation. - - - - - - -

In no case should abbr contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, abbr should only contain those elements allowed within verse.

- - -

The model of this element is based on the abbr element of the Text Encoding Initiative (TEI) and the abbr element of the Encoded - Archival Description (EAD).

- - - - addition - Marks an addition to the text. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Location of the addition. - - - - - - -

The add element contains material inserted by an author, scribe, - annotator, or corrector. The agent responsible for the addition may be encoded using the - hand attribute, while the resp attribute records the editor or - transcriber responsible for identifying the hand of the addition. The cert - attribute signifies the degree of certainty ascribed to the identification of the hand of - the addition. The editor(s) responsible for asserting this particular reading may be - recorded in the resp attribute. The value of resp must point to one or more - identifiers declared in the document header.

-

In no case should add contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, add - should only contain those elements allowed within verse.

- - -

The model of this element is based on the add element of the Text Encoding Initiative (TEI).

- - - - Groups a number of alternative encodings for the same point in a text. - - - - - - - - - - - - -

Because the children of a choice element all represent alternative - ways of encoding the same sequence, it is natural to think of them as mutually exclusive. - However, there may be cases where a full representation of a text requires the alternative - encodings to be considered as parallel. Note also that choice elements - may be recursively nested.

- - -

The model of this element is based on the choice element of the Text Encoding Initiative (TEI).

- - - - correction - Contains the correct form of an apparent erroneous passage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The cert attribute signifies the degree of certainty ascribed to correction. The - resp attribute contains an ID reference to an element containing the name of the - editor or transcriber responsible for suggesting the correction held as the content of the - corr element. If the correction was made in the source, resp should be - used to identify the hand of the corrector. The value of resp must point to one or more - identifiers declared in the document header.

-

In no case should corr contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, corr should only contain those elements allowed within verse.

- - -

The model of this element is based on the corr element of the Text Encoding Initiative (TEI).

- - - - copy/colla parte mark - A verbal or graphical indication to copy musical material - written elsewhere. - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2 - - - - - - a. b. c. d. e. f. g. - - - - - unis: - - - - - in 8va - - - -

Typical examples are colla parte instructions (such as "col Basso") or - other indications intended to result in filling gaps in the score with material written - elsewhere. It is recommended to capture the position of the indication itself with the - attributes tstamp and staff. The area to be filled should contain space or mSpace elements. The material to be used to - fill the gap can be identified by the attributes origin.tstamp, - origin.tstamp2, origin.staff, and origin.layer. If - origin.tstamp2 is not provided, a duration similar to that of the local omission - (as encoded in the combination of tstamp and tstamp2) is assumed. Any - missing @origin.* attributes are assumed to take the same values as information associated - with the cpMark. For example, when only the origin.staff attribute is provided, - it is assumed that the referenced part comes from a different staff in the same measure. If - a different measure is provided by origin.tstamp, but no origin.staff - is given, then it is assumed that the material is to be taken from the same staff.

-

Textual instructions are encoded as text content of the cpMark, while graphical - instructions may use the altsym, facs, or extsym - attributes.

- - - - Contains an area of damage to the physical medium. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Records the degree of damage. - - - - - - -

In no case should damage contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, damage should only contain those elements allowed within verse.

- - -

The model of this element is based on the damage element of the Text Encoding Initiative (TEI).

- - - - deletion - Contains information deleted, marked as deleted, or otherwise indicated as - superfluous or spurious in the copy text by an author, scribe, annotator, or corrector. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The resp attribute contains an ID reference to an element containing the name of - the editor or transcriber responsible for identifying the hand of the deletion. The - cert attribute signifies the degree of certainty ascribed to the identification - of the hand of the deletion. The hand of the agent which made the deletion should be pointed - to using the hand attribute. The rend attribute may be used to record - the method used to make the deletion (overstrike, strike[through], etc.).

-

In no case should del contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, del - should only contain those elements allowed within verse.

- - -

The model of this element is based on the del element of the Text Encoding Initiative (TEI).

- - - - expansion - Contains the expansion of an abbreviation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - abbreviation - Captures the abbreviated form of the text. - - - - - - -

In no case should expan contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, expan should only contain those elements allowed within verse.

- - -

The model of this element is based on the expan element of the Text Encoding Initiative (TEI) and the expan element of the Encoded - Archival Description (EAD).

- - - - Indicates a point where material has been omitted in a transcription, whether as part of - sampling practice or for editorial reasons described in the MEI header. - - - - - - - - - - - - -

When material is omitted because it is illegible or inaudible, unclear should be used instead. Similarly, use damage if the - omission is due to damage and del if the omission is because the - material is marked as deleted, or otherwise indicated as superfluous or spurious in the copy - text by an author, scribe, annotator, or corrector. An indication of how much material has - been omitted from the transcription may be recorded in the extent attribute. The - unit attribute names the unit used for describing the extent of the gap. The - reason attribute gives the reason for omission. Sample values include sampling, - irrelevant, cancelled. The resp attribute contains an ID reference to an - element containing the name of the editor, transcriber or encoder responsible for the - decision not to provide any transcription of the material and hence the application of the - gap tag. The hand attribute signifies the hand which made - the deletion in the case of text omitted from the transcription because of deliberate - deletion by an identifiable hand. The cert attribute signifies the degree of - certainty ascribed to the identification of the extent of the missing material.

- - -

The model of this element is based on the gap element of the Text Encoding Initiative (TEI).

- - - - Marks the beginning of a passage written in a new hand, or of a change in the scribe, - writing style, ink or character of the document hand. - - - - - - - - - - - - - Describes the character of the new hand. - - - - - - Identifies the new hand. The value must contain the ID of a hand element given - elsewhere in the document. - - - - - - - @new attribute should - have content. - The value in @new should correspond to the @xml:id attribute of a hand - element. - - - - - - Identifies the old hand. The value must contain the ID of a hand element given - elsewhere in the document. - - - - - - - @old attribute should - have content. - The value in @old should correspond to the @xml:id attribute of a hand - element. - - - - - - -

The character attribute describes characteristics of the hand, particularly - those related to the quality of the writing, e.g., shaky, thick, regular. A description - of the tint or type of ink, e.g., brown or the writing medium, e.g., pencil, may be placed - in the medium attribute. The new hand may be identified using the new - attribute, while the previous hand may be recorded in the old attribute. The - resp attribute contains an ID reference to an element containing the name of the - editor or transcriber responsible for identifying the change of hand. The cert - attribute signifies the degree of certainty ascribed to the identification of the new - hand.

- - -

The model of this element is based on the handShift element of the Text Encoding Initiative (TEI).

- - - - A graphical or textual statement with additional / explanatory information about the - musical text. The textual consequences of this intervention are encoded independently via - other means; that is, with elements such as add, del, etc. - - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real - - - - - - Describes the purpose of the metaMark. - - - - - - confirmation of a previous textual decision; i.e., cancellation of a deleted - passage in a different writing medium. - - - denoted material is to be inserted in the musical text. - - - denoted material is no longer part of the musical text. - - - denoted material is replaced, either by the musical text pointed at with the - @target attribute or the musical content of the metaMark element itself. - - - attempt to clarify a potentially illegible or otherwise unclear part of the - musical text. - - - marks a section of the musical text which is to be considered further. - - - marks a section of the musical text as an investigation of the consequences of - certain compositional decisions or potential alternatives. - - - declares a formerly cancelled part of the musical text as valid again. - - - clarification of the reading order of the musical text. - - - - - -

This element is used to encode explicit metatexts as - defined by the Beethovens Werkstatt project.

- - - - original - Contains material which is marked as following the original, rather than - being normalized or corrected. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This element will often be combined with a regularized form within a choice element. The - editor(s) responsible for asserting that the material is original may be recorded in the - resp attribute. The value of resp must point to one or more identifiers declared - in the document header. The cert attribute signifies the degree of certainty - ascribed to the transcription of the original text.

-

In no case should orig contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, orig should only contain those elements allowed within verse.

- - -

The model of this element is based on the orig element of the Text Encoding Initiative (TEI).

- - - - regularization - Contains material which has been regularized or normalized in some - sense. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

It is possible to identify the individual responsible for the regularization, and, using - the choice and orig elements, to provide both - original and regularized readings. The editor(s) responsible for asserting the regularized - material may be recorded in the resp attribute. The value of resp must - point to one or more identifiers declared in the document header. The cert - attribute signifies the degree of certainty ascribed to the regularized reading.

-

In no case should reg contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, reg - should only contain those elements allowed within verse.

- - -

The model of this element is based on the reg element of the Text Encoding Initiative (TEI).

- - - - Indicates restoration of material to an earlier state by cancellation of an editorial or - authorial marking or instruction. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - description - Provides a description of the means of restoration, stet or strike-down, - for example. - - - - - - -

In no case should restore contain elements that would not otherwise - be permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, restore should only contain those elements allowed within verse.

- - -

The model of this element is based on the restore element of the Text Encoding Initiative (TEI).

- - - - Contains apparently incorrect or inaccurate material. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

A correction for the apparent error may be given in an accompanying child or sibling corr element.

-

In no case should sic contain elements that would not otherwise be - permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, sic - should only contain those elements allowed within verse.

- - -

The model of this element is based on the sic element of the Text Encoding Initiative (TEI).

- - - - substitution - Groups transcriptional elements when the combination is to be regarded as - a single intervention in the text. - - - - - - - - - - - - - -

The model of this element is based on the subst element of the Text Encoding Initiative (TEI).

- - - - Contains material supplied by the transcriber or editor for any reason. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

When the presumed loss of text arises from an identifiable cause, agent signifies the - causative agent. When the presumed loss of text arises from action (partial deletion, etc.) - assignable to an identifiable hand, the hand attribute signifies the hand - responsible for the action. The reason attribute indicates why the text has to be - supplied, e.g., overbinding, faded ink, lost folio, - omitted in original, etc. - The source attribute contains the source of the supplied text. The editor(s) - responsible for supplied material may be recorded in the resp attribute. The - value of resp must point to one or more identifiers declared in the document header. The - cert attribute signifies the degree of certainty ascribed to the supplied - material.

-

In no case should supplied contain elements that would not otherwise - be permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, supplied should only contain those elements allowed within verse.

- - -

The model of this element is based on the supplied element of the Text Encoding Initiative (TEI).

- - - - Contains material that cannot be transcribed with certainty because it is illegible or - inaudible in the source. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Where the difficulty in transcription arises from an identifiable cause, the - agent attribute signifies the causative agent. The cert attribute - signifies the degree of certainty ascribed to the transcription of the text contained within - the unclear element. Where the difficulty in transcription arises from - action (partial deletion, etc.) assignable to an identifiable hand, the hand - attribute signifies the hand responsible for the action. The reason attribute - indicates why the material is difficult to transcribe. The resp attribute - indicates the individual responsible for the transcription of the word, phrase, or passage - contained with the unclear element. The value of resp must - point to one or more identifiers declared in the document header.

-

In no case should unclear contain elements that would not otherwise - be permitted to occur within the parent of its own app ancestor. For - example, when used as a descendent of verse, unclear should only contain those elements allowed within verse.

- - -

The model of this element is based on the unclear element of the Text Encoding Initiative (TEI).

- - - - - - External symbols component declarations. - - - Attributes that point to an external symbol authority. - - - A name or label associated with the controlled vocabulary from which the value of - glyph.name or glyph.num is taken, or the textual content of the element. - - - - - - Standard Music Font Layout. - - - - - The web-accessible location of the controlled vocabulary from which the value of - glyph.name or glyph.num is taken, or the textual content of the element. - - - - - - - - Attributes that specify names or values taken from an external symbol authority. - - - Glyph name. - - - - - - - @glyph.name attribute - should have content. - - - - - - Numeric glyph reference in hexadecimal notation, e.g., "#xE000" or "U+E000". N.B. SMuFL - version 1.18 uses the range U+E000 - U+ECBF. - - - - - - - SMuFL version 1.18 uses the range U+E000 - U+ECBF. - - - - - - - - Attributes used to associate MEI features with corresponding glyphs in an - externally-defined standard such as SMuFL. - - - - - - - - - Facsimile component declarations. - - - Attributes that associate a feature corresponding with all or part of an image. - - - facsimile - Points to one or more images, portions of an image, or surfaces which correspond to the current element. - - - - - - - @facs attribute should - have content. - Each value in @facs should correspond to the @xml:id attribute of a surface or zone - element. - - - - - - - - Contains a representation of a written source in the form of a set of images rather than - as transcribed or encoded text. - - - - - - - - - - - - - - -

The graphic element is provided within facsimile for association of - the facsimile with graphic files capable of representing multiple pages, such as TIFF or PDF - formats. When more than one graphic element is used, each must represent the same material. - When each page is represented by a different graphic, use a surface - element for each page.

-

The decls attribute may be used to link the collection of images with a - particular source described in the header.

- - -

The model of this element is based on the facsimile element of the Text Encoding Initiative (TEI).

- - - - Defines a writing surface in terms of a rectangular coordinate space, optionally grouping - one or more graphic representations of that space, and rectangular zones of interest within - it. - - - - - - - - - - - - - - - - - - - -

Scalable Vector Graphics (SVG) markup may be used when allowed by the graphicLike - model.

-

The startid attribute may be used to hold a reference to the first feature - occurring on this surface.

- - -

The model of this element is based on the surface element of the Text Encoding Initiative (TEI).

- - - - Defines an area of interest within a surface or graphic file. - - - - - - - - - - - - - - -

Scalable Vector Graphics (SVG) markup may be used when allowed by the graphicLike - model.

-

The model of this element is based on the zone element of the Text Encoding Initiative (TEI).

- - - - - - Figures and tables component declarations. - - - Attributes shared by table cells. - - - The number of columns spanned by this cell. - - - - - - The number of rows spanned by this cell. - - - - - - - - Groups elements that provide a brief prose description of the appearance or content of a - graphic figure. - - - Groups elements representing or containing graphic information such as an illustration or - figure. - - - - - - Groups elements that indicate the location of an inline graphic, illustration, or - figure. - - - Groups table-like elements. - - - - - - - figure - Groups elements representing or containing graphic information such as an - illustration or figure. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the figure element of the Text Encoding Initiative (TEI).

- - - - figure description - Contains a brief prose description of the appearance or content of - a graphic figure, for use when documenting an image without displaying it. - - - - - - - - - - - - - - - - - - - - - -

Best practice suggests the use of controlled vocabulary for figure descriptions. Don't - confuse this entity with a figure caption. A caption is text primarily intended for display - with an illustration. It may or may not function as a description of the illustration.

- - -

The model of this element is based on the figDesc element of the Text Encoding Initiative (TEI).

- - - - Indicates the location of an inline graphic. - - - - - - - - - - - - - - - - - - - - - Graphic child of zone should not have - children. - - - Graphic should have either a - startid attribute or ulx and uly attributes. - - - Graphic should not have @ulx or @uly - attributes. - Graphic should not have @ho or @vo - attributes. - - - - -

The model of this element is based on the graphic element of the Text Encoding Initiative (TEI).

- - - - Contains text displayed in tabular form. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the table element of the Encoded Archival Description (EAD), the table element of the Text - Encoding Initiative (TEI), and the table element of HTML.

- - - - table data - Designates a table cell that contains data as opposed to a cell that - contains column or row heading information. - - - - - - - - - - - - - - - - - - - -

The colspan and rowspan attributes record tabular display rendering - information.

- - -

The model of this element is based on the td element of HTML.

- - - - table header - Designates a table cell containing column or row heading information as - opposed to one containing data. - - - - - - - - - - - - - - - - - - - -

The colspan and rowspan attributes record tabular display rendering - information.

- - -

The model of this element is based on the th element of HTML.

- - - - table row - A formatting element that contains one or more cells (intersection of a row - and a column) in a table. - - - - - - - - - - - - - - - -

More precise rendition of the table and its cells can be specified in a style sheet.

- - -

The model of this element is based on the tr element of HTML.

- - - - - - Fingering component declarations. - - - Logical domain attributes. - - - - - - - - - Logical domain attributes. - - - - - - - - - - - alternation of fingers. - - - combination of fingers. - - - substitution of fingers. - - - - - - - Groups elements that capture performance instructions regarding the use of the fingers of - the hand (or a subset of them). - - - - - - finger - An individual finger in a fingering indication. - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - - The stack element is not allowed as a - descendant of fing. - - - - - - finger group - A group of individual fingers in a fingering indication. - - - - - - - - - - - - - - - - - - - - - - At least 2 fing or fingGrp - elements are required. - - - - - - - - When @tstamp or @startid is - present on fingGrp, its child elements cannot have a @tstamp or @startid - attribute. - - - When @tstamp or @startid is not present on fingGrp, each of its child elements must - have a @tstamp or @startid attribute. - - - - - - - - - FRBR (Functional Requirements for Bibliographic Records) declarations. - - - Relationships between FRBR entities. - - - - Target is an abridgement, condensation, or expurgation of the current entity. - - - Reciprocal relationship of hasAbridgement. - - - Target is an adaptation, paraphrase, free translation, variation (music), - harmonization (music), or fantasy (music) of the current entity. - - - Reciprocal relationship of hasAdaptation. - - - Target is an alternate format or simultaneously released edition of the current - entity. - - - Reciprocal relationship of hasAlternate. - - - Target is an arrangement (music) of the current entity. - - - Reciprocal relationship of hasArrangement. - - - Target is a cadenza, libretto, choreography, ending for unfinished work, incidental - music, or musical setting of a text of the current entity. - - - Reciprocal relationship of hasComplement. - - - Target is a physical embodiment of the current abstract entity; describes the - expression-to-manifestation relationship. - - - Reciprocal relationship of hasEmbodiment. - - - Target is an exemplar of the class of things represented by the current entity; - describes the manifestation-to-item relationship. - - - Reciprocal relationship of hasExamplar. - - - Target is a parody, imitation, or travesty of the current entity. - - - Reciprocal relationship of hasImitation. - - - Target is a chapter, section, part, etc.; volume of a multivolume manifestation; - volume/issue of serial; intellectual part of a multi-part work; illustration for a text; - sound aspect of a film; soundtrack for a film on separate medium; soundtrack for a film - embedded in film; monograph in a series; physical component of a particular copy; the - binding of a book of the current entity. - - - Reciprocal relationship of hasPart. - - - Target is a realization of the current entity; describes the work-to-expression - relationship. - - - Reciprocal relationship of hasRealization. - - - Target has been reconfigured: bound with, split into, extracted from the current - entity. - - - Reciprocal relationship of hasReconfiguration. - - - Target is a reproduction, microreproduction, macroreproduction, reprint, - photo-offset reprint, or facsimile of the current entity. - - - Reciprocal relationship of hasReproduction. - - - Target is a revised edition, enlarged edition, or new state (graphic) of the current - entity. - - - Reciprocal relationship of hasRevision. - - - Target is a sequel or succeeding work of the current entity. - - - Reciprocal relationship of hasSuccessor. - - - Target is a digest or abstract of the current entity. - - - Reciprocal relationship of hasSummarization. - - - Target is an index, concordance, teacher’s guide, gloss, supplement, or appendix of - the current entity. - - - Reciprocal relationship of hasSupplement. - - - Target is a dramatization, novelization, versification, or screenplay of the current - entity. - - - Reciprocal relationship of hasTransformation. - - - Target is a literal translation or transcription (music) of the current - entity. - - - Reciprocal relationship of hasTranslation. - - - - - - Collects FRBR expression-like elements. - - - Collects FRBR item-like elements. - - - Collects FRBR manifestation-like elements. - - - Intellectual or artistic realization of a work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The perfDuration element captures the intended duration - of the expression, while extent records scope of the expression in - other terms, such as number of pages, measures, etc.

- - - - Gathers bibliographic expression entities. - - - - - - - - - - - - - - Single instance or exemplar of a source/manifestation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gathers bibliographic item entities. - - - - - - - - - - - - - - A bibliographic description of a physical embodiment of an expression of a work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Item children are not permitted when @singleton - equals "true". - - - - - - - Availability is only permitted when @singleton equals "true". - - - - - - Indicates the manifestation is a unique physical object. - - - -

This attribute is inspired by the FRBRoo concept of manifestation singleton.

 -

Manifestation singleton encompasses: manuscripts, preperatory sketches, and final clean drafts.

 - - - - - A container for the descriptions of physical embodiments of an expression of a - work. - - - - - - - - - - - - - - - - Genetic encoding component declarations. - - - Attributes that pertain to a genetic state. - - - - @state attribute should - have content. - The value in @state should correspond to the @xml:id attribute of a genState (genetic state) - element. - - - - - - The @instant attribute is syntactic sugar for classifying a scribal intervention as an - ad-hoc modification; that is, one which does not interrupt the writing process. - - - - unknown - - - - - Points to the genetic state that results from this modification. - - - - - - - - genetic description - Bundles information about the textual development of a - work. - - - - - - - - - - - - - - - - When set to "true" the child elements are known to be in chronological order. When set - to "false" or when not provided, the order of child elements is unknown. - - - - - - -

The development of a work can be traced in one or more sources.

-

When the genDesc element is nested, the inner element describes a - group of processes with unknown chronological order inside a larger set of processes with - known order, or vice versa.

-

The decls attribute may be used to link the genetic description with a - particular work described in the header.

- - - - Describes a distinctive state in the textual development of a work. - - - - - - - - - - - - - - - - - - - - -

Any scribal modifications encoded with elements, such as add, del, etc., which refer to a genState element, are regarded as the - operations that need to be implemented to reach this state; that is, they precede this - state.

-

When nested inside a genDesc element with ordered set to - "false", information regarding the chronological order of states may be provided using the - next, prev, follows and precedes attributes.

-

The date can be used to identify when the current state was - achieved.

- - - - - - Gestural component declarations. - - - Gestural domain attributes. - - - - - - Attributes for capturing momentary pitch inflection in the gestural domain. - - - Records the performed pitch inflection. - - - - - - - The value of @accid.ges should - not duplicate the value of @accid. - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Attributes describing the method of performance. - - - Records performed articulation that differs from the written value. - - - - - - - - Gestural domain attributes. - - - - - - Attributes whether an element is performed "attacca". - - - Indicates that the performance of the next musical division should begin immediately - following this one. - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Records the amount of detuning. The decimal values should be rendered as a fraction - (or an integer plus a fraction) along with the bend symbol. - - - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Attributes that record performed duration that differs from a feature’s written - duration. - - - Records performed duration information that differs from the written duration. - - - - - - Number of dots required for a gestural duration when different from that of the - written duration. - - - - - - Duration as a count of units provided in the time signature denominator. - - - \d+(\.\d+)? - - - - - Duration recorded as pulses-per-quarter note, e.g., MIDI clicks or MusicXML - divisions. - - - - - - Duration in seconds, e.g., 1.732. - - - \d+(\.\d+)? - - - - - Duration as an optionally dotted Humdrum **recip value. - - - [0-9]+(%[0-9]+)?\.*q? - - - - - - - Gestural domain attributes. - - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Attributes for describing the performed components of a line. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. The tstamp.ges and tstamp.real attributes encode the onset - time of the measure. In reality, this is usually the same as the onset time of the first event - in the measure. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - - - - - - - - When the @extremis attribute is used, - the @pname.ges and @oct.ges attributes are not allowed. - - - - - - Indicates an extreme, indefinite performed pitch. - - - Highest note the performer can play. - - - Lowest note the performer can play. - - - -

On a wind instrument, the "highest note possible" depends on the player’s abilities. On - a string instrument, the "lowest note possible" depends on how much a string is - de-tuned; that is, loosened using the tuning peg. Use of the pname and - oct or ploc and oloc or loc attributes is - necessary to record the written pitch and octave of the symbol for this note.

- - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural accidentals associated with ornaments. - - - Records the sounding accidental associated with an upper neighboring note. - - - - - - Records the sounding accidental associated with a lower neighboring note. - - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural attributes about pitch. - - - Records performed octave information that differs from the written value. - - - - - - Contains a performed pitch name that differs from the written value. - - - - - - pitch number - Holds a pitch-to-number mapping, a base-40 or MIDI note number, for example. - - - - - - - - Gestural domain attributes that describe the properties of a plica in the mensural repertoire. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes for scoreDef. The values set in these attributes act as - score-wide defaults for attributes that are not set in descendant elements. For example, the - grace attribute value here applies to all the grace attribute values in the score (or, more - accurately, until the next scoreDef element) without having to - individually set each note’s grace attribute value. The midi.* attributes function as default - values when creating sounding output. The tune.* attributes provide the capability of - recording a tuning reference pitch. - - - - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - - Attributes that locate a sound source within 3-D space. - - - The lateral or left-to-right plane. - - - - -

A value of 0, 360, or -360 is directly in front of the listener, while a value of 180 - or -180 is directly behind.

- - - - The above-to-below axis. - - - - -

A value of 0, 360, or -360 is directly above the listener, while a value of 180 or -180 - is directly below.

- - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - Gestural domain attributes for staffDef in the CMN repertoire. - - - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes that describe the properties of a stem in the mensural repertoire. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - Attributes that record a performed (as opposed to notated) time stamp. - - - Encodes the onset time in terms of musical time, i.e., beats[.fractional beat part], - as expressed in the written time signature. - - - - - - Records the onset time in terms of ISO time. - - - - - - - - Attributes that record a performed (as opposed to notated) time stamp for the end of an - event. - - - Encodes the ending point of an event, i.e., a count of measures plus a beat location - in the ending measure. - - - - - - Records the ending point of an event in terms of ISO time. - - - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - - - - Gestural domain attributes. - - - - - - - Gestural domain attributes. - - - Gestural domain attributes. - - - Gestural domain attributes. - - - - - Harmony component declarations. - - - Logical domain attributes. - - - - - - - Logical domain attributes. - - - - - - - Logical domain attributes. - - - - - - - - - Logical domain attributes. - - - - - - - - - chord reference - Contains a reference to a chordDef element elsewhere in the - document. - - - - - - - @chordref attribute - should have content. - The value in @chordref should correspond to the @xml:id attribute of a chordDef - element. - - - - - - - - Groups elements that group playable chord definitions. - - - Groups harmonic elements that function as control events; that is, those events that - modify or otherwise depend on the existence of notated events. - - - - - - Groups elements that record figured bass. - - - Groups elements that represent single figured bass elements. - - - Groups elements that record indications of harmony. - - - - - - chord definition - Chord tablature definition. - - - - - - - - - - - - - - - - -

An xml:id attribute, while not required by the schema, is needed so that harm elements can reference a particular chord definition. The - pos (position) attribute is provided in order to create displayable chord - tablature grids. chordMember sub-elements record the individual - pitches of the chord. barre sub-elements may be used when a single - finger is used to stop multiple strings.

- - - - An individual pitch in a chord defined by a chordDef element. - - - - - - - - - - - -

The string, fret, and fing attributes are provided in - order to create displayable chord tablature grids. The inth (harmonic interval) - attribute may be used to facilitate automated performance of a chord. It gives the number of - 1/2 steps above the bass. Of course, for the bass note itself, inth should be set - to 0.

- - - - Chord/tablature look-up table. - - - - - - - - - - -

A chordTable may be shared between MEI instances through the use of an external parsed - entity containing the look-up table to be shared.

- - - - figure - Single element of a figured bass indication. - - - - - - - - - - - - - - - - - - - - - - figured bass - Symbols added to a bass line that indicate harmony. Used to improvise a - chordal accompaniment. Sometimes called Generalbass, thoroughbass, or basso continuo. - - - - - - - - - - - - - - - - - harmony - An indication of harmony, e.g., chord names, tablature grids, harmonic - analysis, figured bass. - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - - Metadata header component declarations. - - - Groups elements that may appear as part of a description of the availability of and access - to a bibliographic item. - - - - - - - - - - - - - - - - - - - - - - - - - Groups manifestation- and item-specific elements that may appear as part of a - bibliographic description. - - - - - - - - - - - - - - - - - - - - - - - Attributes that link a bifolium element with a surface - element. - - - A reference to a surface element positioned on the outer recto - side of a (folded) sheet. - - - - - - A reference to a surface element positioned on the inner verso - side of a (folded) sheet. - - - - - - A reference to a surface element positioned on the inner recto - side of a (folded) sheet. - - - - - - A reference to a surface element positioned on the outer verso - side of a (folded) sheet. - - - - - - - - Attributes that link a folium element with a surface element. - - - A reference to a surface element positioned on the recto side of - the sheet. - - - - - - A reference to a surface element positioned on the verso side of - the sheet. - - - - - - - - Attributes that define the characteristics and components of the performance resource. - - - - - - - Use this attribute to identify the performance resource as a soloist especially in an accompanied work, such as a concerto or vocal solo. - - - - - - - - Attributes that define the characteristics and components of the performance resource or a performance resource list. - - - - - - Indicates the number of performers. - - - - - - - - Attributes that describe a performance resource as ad libitum (optional). - - - Marks a performance resource as ad libitum (optional). - - - - - - -

The technical term “ad libitum” has several meanings depending on the context in which it occurs:

-

- - Meanings of ad libitum - - indicates an optional performance resource (instrumental or vocal part or group), - - marks a passage to be played freely or free in time, - - requests or invites to improvise a passage of music, - - indicates that the number repetitions can be set individually or spontaneously. - -

-

Currently only the use within a performance resource (case 1) is supported.

- - - - Attributes that define the characteristics and components of the bibliographic - description. - - - - - Language material. - - - Notated music. - - - Manuscript notated music. - - - Non-manuscript cartographic material. - - - Manuscript cartographic material. - - - Projected medium. - - - Nonmusical sound recording. - - - Musical sound recording. - - - Two-dimensional nonprojectable graphic. - - - Computer file. - - - Kit. - - - Mixed materials. - - - Three-dimensional artifact or naturally occurring object. - - - Manuscript language material. - - - - - -

The recordtype attribute may be used to determine the appropriateness and - validity of certain data elements in the description.

-

- - Code Descriptions - - Use for non-manuscript language material, including microforms and electronic - resources that are basically textual in nature, whether they are reproductions from - print or originally produced. - - Use for printed, microform, or electronic notated music. - - Use for manuscript notated music or a microform of manuscript music. - - Use for non-manuscript cartographic material or a microform of non-manuscript - cartographic material. - - Use for manuscript cartographic material or a microform of manuscript cartographic - material. - - Use for motion pictures, videorecordings (including digital video), filmstrips, - slide, transparencies or material specifically designed for projection. - - Use for recordings of nonmusical sounds (e.g., speech). - - Use for musical sound recording (e.g., phonodiscs, compact discs, or cassette - tapes. - - Use for two-dimensional nonprojectable graphics such as, activity cards, charts, - collages, computer graphics, digital pictures, drawings, duplication masters, flash - cards, paintings, photo CDs, photomechanical reproductions, photonegatives, photoprints, - pictures, postcards, posters, prints, spirit masters, study prints, technical drawings, - transparency masters, and reproductions of any of these. - - Use for computer software (including programs, games, fonts), numeric data, - computer-oriented multimedia, online systems or services. Other classes of electronic - resources are coded for their most significant aspect (e.g., language material, graphic, - cartographic material, sound, music, moving image). In case of doubt or if the most - significant aspect cannot be determined, consider the item a computer file. - - Use for a mixture of various components issued as a unit and intended primarily for - instructional purposes where no one item is the predominant component of the kit. - Examples are packages of assorted materials, such as a set of school social studies - curriculum material (books, workbooks, guides, activities, etc.), or packages of - educational test materials (tests, answer sheets, scoring guides, score charts, - interpretative manuals, etc.). - - Use for materials in two or more forms that are usually related by virtue of their - having been accumulated by or about a person or body. Includes archival fonds and - manuscript collections of mixed forms of materials, such as text, photographs, and sound - recordings. Intended primary purpose is other than for instructional purposes (i.e., - materials coded as "o"). - - Includes man-made objects such as models, dioramas, games, puzzles, simulations, - sculptures and other three-dimensional art works, exhibits, machines, clothing, toys, - and stitchery. Also includes naturally occurring objects such as, microscope specimens - (or representations of them) and other specimens mounted for viewing. - - This category is applied to items for language material in handwriting, typescript, - or computer printout including printed materials completed by hand or by keyboard or a - microform of these categories. At the time it is created, this material is usually - intended, either implicitly or explicitly, to exist as a single instance. Examples - include marked or corrected galley and page proofs, manuscript books, legal papers, and - unpublished theses and dissertations. - -

- - - - Attributes that describe correction and normalization methods. - - - Indicates the method employed to mark corrections and normalizations. - - - Corrections and normalizations made silently. - - - Corrections and normalizations indicated using elements. - - - - - - - Collects bifoliumlike elements. - - - Groups elements that may appear as part of a description of the editorial process applied - to the encoding of notation. - - - Groups elements that may appear as part of the description of the encoding process. - - - Groups elements that may be used to provide a structured description of an event. - - - Collects foliumlike elements. - - - Groups elements that may appear as part of auxiliary material preceding or following the - text proper. - - - Groups elements that may appear as part of the MEI metadata header. - - - Groups elements dealing with modifications of document pages. - - - Groups elements that may appear as part of the physical description of a bibliographic - item. - - - Groups elements that may appear as part of the publication statement for a bibliographic - item. - - - Groups elements that may be document elements when the header module is invoked. - - - Groups elements that assist in the identification of a work. - - - Collects work-like elements. - - - access restriction - Describes the conditions that affect the accessibility of - material. - - - - - - - - - - - -

May indicate the nature of restrictions or the lack of restrictions. Do not confuse this - element with useRestrict (usage restrictions), which captures - information about limitations on the use of material, such as those - afforded by copyright.

- - -

The model of this element is based on the accessrestrict element of the Encoded Archival Description (EAD).

- - - - Records information concerning the process by which an item was acquired by the holding - institution. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the acquisition element of the Text Encoding Initiative (TEI).

- - - - alternative identifier - May contain a bibliographic identifier that does not fit within - the meiHead element’s id attribute, for example because the identifier does not fit the - definition of an XML id or because multiple identifiers are needed. - - - - - - - - - - - - - - -

One or the other of altId or the xml:id attribute on mei is required when applicable.

- - - - application information - Groups information about applications which have acted upon - the MEI file. - - - - - - - - - - - - - -

The model of this element is based on the appInfo element of the Text Encoding Initiative (TEI).

- - - - Provides information about an application which has acted upon the current - document. - - - - - - - - - - - - - - - - - - - - Supplies a version number for an application, independent of its identifier or display - name. - - - - - - -

The model of this element is based on the application element of the Text Encoding Initiative (TEI).

- - - - Documents the usage of a specific attribute of the element. - - - - - - - - - - - - - @context attribute should - contain an XPath expression. - - - - - - Name of the attribute. - - - - - - Circumstances in which the attribute appears, an XPath expression. - - - - - - - - Defines the class of user for which the work is intended, as defined by age group (e.g., - children, young adults, adults, etc.), educational level (e.g., primary, secondary, etc.), or - other categorization. - - - - - - - - - - - - Groups elements that describe the availability of and access to a bibliographic item, - including an MEI-encoded document. - - - - - - - - - - - -

When used within the fileDesc element, availability indicates access to the MEI-encoded document itself.

- - -

The model of this element is based on the availability element of the Text Encoding Initiative (TEI).

- - - - Describes a folded sheet of paper. - - - - - - - - - - - - - - - - - - - - - - - - Contains the primary statement of responsibility given for a work on its title - page. - - - - - - - - - - - - - - - - - - - capture mode - The means used to record notation, sound, or images in the production of - a source/manifestation (e.g., analogue, acoustic, electric, digital, optical etc.). - - - - - - - - - - - - - carrier form - The specific class of material to which the physical carrier of the - source/manifestation belongs (e.g., sound cassette, videodisc, microfilm cartridge, - transparency, etc.). The carrier for a manifestation comprising multiple physical components - may include more than one form (e.g., a filmstrip with an accompanying booklet, a separate - sound disc carrying the sound track for a film, etc.). - - - - - - - - - - - - - Contains an individual descriptive category in a user-defined taxonomy, possibly nested - within a superordinate category. - - - - - - - - - - - - - - - - - - - - - - - - - - - To be addressable, the category element must - have an xml:id attribute. - - - - - - category relationship - Contains the name of a related category. - - - - - - - - - - - - - - - - - - - - Provides a description of the relationship between the current and the target - categories. - - - Category to which the current category is hierarchically subordinate. - - - Category which is hierarchically subordinate to the current category. - - - Category that is associatively but not hierarchically linked to the current - category. - - - Non-preferred category; often a synonym or near-synonym for the preferred category - label. - - - - - - - Individual change within the revision description. - - - - - - - - - - - - - - - - - - The date of the change must be recorded in an - isodate attribute or date element. - It is recommended that the agent responsible for the change be recorded - in a resp attribute or in a name, corpName, or persName element in the respStmt - element. - - - - -

Additions, deletions, and significant recoding should be noted, but not correction of minor - typographical errors. It is recommended that revisions should be entered in reverse - chronological order, with the most recent change first. The - resp attribute contains a pointer to an element containing info about the - person/entity responsible for change. The edition element can be used - to designate an MEI encoding that has been so substantively changed that it constitutes a - new version that supersedes earlier versions.

- - -

The model of this element is based on the respective element of the Encoded Archival Description (EAD).

- - - - change description - Description of a revision of the MEI file. - - - - - - - - - - - - - Groups information which describes the nature or topic of an entity. - - - - - - - - - - - - - -

Although the use of names and terms from locally controlled vocabularies is possible, best - practice suggests that terms should come from standard national or international - vocabularies whenever they are available in order to enable searches in systems that include - multiple MEI documents, or MEI documents and bibliographic records from many - institutions.

- - - - Groups information which describes the nature or topic of an entity. - - - - - - - - - - - - - - - - -

Although the use of names and terms from locally controlled vocabularies is possible, best - practice suggests that terms should come from standard national or international - vocabularies whenever they are available in order to enable searches in systems that include - multiple MEI documents, or MEI documents and bibliographic records from many - institutions.

- - - - Container for intellectual or physical component parts of a bibliographic entity. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Only child elements of the same name as the parent of the componentList are - allowed. - - - - - - - When any child - element has a comptype attribute, it is recommended that comptype appear on all child - elements. - - - - -

The child elements of this element are treated as components of the bibliographic entity - containing the componentList. Although this is an implicit way of - expressing FRBR’s hasPart and isPartOf relationships, it avoids this terminology in order to - prevent confusion with musical terminology. Work, expression, and item components must be - the same type as the parent of componentList: work children are - allowed within work, etc. Manifestations; i.e., sources, may have - either source or itemcomponents as required to - accommodate composite sources (those containing multiple sources) or multi-part sources - (those made up of several physical items.

- - - - The physical condition of an item, particularly any variances between the physical make-up - of the item and that of other copies of the same item (e.g., missing pages or plates, - brittleness, faded images, etc.). - - - - - - - - - - -

The model of this element is based on the respective element of the Encoded Archival Description (EAD).

- - - - Contains a single entry within a content description element. - - - - - - - - - - - - - - - - - - - List of the material contained within a resource. - - - - - - - - - - - - - - - - - - - - - - - - - - When labels - are used, usually each content item has one. - - - - - - -

A suitable tone ; Left hand coloring ; Rhythm and accent ; Tempo ; - Flexibility ; Ornaments

- - - - - - - Contents - Sonata in D major, op. V, no. 1 / - Corelli - Sonata in G minor / Purcell (with Robert Donington, - gamba) - Forlane from Concert royal no. 3 / - Couperin - - - - - - - - - -

Use this element to provide an enumeration of the contents of a bibliographic entity, like - that often found in a table of contents. When a detailed bibliographic description of - included material is desired, use the componentList element - instead.

- - - - The historical, social, intellectual, artistic, or other context within which the work was - originally conceived (e.g., the 17th century restoration of the monarchy in England, the - aesthetic movement of the late 19th century, etc.) or the historical, social, intellectual, - artistic, or other context within which the expression was realized. - - - - - - - - - - - - States how and under what circumstances corrections have been made in the text. - - - - - - - - - - - - - - - - - - - Indicates the degree of correction applied to the text. - - - The text has been thoroughly checked and proofread. - - - The text has been checked at least once. - - - The text has not been checked. - - - The correction status of the text is unknown. - - - - - -

The model of this element is based on the correction element of the Text Encoding Initiative (TEI).

- - - - A cutout is a section of a document sheet that has been removed and is now missing. - - - - - - - - - - - - - - - - - - - - Describes the position of the cutout on the parent folium / bifolium. - - - removed from outer recto side of bifolium. - - - removed from inner verso side of bifolium. - - - removed from inner recto side of bifolium. - - - removed from outer verso side of bifolium. - - - removed from recto side of folium. - - - removed from verso side of folium. - - - - - Describes the method of removing the cutout. - - - - - - section is cleanly cut by a knife, scissor or other sharp blade. - - - section is ripped off the page, leaving a rough edge. - - - - - -

The dimensions (@width, @height) of the parent element (e.g., folium) - indicate the size of the bounding box of the remaining part of the page. That is, if the - complete lower half of a page has been cut, the @width and @height attributes describe the - remaining upper half. If, in contrast, only the lower right quarter of the page has been - cut, these attributes still indicate the size of the full page (assuming that the removed - section was a regular rectangle).

- - -

The dimensions (@width, @height) on cutout itself are only to be used - when there is a "gap" in the manuscript that allows to specify the dimensions of that - missing part. In this case, the bounding box dimensions are given, together with @x and @y - to indicate the upper left point on the original page. If, however, the removed section is - available by itself, then a corresponding folium (or bifolium) should be placed inside the cutout element, and should - provide it’s own dimensions using @width and @height there. In this case, @width and @height - on cutout is expendable.

- - - - Contains a dedicatory statement. - - - - - - - - - - - - - - - - - - - - - - - - - - -

This element uses a variant of the content model provided by - macro.struc-unstrucContent.

- - - - domains declaration - Indicates which domains are included in the encoding. - - - - - - - - - - - - - - - - - - - - - - - - edition statement - Container for meta-data pertaining to a particular edition of the - material being described. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the editionStmt element of the Text Encoding Initiative (TEI) and the editionstmt Encoded - Archival Description (EAD).

- - - - editorial declaration - Used to provide details of editorial principles and practices - applied during the encoding of musical text. - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the editorialDecl element of the Text Encoding Initiative (TEI).

- - - - encoding description - Documents the relationship between an electronic file and the - source or sources from which it was derived as well as applications used in the - encoding/editing process. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the encodingDesc element of the Text Encoding Initiative (TEI).

- - - - exhibition history - A record of public exhibitions, including dates, venues, - etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the MARC 585 field.

- - - - extended metadata - Provides a container element for non-MEI metadata formats. - - - - - - - - - - - - - - - - - - file characteristics - Standards or schemes used to encode the file (e.g., ASCII, SGML, - etc.), physical characteristics of the file (e.g., recording density, parity, blocking, etc.), - and other characteristics that have a bearing on how the file can be processed. - - - - - - - - - - - - file description - Contains a full bibliographic description of the MEI file. - - - - - - - - - - - - - - - - - - - - - - - - -

Extent in this context represents file size.

- - -

The model of this element is based on the fileDesc element of the Text Encoding Initiative (TEI) and the filedesc element of the Encoded - Archival Description (EAD).

- - - - Describes the order of folia and bifolia making up the text block of a manuscript or - print. - - - - - - - - - - - - - - - - - - -

The purpose of foliaDesc is to transcribe the addition and removal of - pages as part of physical modifications to a document. Missing pages may be indicated using - the gap element. The folium and bifolium children describe the physical order of surface - elements provided elsewhere.

- - - - Describes a single leaf of paper. - - - - - - - - - - - - - -

When the exact folium setup can't be identified, it is advised to use folium elements only (and not guess about the presence of bifoliums in the document).

- - - - Defines a distinct scribe or handwriting style. - - - - - - - - - - - - - - - - - - Marks this hand as the first one of the document. - - - - - - -

The initial attribute indicates whether this is the first or main hand of the - document. The medium attribute describes the writing medium, e.g., - pencil, or the tint or type of ink, e.g., brown. - The resp attribute contains an ID reference to an element containing the name of - the editor or transcriber responsible for identifying the hand. The characteristics of the - hand, particularly those related to the quality of the writing, such as shaky, - thick, etc. may be described within the content of the hand - element.

- - -

The model of this element is based on the handNote element of the Text Encoding Initiative (TEI).

- - - - Container for one or more hand elements. - - - - - - - - - - - - - - - - - - - - When labels are used, - usually each hand has one. - - - - -

The model of this element is based on the handNotes element of the Text Encoding Initiative (TEI).

- - - - Provides a container for information about the history of a resource other than the - circumstances of its creation. - - - - - - - - - - - - - - - - - - - - - - - - - The elements acquisition, provenance, exhibHist, treatHist and treatSched are not permitted at the work or expression level and are only permitted at the manifestation level, if the manifestation is a manifestation singleton. - - - - -

To facilitate efficient data interchange, basic information about the circumstances - surrounding the creation of bibliographic resources should be recorded within the creation element, while the record of ownership and custody should be - captured within the history element.

- - - - Incipit coded in a non-XML, plain text format, such as Plaine & Easie Code. - - - - - - - - - - - - - - incipCode must have a form or mimetype - attribute. - - - - - - Form of the encoded incipit. - - - - - - Plaine & Easie Code. - - - **kern representation of the Humdrum format. - - - Parsons code. - - - - - - - Opening words of a musical composition. - - - - - - - - - - - - - - - - - - - - - An inscription added to an item, such as a bookplate, a note designating the item as a - gift, and/or the author’s signature. - - - - - - - - - - - - Describes the scope of any analytic or interpretive information added to the transcription - of the music. - - - - - - - - - - - - - - - - -

The model of this element is based on the interpretation element of the Text Encoding Initiative (TEI).

- - - - Key captures information about tonal center and mode. - - - - - - - - - - - - -

This element is used exclusively within bibliographic descriptions. Do not confuse this - element with keySig, which is used within the body of an MEI file to - record this data.

- - - - Description of a language used in the document. - - - - - - - - - - - - - - - -

A textual element may be related to this element by setting its xml:lang - attribute, which normally takes the form of a code drawn from a coded list, such as - ISO639-2b, to the same value as this element’s codedval attribute. The name and web location - of the authorizing list may be encoded in the auth attribute and the - auth.uri attribute, respectively.

- - -

The model of this element is based on the language element of the Text Encoding Initiative (TEI) and the language element of the Encoded - Archival Description (EAD).

- - - - language usage - Groups elements describing the languages, sub-languages, dialects, - etc., represented within the encoded resource. - - - - - - - - - - - - - - -

The model of this element is based on the langUsage element of the Text Encoding Initiative (TEI).

- - - - MEI header - Supplies the descriptive and declarative metadata prefixed to every - MEI-conformant text. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The meiHead type attribute can have the value 'music' - only when the document element is "mei". - - - The meiHead type attribute can have the value - 'corpus' only when the document element is "meiCorpus". - - - The meiHead type attribute can have the value - 'independent' only when the document element is "meiHead". - - - - - - Specifies the kind of document to which the header is attached, for example whether it - is a corpus or individual text. - - - Header is attached to a music document. - - - Header is attached to a corpus. - - - Header is independent; i.e., not attached to either a music or a corpus - document. - - - - - -

In order to encourage uniformity in the provision of metadata across document types, this - element is modelled on an element in the Text Encoding Initiative (TEI) standard. This - information is often essential in a machine-readable environment. Five sub-elements must be - encoded in the following order: altId(optional), fileDesc(required), encodingDesc(optional), workList(optional), and revisionDesc(optional). These elements - and their sub-elements provide: a unique identifier for the MEI file, bibliographic - information about the MEI file and its sources, information about the encoding process, - information about the creation of the work being encoded, and statements regarding - significant revisions of the file. The xml:lang attribute may be used to indicate - the language in which the metadata content of the header is provided.

- - - - Captures information about mensuration within bibliographic descriptions. - - - - - - - - - - - - - - Captures information about the time signature within bibliographic descriptions. - - - - - - - - - - - -

This element is used exclusively within bibliographic descriptions. Do not confuse meter with the meterSig or meterSigGrp or attributes used by staffDef and scoreDef to record this data within the - body of an MEI file.

- - - - Supplies the formal name of the namespace to which the elements documented by its children - belong. - - - - - - - - - - - - - - - - - - - - Formal namespace identifier; that is, a uniform resource identifier (URI). - - - - - - Prefix associated with the formal identifier. - - - - - - -

The model of this element is based on the namespace element of the Text Encoding Initiative (TEI).

- - - - Indicates the extent of normalization or regularization of the original source carried out - in converting it to electronic form. - - - - - - - - - - - - - - - - - -

The model of this element is based on the normalization element of the Text Encoding Initiative (TEI).

- - - - notes statement - Collects any notes providing information about a text additional to - that recorded in other parts of the bibliographic description. - - - - - - - - - - - - - -

The model of this element is based on the notesStmt element of the Text Encoding Initiative (TEI).

- - - - other distinguishing characteristic - Any characteristic that serves to differentiate a - work or expression from another. - - - - - - - - - - - Describes a physical writing surface attached to the original document. - - - - - - - - - - - - - - - - - - The allowed positions of a patch depend on its parent element. - A patch element must contain either a folium - or a bifolium element. - - - - - - Describes the position of the patch on the parent folium / bifolium. - - - patch attached to outer recto side of bifolium. - - - patch attached to inner verso side of bifolium. - - - patch attached to inner recto side of bifolium. - - - patch attached to outer verso side of bifolium. - - - patch attached to recto side of folium. - - - patch attached to verso side of folium. - - - - - Describes the method of attachment of the patch. - - - - - - patch is glued on surface beneath. - - - patch is sewn on surface beneath. - - - patch is pinned to the surface beneath. - - - patch is taped on surface beneath using an adhesive strip. - - - patch is attached on surface beneath using a staple. - - - - - -

A patch must always contain a folium or bifolium element. The @x and @y attributes are used to position the patch on its - parent surface by indicating the upper left corner of the patch. The size of the patch is - encoded using the @height and @width attributes on the child folium (or bifolium).

- - - - - performance duration - Used to express the duration of performance of printed or - manuscript music or the playing time for a sound recording, videorecording, etc. - - - - - - - - - - - - - - - Holds a W3C duration value, e.g., "PT2H34M45.67S". - - - - - - -

- - - - performance medium - Indicates the number and character of the performing forces used in - a musical composition. - - - - - - - - - - - - - - - - - - - - - -

Arrangements are coded for the medium of the work being described, not for the original - medium.

- - - - performance resource - Name of an instrument on which a performer plays, a performer's - voice range, or a standard performing ensemble designation. - - - - - - - - - - - - - - - - - - -

In the context of a performance resource the attribute adlib marks a resource as optional.

- - -

To indicate the tuning of an instrument, the attribute trans.diat can be used.

- - - - performance resources list - Several instrumental or vocal resources treated as a group. - - - - - - - - - - - - - - - - - - - - - -

The function of instrumentalists or vocalists is represented by the choice of perfRes and perfResList child elements. Arrangements - are coded for the medium of the work being described, not for the original medium.

- - - - physical description - Container for information about the appearance, construction, or - handling of physical materials, such as their dimension, quantity, color, style, and technique - of creation. - - - - - - - - - - - - - - - - -

Dedicatory text and title page features may also be encoded here when they are not - transcribed as part of the front or back matter; i.e., when they are considered to be - meta-data rather than a transcription.

- - -

The model of this element is based on the physdesc element of the Encoded Archival Description (EAD).

- - - - physical medium - Records the physical materials used in the source, such as ink and - paper. - - - - - - - - - - - -

All materials may be described in a single physMedium element or - multiple elements may be used, one for each medium.

- - -

The model of this element is based on respective elements of the Encoded Archival Description (EAD). It - has the same function as the material element of the Text Encoding Initiative (TEI).

- - - - plate number - Designation assigned to a resource by a music publisher, usually printed - at the bottom of each page, and sometimes appearing also on the title page. - - - - - - - - - - - - -

While it is often called a "plate number", it does not always contain numbers. The - facs attribute may be used to record the location of the plate number in a - facsimile image.

- - - - Playing speed for a sound recording is the speed at which the carrier must be operated to - produce the sound intended (e.g., 33 1/3 rpm, 19 cm/s, etc.). - - - - - - - - - - - - The cost of access to a bibliographic item. - - - - - - - - - - - - - - - - - - - - Numeric value capturing a cost. Can only be interpreted in combination with the - currency attribute. - - - [0-9]+\.[0-9]{2} - - - - - Monetary unit. - - - - - - -

Best practice suggests the use of controlled vocabulary for the currency attribute, such as - the ISO 4217 list of currency designators.

- - - - project description - Project-level meta-data describing the aim or purpose for which - the electronic file was encoded, funding agencies, etc. together with any other relevant - information concerning the process by which it was assembled or collected. - - - - - - - - - - - - - - - - -

The model of this element is based on the projectDesc element of the Text Encoding Initiative (TEI).

- - - - The record of ownership or custodianship of an item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the respective element of the Encoded Archival Description (EAD) and the provenance element of the Text - Encoding Initiative (TEI).

- - - - publication statement - Container for information regarding the publication or - distribution of a bibliographic item, including the publisher’s name and address, the date of - publication, and other relevant details. - - - - - - - - - - - - - - - - - - -

When an item is unpublished, use only the unpub sub-element.

- - -

The model of this element is based on the publicationStmt element of the Text Encoding Initiative (TEI).

- - - - revision description - Container for information about alterations that have been made - to an MEI file. - - - - - - - - - - - - - -

It is recommended that changes be recorded in reverse chronological order, with the most - recent alteration first.

- - -

The model of this element is based on the revisionDesc element of the Text Encoding Initiative (TEI).

- - - - sampling declaration - Contains a prose description of the rationale and methods used in - sampling texts in the creation of a corpus or collection. - - - - - - - - - - - - - - - - -

The model of this element is based on the samplingDecl element of the Text Encoding Initiative (TEI).

- - - - Describes the type of score used to represent a musical composition (e.g., short score, - full score, condensed score, close score, etc.). - - - - - - - - - - - - - Describes the principles according to which the musical text has been segmented, for - example into movements, sections, etc. - - - - - - - - - - - - - - - - -

The model of this element is based on the segmentation element of the Text Encoding Initiative (TEI).

- - - - series statement - Groups information about the series, if any, to which a publication - belongs. - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The title sub-element records the series title, the respStmt element records the person or group responsible for the series, and the identifier element contains a series identifier. The contents element should be used when it is necessary to enumerate the content of the - series, but not describe each component. The seriesStmt element is - provided within seriesStmt for the description of a sub-series.

- - -

The model of this element is based on the seriesStmt element of the Text Encoding Initiative (TEI).

- - - - sound channels - Reflects the number of apparent sound channels in the playback of a - recording (monaural, stereophonic, quadraphonic, etc.). - - - - - - - - - - - - - - - - - - Records the channel configuration in numeric form. - - - - - - -

The number of apparent playback channels can differ from the number of physical channels of - the recording medium, i.e., 2-track monophonic recordings. In this example, the soundChan - element should record the fact that there is a single output channel, while the trackConfig element should capture the existence of two physical tracks. - This element is analogous to MARC field 344 subfield g.

- - - - A bibliographic description of a source used in the creation of the electronic - file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @target attribute should - have content. - Each value in @target should correspond to the @xml:id attribute of a source or - manifestation element or be an external URI. - - - - -

This element contains, or references via its target attribute, a description of - a source used in the creation of the electronic file. For description of a physical - embodiment of an expression of a work use the manifestation - element.

-

The data attribute may be used to reference one or more musical features found - in the content of this particular source.

- - -

The model of this element is based on the source element of the Text Encoding Initiative (TEI) and the source element of the Encoded - Archival Description (EAD).

- - - - source description - A container for the descriptions of the source(s) used in the - creation of the electronic file. - - - - - - - - - - - - -

This element is recommended where the MEI file is a transcription of existing music, but is - not required when the data is originally created in MEI form.

- - - - special reproduction characteristic - The equalization system, noise reduction system, - etc. used in making the recording (e.g., NAB, DBX, Dolby, etc.). - - - - - - - - - - - - - standard values - Specifies the format used when standardized date or number values are - supplied. - - - - - - - - - - - - - - - - -

The model of this element is based on the stdVals element of the Text Encoding Initiative (TEI).

- - - - system requirements - System requirements for using the electronic item. - - - - - - - - - - - - tagging declaration - Provides detailed information about the tagging applied to a - document. - - - - - - - - - - - - - - - - -

The model of this element is based on the tagsDecl element of the Text Encoding Initiative (TEI).

- - - - Documents the usage of a specific element within the document. - - - - - - - - - - - - - - - - @context attribute should - contain an XPath expression. - - - - - - Name of the element. - - - - - - Circumstances in which the element appears, an XPath expression. - - - - - - Number of occurrences in the defined context. - - - - - - Number of occurrences in the defined context that have an xml:id - attribute. - - - - - - -

The model of this element is based on the tagUsage element of the Text Encoding Initiative (TEI).

- - - - Defines a typology either implicitly, by means of a bibliographic citation, or explicitly - by a structured taxonomy. - - - - - - - - - - - - - - - - - - - - - - - - Collection of text phrases which describe a resource. - - - - - - - - - - - - - - - - - - - - When labels are used, - usually each term has one. - - - - -

An external taxonomy from which all the descendant term elements are - drawn may be referred to using the target attribute.

- - - - title statement - Container for title and responsibility meta-data. - - - - - - - - - - - - - - - - - - -

The model of this element is based on the titleStmt element of the Text Encoding Initiative (TEI).

- - - - track configuration - Number of physical/input tracks on a sound medium (e.g., eight - track, twelve track). - - - - - - - - - - - - - Records the track configuration in numeric form. - - - - - - -

The number of apparent playback channels can differ from the number of physical channels of - the recording medium, i.e., 2-track monophonic recordings. In this example, the trackConfig - element should record the fact that there are two physical tracks on the sound medium, while - the soundChan element should be used to state that there is a single - output channel. This element may be mapped to MARC field 344 subfield e or subfield f as - appropriate.

- - - - treatment history - A record of the treatment the item has undergone (e.g., - de-acidification, restoration, etc.). - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Treatment history may also comprise details of the treatment process (e.g., chemical - solutions used, techniques applied, etc.), the date the treatment was applied, etc.

- - -

The model of this element is based on the respective element of the Encoded Archival Description (EAD).

- - - - treatment scheduled - Scheduled treatment, e.g., de-acidification, restoration, etc., for - an item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the respective element of the Encoded Archival Description (EAD).

- - - - unpublished - Used to explicitly indicate that a bibliographic resource is - unpublished. - - - - - - - - - - -

A short phrase indicating the nature of or the reason for the unpublished status may be - given as the element’s content.

- - - - usage restrictions - Container for information about the conditions that affect use of a - bibliographic item after access has been granted. - - - - - - - - - - - -

useRestrict may indicate limitations imposed by an owner, - repository, or legal statute (for example, copyright law) regarding the reproduction, - publication, or quotation of the item. It may also indicate the absence of restrictions, - such as when rights have been ceded to the public domain. Do not confuse this element with - the accessRestrict element, which holds information about conditions - affecting the availability of the material.

- - -

The model of this element is based on the userestrict element of the Encoded Archival Description (EAD).

- - - - Contains a description of a watermark or similar device. - - - - - - - - - - - - -

The facs attribute may be used to record the location of the watermark in a - facsimile image.

- - -

The model of this element is based on the watermark element of the Text Encoding Initiative (TEI).

- - - - Provides a detailed description of a work — a distinct intellectual or artistic creation — - specifically its history, language use, and high-level musical attributes (e.g., key, tempo, - meter, medium of performance, and intended duration). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The perfDuration element captures the intended duration - of the work.

- - - - work list - Grouping mechanism for information describing non-bibliographic aspects of a - text. - - - - - - - - - - - - - - - - - Lyrics component declarations. - - - Logical domain attributes. - - - - - - - - Logical domain attributes. The n attribute should be used for verse numbers. Numbers need - not be consecutive; they may also be expressed as ranges, e.g., 2-3,6. - - - Logical domain attributes. The n attribute should be used for verse numbers. Numbers need - not be consecutive; they may also be expressed as ranges, e.g., 2-3,6. - - - Logical domain attributes. The n attribute should be used for repetition numbers. Numbers - need not be consecutive; they may also be expressed as ranges, e.g., 2-3,6. - - - Groups elements that contain a lyric verse. - - - - - - - - Recurring lyrics, especially at the end of each verse or stanza of a poem or song lyrics; - a chorus. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The lb element is allowed here in order to facilitate karaoke - applications. The func attribute on lb may be used to - distinguish true line endings from those of line groups for these applications.

- - - - Division of a poem or song lyrics, sometimes having a fixed length, meter or rhyme scheme; - a stanza. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The lb element is allowed here in order to facilitate karaoke - applications. The func attribute on lb may be used to - distinguish true line endings from those of line groups for these applications.

- - - - Sung text for a specific iteration of a repeated section of music. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The volta element is intended for those cases where the musical notation is repeated, but - the accompanying lyrics are not.

- - - - - - Mensural repertoire component declarations. - - - Logical, that is, written, note-shape (or note symbol) attribute values for the mensural repertoire. - - - - Two or three times as long as a longa. - - - Two or three times as long as a brevis. - - - Two or three times as long as a semibreve. - - - Half or one-third as long as a breve/brevis. - - - Half or one-third as long as a semibreve/semibrevis. - - - Half as long as a minima. - - - Half as long as a semiminima. - - - Half as long as a fusa. - - - - - - Logical, that is, written, duration attribute values for multi-breve rests in the mensural repertoire. - - - - A two-breve rest. - - - A three-breve rest. - - - - - - Logical, that is, written, duration attribute values for mensural rests. - - - - - - - - - Duration attribute values of a given note symbol for the mensural repertoire. - - - - Three times the duration of the note in the next smaller degree. - - - Two times the duration of the note in the next smaller degree. - - - Twice the original duration of the note (only usable in perfect mensurations). - - - Category of a regular semibrevis in Ars antiqua, equivalent to a third of a brevis. - - - Category of an altered semibrevis in Ars antiqua, equivalent to two minor semibrevis. - - - One of the three categories of a longa in Ars antiqua ('duplex', 'perfecta', and 'imperfecta'). A duplex longa is twice as long as a regular longa. - - - - - - Form of the flag. - - - - Flag is a straight horizontal line. - - - Flag is a straight line at an angle. - - - Flag is curled. - - - Flag is flared. - - - Flag looks extended. - - - Flag is hooked-form. - - - - -

- - -

- - - - Position of the flag relative to the stem. - - - - Flag lies at the left side of the stem. - - - Flag lies at the right side of the stem. - - - Flag is centered in the stem. - - - - - - Items in the Mensural repertoire that may be printed near a staff. - - - - Ligatures. - - - - - - Form of the stem attached to the note. - - - - Stem has a circular form. - - - Stem has an oblique form. - - - Stem has a swallowtail form. - - - Stem has a virgula-like form. - - - - - - Attribute that expresses duration for a given mensural note symbol. - - - - - Duplex quality can only be used with longas (in Ars antiqua). - - - - - - - - - Maior / minor quality can only be used with semibreves (in Ars antiqua). - - - - - - - Encodes the durational quality of a mensural note using the values provided by the data.DURQUALITY.mensural datatype (i.e., the perfect / imperfect / altered / major / minor / duplex quality of a note). - - - - - - - - Logical domain attributes. - - - Used by staffDef and scoreDef to provide default values for attributes in the logical - domain related to mensuration. The tempus, prolatio, modusmaior, and modusminor attributes - (from the att.mensural.shared class) specify the relationship between the four principle - levels of note value, i.e., the long, breve, semibreve and minim, in mensural notation. - Modusminor describes the long-breve relationship, while tempus describes the breve-semibreve, - and prolatio the semibreve-minim relationship, respectively. Modusmaior is for the maxima-long - relationship. The proport.* attributes describe augmentation or diminution of the normal value - of the notes in mensural notation. - - - - - - Together, proport.num and proport.numbase specify a proportional change as a ratio, - e.g., 1:3. Proport.num is for the first value in the ratio. - - - - - - Together, proport.num and proport.numbase specify a proportional change as a ratio, - e.g., 1:3. Proport.numbase is for the second value in the ratio. - - - - - - - - Shared attributes in the mensural repertoire. - - - - - When the @divisio attribute is used, the @tempus and @prolatio attributes are not allowed. - - - - - - - Describes the maxima-long relationship. - - - - - - Describes the long-breve relationship. - - - - - - Describes the semibreve-minim relationship. - - - - - - Describes the breve-semibreve relationship. - - - - - - Describes the divisions of the breve in use in 14th-century Italy. - - - - - - - - Analytical domain attributes in the Mensural repertoire. - - - Gestural domain attributes in the Mensural repertoire. - - - - - - Logical domain attributes in the Mensural repertoire. - - - Visual domain attributes in the Mensural repertoire. - - - Indicates this element’s participation in a ligature. - - - - - - - - Logical domain attributes that describe the properties of a plica in the mensural repertoire. - - - Logical domain attributes. These attributes describe augmentation or diminution of the - normal value of the notes in mensural notation as a ratio. - - - - - - Gestural domain attributes. - - - - - - Visual domain attributes. - - - States how many spaces are covered by the rest. - - - - - - - - Logical domain attributes for a score in the mensural repertoire. The values set in these - attributes act as score-wide defaults for attributes that are not set in descendant - elements. - - - - - - Visual domain attributes for scoreDef in the mensural repertoire. - - - - - - Logical domain attributes for staffDef in the mensural repertoire. - - - - - - Visual domain attributes for the mensural repertoire. - - - - - - Logical domain attributes that describe the properties of a stem in the mensural repertoire. - - - Attributes that describe the properties of stemmed features specific to mensural repertoires. - - - Records the form of the stem. - - - - - - - - Groups event elements that occur in the mensural repertoire. - - - - - - Groups notated events that may appear at the layer level in the mensural - repertoire. - - - - - - - - Groups elements that may appear in the declaration of staff features. - - - - - - Groups elements that are components of a staff in the mensural repertoire. - - - - - - A mensural notation symbol that combines two or more notes into a single sign. - - - - - - - - - - - - - - - - - - - - - - -

The rhythmic meaning of the components of a ligature is typically contextual, not absolute; - therefore, an interpretative duration may be encoded on each of the components using either - the dur.ges attribute or the num and numbase attribute - pair. The ligature element should not be used for - brackets in modern notation that indicate notes that were part of a ligature in the original - source.

- - - - mensuration - Collects information about the metrical relationship between a note value - and the next smaller value; that is, either triple or duple. - - - - - - - - - - - - - - -

The mensur element is provided for the encoding of mensural notation. - The slash attribute indicates the number lines added to the mensuration sign. For - example, one slash is added for what we now call 'alla breve'.

- - - - Plica - - - - - - - - - - - - Only one plica is allowed. - - - - - - proportion - Description of note duration as arithmetic ratio. - - - - - - - - - - - - - - -

The proport element is provided for the encoding of mensural notation. It allows the - description of note durations as arithmetic ratios. While mensuration refers to the normal - relationships between note durations, proportion affects the relations of the note durations - to the tactus.

- - - - A stem element. - - - - - - - - - - - - - - - A note with nested stem elements must not have @stem.* attributes. - - - - -

Mensural notes can have multiple stems and these may have various forms, directions, and types of flags. - Multiple stem elements can be encoded as children of a single note. The attributes pos, - length, form, and dir allow to encode different positions, lengths, - forms, and directions for each these stems. The attributes flag.pos and flag.form - also allow to encode different types of flags for each of the stems.

- - - - - - MIDI component declarations. - - - Attributes that record MIDI channel information. - - - Records a MIDI channel value. - - - - - - Specifies the 'on' part of the duty cycle as a percentage of a note’s duration. - - - - - - Sets the MIDI port value. - - - - - - Sets the MIDI track. - - - - - - - - Logical domain attributes. - - - Attributes which identify a MIDI instrument. - - - Provides a way of pointing to a MIDI instrument definition. It must contain the ID of - an instrDef element elsewhere in the document. - - - - - - - @instr attribute - should have content. - The value in @instr should correspond to the @xml:id attribute of an instrDef - element. - - - - - - - - Attributes common to MIDI events. - - - - - - - - - - Logical domain attributes. - - - - - - - - Attributes that record MIDI instrument information. - - - - Only one of @midi.instrname and @midi.instrnum - allowed. - - - - - - - Only one of @midi.patchname and @midi.patchnum - allowed. - - - - - - Captures the General MIDI instrument number. Use an integer for a 0-based value. An - integer preceded by "in" indicates a 1-based value. - - - - - - Provides a General MIDI label for the MIDI instrument. - - - - - - Sets the instrument’s position in a stereo field. MIDI values of 0 and 1 both pan - left, 127 or 128 pans right, and 63 or 64 pans to the center. Positve percentage values - pan to the right, negative ones to the left. 0% is centered. - - - - - - Records a non-General MIDI patch/instrument name. - - - - - - Records a non-General MIDI patch/instrument number. - - - - - - Sets the instrument’s volume. - - - - - - - - Attributes that record MIDI numbers. - - - number - MIDI number in the range set by data.MIDIVALUE. - - - - - - - - Attributes that record MIDI tempo information. - - - Captures the number of *quarter notes* per minute. In MIDI, a beat is always defined - as a quarter note, *not the numerator of the time signature or the metronomic - indication*. - - - - - - Records the number of microseconds per *quarter note*. In MIDI, a beat is always - defined as a quarter note, *not the numerator of the time signature or the metronomic - indication*. At 120 quarter notes per minute, each quarter note will last 500,000 - microseconds. - - - - - - - - Attributes that record MIDI values. - - - MIDI number. - - - - - - - - Attributes that record terminal MIDI values. - - - MIDI number. - - - - - - - - MIDI attributes pertaining to key velocity. - - - MIDI Note-on/off velocity. - - - - - - - - Attributes that record time-base information. - - - Indicates the number of pulses (sometimes referred to as ticks or divisions) per - quarter note. Unlike MIDI, MEI permits different values for a score and individual - staves. - - - - - - - - Groups elements which group MIDI-like elements. - - - - - - - - control change - MIDI parameter/control change. - - - - - - - - - - -

The num attribute specifies a MIDI parameter number, while val - contains the parameter value. Each must fall in the range 0-127.

- - - - channel - MIDI channel assignment. - - - - - - - - - - MIDI number in the range set by data.MIDICHANNEL. - - - - - - - - channel pressure - MIDI channel pressure/after touch. - - - - - - - - - -

The value of the num attribute must be in the range 0-127.

- - - - MIDI cue point. - - - - - - - - - - - Arbitrary MIDI data in hexadecimal form. - - - - - - - - -

The element’s content must be wrapped in a CDATA section to avoid parsing errors.

- - - - instrument definition - MIDI instrument declaration. - - - - - - - - - - - - - - - - - - -

This element provides a starting or default instrument declaration for a staff, a group of - staves, or a layer. Following scoreDef, staffDef, layerDef, or MIDI prog elements may then - change the instrument as necessary.

- - - - instrument group - Collects MIDI instrument definitions. - - - - - - - - - - - MIDI marker meta-event. - - - - - - - - - - - MIDI text meta-event. - - - - - - - - - - - Container for elements that contain information useful when generating MIDI output. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The label attribute can be used to differentiate between multiple MIDI data - streams, e.g., quantized/unquantized, straight/swing, ornamented/as notated, etc.

- - - - MIDI note-off event. - - - - - - - - - - - MIDI note-on event. - - - - - - - - - - - MIDI port. - - - - - - - - - - - program - MIDI program change. - - - - - - - - - - - sequence number - MIDI sequence number. - - - - - - - - - - Number in the range 0-65535. - - - 65535 - - - - - - - track name - MIDI track/sequence name. - - - - - - - - - - - velocity - MIDI Note-on/off velocity. - - - - - - - - - - - Indicates whether this is note-on or note-off velocity data. - - - Note-on velocity. - - - Note-off velocity. - - - - - - - - - Manuscript description component declarations. - - - Attributes that express the relationship between a component and its host. - - - - - - - The comptype attribute may occur on - only when it is a descendant of a - componentList. - - - - - - A physical and logical part of entity. - - - A physical, but not logical component of the entity, usually included as part of - the binding process. - - - A logical component of the entity physically held elsewhere. - - - - - - - Attributes that describe foliation schemes. - - - Identifies the foliation scheme in terms of which the location is being specified by - pointing to some foliation element defining it, or to some other equivalent - resource. - - - - - - - - Groups elements that may appear inline when the msdesc module is active. - - - - - - Holds a description of any additional material bound with an item, such as - non-contemporaneous documents or fragments. - - - - - - - - - - -

The model of this element is based on the accMat element of the Text Encoding Initiative (TEI).

- - - - addition description - Provides a description of significant additions found within an - item, such as marginalia or other annotations. - - - - - - - - - - -

The model of this element is based on the additions element of the Text Encoding Initiative (TEI).

- - - - binding - Contains a description of one binding, i.e., type of covering, boards, etc. - applied to an item. - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the binding element of the Text Encoding Initiative (TEI).

- - - - binding description - Describes the present and former bindings of an item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the bindingDesc element of the Text Encoding Initiative (TEI).

- - - - Describes the system used to ensure correct ordering of the quires making up an item, - typically by means of annotations at the foot of the page. - - - - - - - - - - - - - - The catchwords element may only appear as a - descendant of the physDesc element. - - - - -

The model of this element is based on the catchwords element of the Text Encoding Initiative (TEI).

- - - - Records a description of how the leaves or bifolia of an item are physically - arranged. - - - - - - - - - -

The model of this element is based on the collation element of the Text Encoding Initiative (TEI).

- - - - Contains a statement providing information regarding the date, place, agency, or reason - for production of the item. - - - - - - - - - - - -

The model of this element is based on the colophon element of the Text Encoding Initiative (TEI).

- - - - decoration description - Contains a description of the decoration of an item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the decoDesc element of the Text Encoding Initiative (TEI).

- - - - decoration note - Contains a description of one or more decorative features of an - item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the decoNote element of the Text Encoding Initiative (TEI).

- - - - Contains the explicit of a manuscript item; that is, the closing words of the text proper, - exclusive of any rubric or colophon which might follow it. - - - - - - - - - - - -

The model of this element is based on the explicit element of the Text Encoding Initiative (TEI).

- - - - Describes the numbering system or systems used to count the leaves or pages in a - codex. - - - - - - - - - -

The model of this element is based on the foliation element of the Text Encoding Initiative (TEI).

- - - - Contains a heraldic formula or phrase, typically found as part of a blazon, coat of arms, - etc. - - - - - - - - - - - - -

The model of this element is based on the heraldry element of the Text Encoding Initiative (TEI).

- - - - Describes how text is laid out on the page, including information about any ruling, - pricking, or other evidence of page-preparation techniques. - - - - - - - - - - - Specifies the number of columns per page. - - - - -

A single number indicates that all pages have this number of columns. Two numbers mean - that the number of columns per page varies between the values supplied.

- - - - Specifies the number of ruled text lines per column. - - - - -

A single number indicates that all columns have this number of ruled lines. Two - numbers mean that the number of text lines per column varies between the values - supplied.

- - - - Specifies the number of written text lines per column. - - - - -

A single number indicates that all columns have this number of written text lines. Two - numbers mean that the number of text lines per column varies between the values - supplied.

- - - - Specifies the number of ruled staves per column. - - - - -

A single number indicates that all columns have this number of ruled staves. Two - numbers mean that the number of ruled staves per column varies between the values - supplied.

- - - - Specifies the number of written staves per column. - - - - -

A single number indicates that all columns have this number of written staves. Two - numbers mean that the number of written staves per column varies between the values - supplied.

- - - - -

The model of this element is based on the layout element of the Text Encoding Initiative (TEI).

- - - - layout description - Collects layout descriptions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the layoutDesc element of the Text Encoding Initiative (TEI).

- - - - Defines a location within a manuscript or manuscript component, usually as a (possibly - discontinuous) sequence of folio references. - - - - - - - - - - - - - - - - - - - - Specifies the starting point of the location in a normalized form. - - - - - - Specifies the end-point of the location in a normalized form. - - - - - - -

The model of this element is based on the locus element of the Text Encoding Initiative (TEI).

- - - - locus group - Groups locations which together form a distinct but discontinuous item - within a manuscript or manuscript part, according to a specific foliation. - - - - - - - - - - - - - - - - The locusGrp element may only appear as a descendant of a physDesc element, a - contentItem element, or a source element that is a component of another source or - work. - - - - -

The model of this element is based on the locusGrp element of the Text Encoding Initiative (TEI).

- - - - Contains a string of words through which a manuscript signals the beginning or end of a - text division, often with an assertion as to its author and title, which is in some way set - off from the text itself, usually in red ink, or by use of different size or type of script, - or some other such visual device. - - - - - - - - - - - - - - - Signals beginning of a text division. - - - Marks the end of a text division. - - - - - -

The model of this element is based on the rubric element of the Text Encoding Initiative (TEI).

- - - - script description - Contains a description of the letters or characters used in an - autographic item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the scriptDesc element of the Text Encoding Initiative (TEI).

- - - - script note - Describes a particular script distinguished within the description of an - autographic item. - - - - - - - - - -

The model of this element is based on the scriptNote element of the Text Encoding Initiative (TEI).

- - - - A single seal or similar attachment. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the seal element of the Text Encoding Initiative (TEI).

- - - - seal description - Describes the seals or similar external attachments applied to an - item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the sealDesc element of the Text Encoding Initiative (TEI).

- - - - second folio - Marks the word or words taken from a fixed point in a codex (typically - the beginning of the second leaf) in order to provide a unique identifier for the item. - - - - - - - - - - - - - - - The secFolio element may only appear as a - descendant of the physDesc element. - - - - -

The model of this element is based on the secFol element of the Text Encoding Initiative (TEI).

- - - - Provides a description of the leaf or quire signatures found within a codex. - - - - - - - - - - - - - - The signatures element may only appear as a - descendant of the physDesc element. - - - - -

The model of this element is based on the signatures element of the Text Encoding Initiative (TEI).

- - - - Contains a word or phrase describing an official mark indicating ownership, genuineness, - validity, etc. - - - - - - - - - - - - - -

The model of this element is based on the stamp element of the Text Encoding Initiative (TEI).

- - - - Provides a description of the physical support material of a written item. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the support element of the Text Encoding Initiative (TEI).

- - - - support description - Groups elements describing the physical support material of an - item. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Short, project-defined name for the material composing the majority of the - support. - - - - - - Paper. - - - Parchment. - - - Mixed materials. - - - - - -

The model of this element is based on the supportDesc element of the Text Encoding Initiative (TEI).

- - - - type description - Contains a description of the typefaces or other aspects of the - printing of a printed source. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the typeDesc element of the Text Encoding Initiative (TEI).

- - - - type note - Describes a particular font or other significant typographic feature of a - printed resource. - - - - - - - - - -

The model of this element is based on the typeNote element in the Text Encoding Initiative (TEI).

- - - - - - Names and dates component declarations. - - - Groups elements used as part of a physical address. - - - - - - Groups elements which form part of a geographic name. - - - - - - Groups elements which contain names of individuals or corporate bodies. - - - - - - - Groups geographic name elements. - - - - - - - Groups elements that serve as stylistic labels. - - - - - - Groups place name elements. - - - - - - Groups elements which form part of a personal name. - - - additional name - Contains an additional name component, such as a nickname, epithet, or - alias, or any other descriptive phrase used within a personal name. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the addName element of the Text Encoding Initiative (TEI).

- - - - Contains the name of a geopolitical unit consisting of two or more nation states or - countries. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the bloc element of the Text Encoding Initiative (TEI).

- - - - corporate name - Identifies an organization or group of people that acts as a single - entity. - - - - - - - - - - - - - - - - - - - - -

Examples of corporate entities include names of associations, institutions, business firms, - non-profit enterprises, governments, government agencies, projects, programs, religious - bodies, churches, conferences, athletic contests, exhibitions, expeditions, fairs, and - ships. Usually, secondary name parts are encoded in corpName - sub-elements. The name of the list from which a controlled value is taken may be recorded - using the auth attribute.

- - -

The model of this element is based on the corpname element of the Encoded Archival Description (EAD).

- - - - Contains the name of a geopolitical unit, such as a nation, country, colony, or - commonwealth, larger than or administratively superior to a region and smaller than a - bloc. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the country element of the Text Encoding Initiative (TEI).

- - - - Contains the name of any kind of subdivision of a settlement, such as a parish, ward, or - other administrative or geographic unit. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the district element of the Text Encoding Initiative (TEI).

- - - - family name - Contains a family (inherited) name, as opposed to a given, baptismal, or - nick name. - - - - - - - - - - - - - - - - - - - - - - - Contains a forename, given or baptismal name. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the forename element of the Text Encoding Initiative (TEI).

- - - - generational name component - Contains a name component used to distinguish otherwise - similar names on the basis of the relative ages or generations of the persons named. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the genName element of the Text Encoding Initiative (TEI).

- - - - geographical feature name - Contains a common noun identifying a geographical - feature. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the geogFeat element of the Text Encoding Initiative (TEI).

- - - - geographic name - The proper noun designation for a place, natural feature, or political - jurisdiction. - - - - - - - - - - - - - - - - - - - - -

Examples include Black Forest; Baltimore, Maryland; and Quartier Latin, Paris. Geographic - name parts can be encoded using geogName sub-elements. For greater - specificity, however, use district, settlement, - region, country, and bloc - sub-elements. The name of the list from which a controlled value is taken, such as the - Thesaurus of Geographic Names (TGN), may be recorded using the auth - attribute.

- - -

The model of this element is based on the geogname element of the Encoded Archival Description (EAD).

- - - - name link - Contains a connecting phrase or link used within a name but not regarded as - part of it, such as "van der" or "of", "from", etc. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the nameLink element of the Text Encoding Initiative (TEI).

- - - - period name - A label that describes a period of time, such as 'Baroque' or '3rd Style - period'. - - - - - - - - - - - - - - - - - - - - -

The name of the list from which a controlled value is taken may be recorded using the - auth attribute.

- - - - personal name - Designation for an individual, including any or all of that individual's - forenames, surnames, honorific titles, and added names. - - - - - - - - - - - - - - - - - - - - - -

Parts of a personal name may be captured using persName sub-elements. - For greater specificity, however, use foreName, famName, genName, addName, genName, - nameLink, and roleName elements. The name of the list from which a controlled value for - persName is taken may be recorded using the auth attribute.

- - -

The model of this element is based on the persname element of the Encoded Archival Description (EAD).

- - - - postal box or post office box - Contains a number or other identifier for some postal - delivery point other than a street address. - - - - - - - - - - - - - - - - -

The model of this element is based on the postBox element of the Text Encoding Initiative (TEI).

- - - - postal code - Contains a numerical or alphanumeric code used as part of a postal address - to simplify sorting or delivery of mail. - - - - - - - - - - - - - - - - -

The model of this element is based on the postCode element of the Text Encoding Initiative (TEI).

- - - - Contains the name of an administrative unit such as a state, province, or county, larger - than a settlement, but smaller than a country. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the region element of the Text Encoding Initiative (TEI).

- - - - role name - Contains a name component which indicates that the referent has a particular - role or position in society, such as an official title or rank. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the roleName element of the Text Encoding Initiative (TEI).

- - - - Contains the name of a settlement such as a city, town, or village identified as a single - geopolitical or administrative unit. - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the settlement element of the Text Encoding Initiative (TEI).

- - - - full street address including any name or number identifying a building as well as the - name of the street or route on which it is located. - - - - - - - - - - - - - - - - - -

The model of this element is based on the street element of the Text Encoding Initiative (TEI).

- - - - style name - A label for a characteristic style of writing or performance, such as - 'bebop' or 'rock-n-roll'. - - - - - - - - - - - - - - - - - - - - -

Do not confuse this element with the periodName element. The name of - the list from which a controlled value is taken may be recorded using the auth - attribute.

- - - - - - Neume repertoire component declarations. - - - Items in the Neume repertoire that may be printed near a staff. - - - Logical domain attributes. - - - Identifies the different kinds of division. - - - - - - - - - - - - - - - - Logical domain attributes. - - - - - - - - - - - - Logical domain attributes. - - - - - - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - - - - - Captures written octave information. - - - - 9 - - - unknown - - - - - - pitch name - Contains a written pitch name. - - - [a-g]|unknown - - - - - - - Attributes that record visual details of neume notation. - - - - - - - - - - - - Connection to the previous component within the same neume; this attribute should not - be used for the first component of a neume. - - - Gapped; not connected. - - - Looped. - - - Extended. - - - - - Pen stroke has an extension; specific to Hispanic notation. - - - - - - Indicates participation in a ligature. - - - - - - Length of the pen stroke relative to the previous component within the same neume; - this attribute should not be used for the first component of a neume. - - - Longer. - - - Shorter. - - - - - Direction of the initial direction for an s-shaped pen stroke; i.e., "w" for the - standard letter S, "e" for its mirror image, "s" for the letter S turned 90-degrees - anti-clockwise, and "n" for its mirror image. - - - - - - Direction of the pen stroke. - - - - - - - - Logical domain attributes. - - - - - - - - - - Logical domain attributes. - - - - - - - - - - Attributes that specify the type of neumes. - - - Designation which characterizes the element in some sense, using any convenient - classification scheme or typology that employs single-token labels. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - Groups event elements that occur in the neume repertoire. - - - - - - - Groups notated events that may appear at the layer level in the neume repertoire. - - - - - - Groups elements that modify neume components. - - - Groups elements that modify neume-like features. - - - Groups elements that may occur within a neume. - - - - - - Groups elements that accommodate neumed text. - - - - - - Groups elements that may appear as part of the content of a syllable. - - - Episema. - - - - - - - - - - - - Hispanic tick. - - - - - - - - - - - - - - - Liquescent. - - - - - - - - - - - - Sign representing a single pitched event, although the exact pitch may not be - known. - - - - - - - - - - - - - - - - - - - - - - - - - - - - neume component group - Collection of one or more neume components. - - - - - - - - - - - - - - - - - - - - - - - - Sign representing one or more musical pitches. - - - - - - - - - - - - - - - - - - - - - - - - - - -

The MEI Neumes customization restricts the use of this element. This customization disallows neume as a direct child of layer.

- - - - Oriscus. - - - - - - - - - - - - Quilisma. - - - - - - - - - - - - Significantive letter(s). - - - - - - - - - - - - - - - - - - - - - - - Strophicus. - - - - - - - - - - - - Neume notation can be thought of as "neumed text". Therefore, the syllable element - provides high-level organization in this repertoire. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Represents a division (divisio) in neume notation. Divisions indicate short, medium, or long pauses - similar to breath marks in modern notation. - - - - - - - - - - - - - - - - - - - - - - Performance component declarations. - - - Temporal alignment attributes. - - - - @when attribute should - have content. - A - value in @when should correspond to the @xml:id attribute of a when - element. - - - - - - Indicates the point of occurrence of this feature along a time line. Its value must be - the ID of a when element elsewhere in the document. - - - - - - - - audio/video file - References an external digital audio or video file. - - - - - - - - - - - - - - - - - An avFile child of clip cannot have - children. - - - - -

This element is analogous to the graphic element in the figtable - module.

- - - - Defines a time segment of interest within a recording or within a digital audio or video - file. - - - - - - - - - - - - - - - - - - - When @begin or @end - is used, @betype should appear on clip or one of its ancestors. - - - - -

This element is analogous to the zone element in the facsimile - module.

- - - - A presentation of one or more musical works. - - - - - - - - - - - -

The decls attribute may be used to link the collection with a particular source - described in the header. This element is analogous to the facsimile - element in the facsimile module.

- - - - A recorded performance. - - - - - - - - - - - - - - - - - - - - - - When @begin or @end is used, @betype should be - present. - - - - -

The startid attribute may be used to hold a reference to the first feature - occurring in this performance. This element is analogous to the surface element in the facsimile module.

- - - - Indicates a point in time either absolutely (using the absolute attribute), or relative to - another when element (using the since, interval and inttype attributes). - - - - - - - - - - - - - @since must be present when @interval is used. - The value in @since should correspond to the @xml:id attribute of a when - element. - - - When @interval contains an integer value, - @inttype cannot be 'time'. - - - When @interval contains a time value, @inttype must - be 'time'. - - - - - - - When @absolute is - present, @abstype should be present or @betype should be present on an - ancestor. - - - - - - Provides an absolute value for the time point. - - - - - - Specifies the time interval between this time point and the one designated by the - since attribute. This attribute can only be interpreted meaningfully in conjunction with - the inttype attribute. - - - - 1 - - - - - - - Specifies the kind of values used in the absolute attribute. - - - - - - Specifies the kind of values used in the interval attribute. - - - - - - Identifies the reference point for determining the time of the current when element, - which is obtained by adding the interval to the time of the reference point. The value - should be the ID of another when element within the same parent element. If the since - attribute is omitted and the absolute attribute is not specified, then the reference point - is understood to be the immediately preceding when element. - - - - - - - @since attribute - should have content. - The value in @since should correspond to the @xml:id attribute of a when - element. - - - - - - -

The data attribute may be used to reference one or more features that occur at - this point in time.

- - -

The model of this element is based on the when element of the Text Encoding Initiative (TEI).

- - - - - - Pointer and reference component declarations. - - - Groups elements used for purposes of location and reference. - - - - - - pointer - Defines a traversible pointer to another location, using only attributes to - describe the destination. - - - - - - - - - - - - -

Unlike the ref element, ptr cannot contain text - or sub-elements to describe the referenced object.

- - -

The model of this element is based on the ptr element of the Encoded Archival Description (EAD) and the ptr element of the Text - Encoding Initiative (TEI).

- - - - reference - Defines a traversible reference to another location. May contain text and - sub-elements that describe the destination. - - - - - - - - - - - - - - - - - - -

Unlike the ptr element, ref may contain text - and sub-elements to describe the destination.

- - -

The model of this element is based on the ref element of the Encoded Archival Description (EAD) and the ref element of the Text - Encoding Initiative (TEI).

- - - - - - Component declarations that are shared between two or more modules. - - - Permits any XML elements except those from the MEI or SVG namespace. - - - - - - - - - - - - - - - - - - - - - - - - Groups elements that contain meta-data about a single page. - - - - - - - - - - - - - - Groups elements that may appear as part of the music element. - - - - - - - - - - - - - - - - - Provides a choice between structured and unstructured/mixed content. - - - - - - - - - - - - - - - - - - - - - Groups elements that may appear as part of a bibliographic title. - - - - - - - - - - - - - - - - - - - - - - - - - Datatypes for values in begin, end, abstype and inttype attributes. - - - - Bytes. - - - Synchronized Multimedia Integration Language. - - - MIDI clicks. - - - MIDI machine code. - - - MIDI time code. - - - SMPTE 25 EBU. - - - SMPTE 24 Film Sync. - - - SMPTE 30 Drop. - - - SMPTE 30 Non-Drop. - - - SMPTE 29.97 Drop. - - - SMPTE 29.97 Non-Drop. - - - AES Time-code character format. - - - ISO 24-hour time format: HH:MM:SS.ss. - - - - - - Logical domain attributes. - - - - - - - Records the function of an accidental. - - - Cautionary accidental. - - - Editorial accidental. - - - - - - - Attributes for capturing momentary pitch inflection. - - - Captures a written accidental. - - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - - - - Logical domain attributes for annot. Values for the type attribute can be taken from any - convenient typology of annotation suitable to the work in hand; e.g., annotation, gloss, - citation, digression, preliminary, temporary, etc. - - - - - - - - - - - - - - Logical domain attributes. - - - - - - - Attributes for capturing the written signs that describe the method of performance. - - - Encodes the written articulation(s). Articulations are normally encoded in order from - the note head outward; that is, away from the stem. See additional notes at att.vis.note. - Only articulations should be encoded in the artic attribute; for example, fingerings - should be encoded using the fing element. - - - - - - - - Logical domain attributes. - - - - - - - - Indicates the next section or movement to be performed. - - - - - - - @target attribute - should have content. - The value in @target should correspond to the @xml:id attribute of a section or - mdiv element. - - - - - - - - Attributes that describe the intended audience. - - - The intended audience. - - - Internal use only. - - - Available to all audiences. - - - - - - - Attributes that record the number of dots of augmentation. - - - Records the number of augmentation dots required by a written dotted duration. - - - - - - - An element with a dots attribute must also have a dur - attribute. - - - - - - -

The dots attribute records the number of augmentation dots necessary to - represent a non-power-of-two duration. This is usually, but not always, the number of dots - displayed. For example, a note with this attribute will result in displayed dots, while a - glissando will not.

- - - - Attributes that describe the source of a controlled value. - - - - - - A name or label associated with a controlled vocabulary or other authoritative source - for this element or its content. - - - - - - A web-accessible location of the controlled vocabulary or other authoritative source - of identification or definition for this element or its content. This attribute may - contain a complete URI or a partial URI which is completed by the value of the codedval - attribute. - - - - - - - - Logical domain attributes. - - - - - - Records the appearance and usually the function of the bar line. - - - - - - - - Attributes that capture the placement of bar lines. - - - States the length of bar lines in virtual units. The value must be greater than 0 and - is typically equal to 2 times (the number of staff lines - 1); e.g., a value of 8 for a - 5-line staff. - - - 0 - - - -

This attribute is ignored if the value of the bar.style attribute is mensur.

- - - - Records the method of barring. - - - - - - - "mensur" not allowed in this - context. - - - - - - Denotes the staff location of bar lines, if the length is non-standard; that is, not - equal to 2 times (the number of staff lines - 1). - - - - -

The location may include staff lines, the spaces between the lines, and the spaces - directly above and below the staff. The value ranges between 0 (just below the staff) to - 2 * number of staff lines (directly above the staff). For example, on a 5-line staff the - lines would be numbered 1, 3, 5, 7, and 9 while the spaces would be numbered 0, 2, 4, 6, - 8, and 10. So, a value of 9 puts the bar line through the top line of the staff.

-

This attribute is ignored if the value of the bar.style attribute is mensur.

- - - - - - Attributes that form the basis of the att.common class. - - - - - - - Provides a base URI reference with which applications can resolve relative URI - references into absolute URI references. - - - - - - - - Bibliographic attributes. - - - Contains a reference to a field or element in another descriptive encoding system to - which this MEI element is comparable. - - - - - - -

Mapping elements from one system to another via analog may help a repository - harvest selected data from the MEI file to build a basic catalog record. The encoding system - from which fields are taken must be specified. When possible, subfields as well as fields - should be specified, e.g., subfields within MARC fields.

- - - - Logical domain attributes. - - - - - - - - - - Attributes that indicate the calendar system of a date or other datable element. - - - Indicates the calendar system to which a date belongs, for example, Gregorian, Julian, - Roman, Mosaic, Revolutionary, Islamic, etc. - - - - - - - - Attributes that can be used to associate a representation such as a name or title with - canonical information about the object being named or referenced. - - - A value that represents or identifies other data. Often, it is a primary key in the - database or a unique value in the coded list identified by the auth or - auth.uri attributes. - - - - - - - - Logical domain attributes for chord. The artic, dots, and dur attributes encode the - written articulations, augmentation dots, and duration values. The beam, fermata, lv, slur, - syl, tie, and tuplet attributes may be used to indicate the attachment of these things to this - chord. If visual information about these things needs to be recorded, then either the elements - corresponding to these attributes or the attributes available in the att.vis.chord class - should be employed. - - - - - - - - - - - - Attributes which can be used to classify features. - - - Contains one or more URIs which denote classification terms that apply to the entity - bearing this attribute. - - - - - - - The value in @class must either correspond to the @xml:id attribute of a category - element or be an external URL. - - - - - - - - Logical domain attributes. - - - - - - - - - Records the function of the clef. A "cautionary" clef does not change the following - pitches. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the logical - domain related to clefs. - - - - An 'F', 'C', or 'G' clef requires that its position be - specified. - - - A TAB or percussion clef requires that the number of lines be - specified. - - - - - - Encodes a value for the clef symbol. - - - - - - Contains a default value for the position of the clef. The value must be in the range - between 1 and the number of lines on the staff. The numbering of lines starts with the - lowest line of the staff. - - - - - - Records the amount of octave displacement to be applied to the clef. - - - - - - Records the direction of octave displacement to be applied to the clef. - - - - - - - - Logical domain attributes. - - - Attributes that record the shape of a clef. - - - - When @shape is present, @line must also be - specified. - - - - - - Describes a clef’s shape. - - - - - - - - Visual color attributes. - - - Used to indicate visual appearance. Do not confuse this with the musical term 'color' - as used in pre-CMN notation. - - - - - - - - Indication of coloration. - - - Indicates this feature is 'colored'; that is, it is a participant in a change in - rhythmic values. In mensural notation, coloration is indicated by colored notes (red, - black, etc.) where void notes would otherwise occur. In CMN, coloration is indicated by an - inverse color; that is, the note head is void when it would otherwise be filled and vice - versa. - - - - - - - - Attributes common to many elements. - - - - - - - - - - - Attributes specifying whether a feature is contemporary or historical. - - - - - - - - - - Attributes shared by events which rely on other events for their existence. For example, a - slur/phrase marking must be drawn between or over a group of notes. The slur is therefore a - control event. - - - - - - - - - - - - - This attribute class records the position of a feature within a two-dimensional coordinate - system. - - - - - - Indicates the lower-right corner x coordinate. - - - - - - Indicates the lower-left corner x coordinate. - - - - - - - Indicates the amount by which the contents of this element have been rotated clockwise or, if applicable, how the orientation of - the element self should be interpreted, with respect to the normal orientation of the parent surface. - The orientation is expressed in arc degrees. - - - - - 0 - -

This attribute is based on the TEI attribute of the same name.

- - - - - - This attribute class records the upper left position of a feature within a two-dimensional coordinate - system. - - - Indicates the upper-left corner x coordinate. - - - - - - Indicates the upper-left corner y coordinate. - - - - - - - - Attributes that describe "cue-ness". - - - - - - - - - - Attributes that describe curvature. - - - Records the placement of Bezier control points as a series of pairs of space-separated - values; e.g., 19 45 -32 118. - - - - - - - - - - - Describes a curve as one or more pairs of values with respect to an imaginary line - connecting the starting and ending points of the curve. The first value captures a - distance to the left (positive value) or right (negative value) of the line, expressed in - virtual units. The second value of each pair represents a point along the line, expressed - as a percentage of the line’s length. N.B. An MEI virtual unit (vu) is half the distance - between adjacent staff lines where the interline space is measured from the middle of a - staff line. - - - - - - - - - - - Describes a curve with a generic term indicating the direction of curvature. - - - Upward curve. - - - Downward curve. - - - A "meandering" curve, both above and below the items it pertains to. - - - - - - - Logical domain attributes. - - - - - - - Encodes the target note when its pitch differs from the pitch at which the custos - appears. - - - - - - - @target attribute - should have content. - The value in @target should correspond to the @xml:id attribute of a note - element. - - - - - - - - Attributes common to dates. - - - Contains the end point of a date range in standard ISO form. - - - - - - Provides the value of a textual date in standard ISO form. - - - - - - Contains an upper boundary for an uncertain date in standard ISO form. - - - - - - Contains a lower boundary, in standard ISO form, for an uncertain date. - - - - - - Contains the starting point of a date range in standard ISO form. - - - - - - - - Attributes for linking metadata to data. - - - Used to link metadata elements to one or more data-containing elements. - - - - - - - @data attribute should - have content. - The value in @data should correspond to the @xml:id attribute of a descendant of - the music element. - - - - - - - - Logical domain attributes. - - - - - - Provides attributes for elements which may be associated with particular contextual - elements within the header. - - - Identifies one or more metadata elements (other than classification terms) within the - header, which are understood to apply to the element bearing this attribute and its - content. - - - - - - - @decls attribute - should have content. - Each value in @decls should correspond to the @xml:id attribute of an element - within the metadata header. - No value in @decls should correspond to the @xml:id attribute of a classification - term. Use @class for this purpose. - - - - - - - - Attributes that capture the dimensions of an entity. - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that describe distance from the staff. - - - Records the default distance from the staff for directives. - - - - - - Records the default distance from the staff for dynamic marks. - - - - - - Records the default distance from the staff of harmonic indications, such as guitar - chord grids or functional labels. - - - - - - Records the default distance from the staff for rehearsal marks. - - - - - - Records the default distance from the staff for tempo marks. - - - - - - - - Logical domain attributes. - - - - - - Records the function of the dot. - - - Augmentation dot. - - - Dot of division. - - - - - - - Attributes that permit total duration to be represented by multiple values. - - - duration - When a duration cannot be represented as a single power-of-two value, multiple - space-separated values that add up to the total duration may be used. - - - - - - - - Attributes that provide a durational default value. - - - Contains a default duration in those situations when the first note, rest, chord, etc. - in a measure does not have a duration specified. - - - - - - Along with numbase.default, describes the default duration as a ratio. num.default is - the first value in the ratio. - - - - - - Along with num.default, describes the default duration as a ratio. numbase.default is - the second value in the ratio. - - - - - - - - Attributes that express duration in musical terms. - - - duration - Records the duration of a feature using the relative durational values provided by the - data.DURATION datatype. - - - - - - - - Attributes that describe duration as a ratio. - - - number - Along with numbase, describes duration as a ratio. num is the first value in the - ratio, while numbase is the second. - - - - - - Along with num, describes duration as a ratio. num is the first value in the ratio, - while numbase is the second. - - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that capture characters used to enclose symbols having a cautionary or - editorial function. - - - Records the characters often used to mark accidentals, articulations, and sometimes - notes as having a cautionary or editorial function. For an example of cautionary - accidentals enclosed in parentheses, see Read, p. 131, ex. 9-14. - - - - - - - - Logical domain attributes. - - - - - - Attributes that record ending style information - - - Describes where ending marks should be displayed. - - - Ending rendered only above top staff. - - - Ending rendered above staves that have bar lines drawn across them. - - - Endings rendered above staff groups. - - - - - - - Attributes that apply to all written events, e.g., note, chord, rest, etc. - - - - - - - - - - Attributes describing the support for and the certainty of an assertion. - - - Signifies the degree of certainty or precision associated with a feature. - - - - - - Indicates the nature of the evidence supporting the reliability or accuracy of the - intervention or interpretation. - - - - - - There is evidence within the document to support the intervention. - - - There is evidence outside the document to support the intervention. - - - The assertion has been made by the editor, cataloguer, or scholar on the basis of - their expertise. - - - - - - - Attributes that describe extension symbols, typically lines. Members of this class are - also typically members of the att.lineRend class. - - - - - - Indicates the presence of an extension symbol, typically a line. - - - - - - - - Provides attributes for describing the size of an entity. - - - - - - - Captures a measurement, count, or description. When extent contains a numeric value, - use the unit attribute to indicate the measurement unit. - - - - - - - The @unit attribute is - recommended. - - - Separation into value (@extent) and unit - (@unit) is recommended. - - - - - - - - Attributes indicating the attachment of a fermata to the feature. - - - Indicates the attachment of a fermata to this element. If visual information about the - fermata needs to be recorded, then a fermata element should be - employed instead. - - - - - - - - Attributes that deal with string filing characteristics. - - - Holds the number of initial characters (such as those constituting an article or - preposition) that should not be used for sorting a title or name. - - - - - - - - Attributes that record the function (i.e., placement) of forme work elements. - - - Records the function (i.e., placement) of a page header or footer. - - - - - - - - Logical domain attributes. - - - - - - - Indicates the nesting level of staff grouping symbols. - - - - - - - - Attributes which identify a document hand. - - - Signifies the hand responsible for an action. The value must be the ID of a hand element declared in the header. - - - - - - - @hand attribute should - have content. - Each value in @hand should correspond to the @xml:id attribute of a hand - element. - - - - - - - - Attributes that describe vertical size. - - - Measurement of the vertical dimension of an entity. - - - - - - - - Attributes that record horizontal alignment. - - - Records horizontal alignment. - - - - - - - - Attributes that uniquely identify an element. - - - - Regularizes the naming of an element and thus facilitates building links between it - and other resources. Each id attribute within a document must have a unique value. - - - - - - - - Attributes which record the type of an electronic resource. - - - Specifies the applicable MIME (multimedia internet mail extension) type. The value - should be a valid MIME media type defined by the Internet Engineering Task Force in RFC - 2046. - - - - - - - - Attributes indicating that elements are semantically linked; that is, while the parts are - encoded separately, together they may be thought of as a single intellectual object. - - - Used for linking visually separate entities that form a single logical entity, for - example, multiple slurs broken across a system break that form a single musical phrase. - Also used to indicate a measure which metrically completes the current one. Record the - identifiers of the separately encoded components, excluding the one carrying the - attribute. - - - - - - - @join attribute should - have content. - Each - value in @join should correspond to the @xml:id attribute of an - element. - - - - - - - - Logical domain attributes. - - - - - - - Attributes for describing key mode. - - - Indicates major, minor, or other tonality. - - - - - - - - Logical domain attributes. - - - Written key signature. - - - - - - -

Mixed key signatures, e.g., those consisting of a mixture of flats and sharps (Read, p. 143, - ex. 9-39), and key signatures with unorthodox placement of the accidentals (Read, p. 141) - can be encoded using the keySig element.

- - - - Used by staffDef and scoreDef to provide default values for attributes in the logical - domain that are related to key signatures. - - - Written key signature. - - - - - - -

Mixed key signatures, e.g., those consisting of a mixture of flats and sharps (Read, p. 143, - ex. 9-39), and key signatures with unorthodox placement of the accidentals (Read, p. 141) - can be encoded using the keySig element.

- - - - - - Captures text to be used to generate a label for the element to which it’s attached, a - "tool tip" or prefatory text, for example. Should not be used to record document - content. - - - - -

label is used to provide a display label for an element’s contents, for - example in the form of a "tool tip" or as the "name" when the element’s contents are - treated as the "value" in a "name-value pair". Unlike n, label may - contain space characters.

-

Don't confuse this attribute with the label element, which - records document content.

- - - - - - Language attributes common to text elements. - - - - Identifies the language of the element’s content. The values for this attribute are - language 'tags' as defined in BCP 47. All language tags that make use of private use - sub-tags must be documented in a corresponding language element in the MEI header whose id - attribute is the same as the language tag’s value. - - - - - - Specifies the transliteration technique used. - - - - -

There is no standard list of transliteration schemes.

- - - - -

BCP 47 is described at https://tools.ietf.org/html/bcp47. The IANA Subtag Registry, from which BCP 47 - language tags are constructed, may be found at www.iana.org/assignments/language-subtag-registry. A tool for locating subtags and - validating language tags is available at https://r12a.github.io/apps/subtags.

- - - - Logical domain attributes. - - - - - - - Provides a mechanism for linking the layer to a layerDef element. - - - - - - - @def attribute should - have content. - The value in @def should correspond to the @xml:id attribute of a layerDef - element. - - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that identify the layer to which a feature applies. - - - Identifies the layer to which a feature applies. - - - - - - - - Attributes for identifying the staff line with which a feature is associated. - - - Indicates the line upon which a feature stands. The value must be in the range between - 1 and the number of lines on the staff. The numbering of lines starts with the lowest line - of the staff. - - - - - - - - Attributes that record the visual rendition of lines. - - - - - - - line end symbol - Symbol rendered at end of line. - - - - - - Holds the relative size of the line-end symbol. - - - - - - line start symbol - Symbol rendered at start of line. - - - - - - Holds the relative size of the line-start symbol. - - - - - - - - Attributes that record the basic visual rendition of lines. - - - - Describes the style of a line. - - - - - - Width of a line. - - - - - - Describes the number of segments into which a dashed or dotted line may be divided, or - the number of "peaks" of a wavy line; a pair of space-separated values (minimum and - maximum, respectively) provides a range between which a rendering system-supplied value - may fall, while a single value indicates a fixed amount of space; that is, the minimum and - maximum values are equal. - - - 2 - - - - - - @lform attribute - matching "dashed", "dotted", or "wavy" required. - - - - - - - - - Attributes that specify element-to-element relationships. - - - Points to an element of which the current element is a copy. - - - - - - - An - element with a copyof attribute can only have comment or processing instruction - descendents. - - - - - - - @copyof attribute - should have content. - The - value in @copyof should correspond to the @xml:id attribute of an - element. - - - - - - Used to point to other elements that correspond to this one in a generic - fashion. - - - - - - - @corresp attribute - should have content. - Each - value in @corresp should correspond to the @xml:id attribute of an - element. - - - - - - points to one or more events in a user-defined collection that are known to be - predecessors of the current element. - - - - - - - @follows attribute - should have content. - Each - value in @follows must correspond to the @xml:id attribute of an - element. - - - - - - Used to point to the next event(s) in a user-defined collection. - - - - - - - @next attribute should - have content. - Each - value in @next should correspond to the @xml:id attribute of an - element. - - - - - - Points to one or more events in a user-defined collection that are known to be - successors of the current element. - - - - - - - @precedes attribute - should have content. - Each - value in @precedes must correspond to the @xml:id attribute of an - element. - - - - - - Points to the previous event(s) in a user-defined collection. - - - - - - - @prev attribute should - have content. - Each - value in @prev should correspond to the @xml:id attribute of an - element. - - - - - - Points to an element that is the same as the current element but is not a literal copy - of the current element. - - - - - - - @sameas attribute - should have content. - Each - value in @sameas should correspond to the @xml:id attribute of an - element. - - - - - - Points to elements that are synchronous with the current element. - - - - - - - @synch attribute - should have content. - Each - value in @synch should correspond to the @xml:id attribute of an - element. - - - - - - - - Attributes that describe default typography of lyrics. - - - Describes the alignment of lyric syllables associated with a note or chord. - - - - - - Sets the font family default value for lyrics. - - - - - - Sets the font name default value for lyrics. - - - - - - Sets the default font size value for lyrics. - - - - - - Sets the default font style value for lyrics. - - - - - - Sets the default font weight value for lyrics. - - - - - - - - Attributes that record the unit of measurement in which a value is expressed. - - - Indicates the unit of measurement. - - - - - - Byte. - - - Character. - - - Centimeter. - - - Degree. - - - Inch. - - - Serial issue. - - - Foot. - - - Meter. - - - Millimeter. - - - Page. - - - Pica. - - - Point. - - - Pixel. - - - Radian. - - - Record. - - - Serial volume. - - - MEI virtual unit. - - - - - - - Attributes pertaining to measure numbers - - - Indicates whether measure numbers should be displayed. - - - - - - - - Attributes that establish the boundaries of a media object. - - - Specifies a point where the relevant content begins. A numerical value must be less - and a time value must be earlier than that given by the end attribute. - - - - - - Specifies a point where the relevant content ends. If not specified, the end of the - content is assumed to be the end point. A numerical value must be greater and a time value - must be later than that given by the begin attribute. - - - - - - Type of values used in the begin/end attributes. The begin and end attributes can only - be interpreted meaningfully in conjunction with this attribute. - - - - - - - - Attributes describing a writing medium, such as pencil or ink. - - - Describes the writing medium. - - - - - - - - Attributes that record the version of MEI in use. - - - Specifies a generic MEI version label. - 5.1-dev - - - Development version - - - Development version - - - Development version - - - Development version - - - Development version - - - Development version - - - - - - - Logical domain attributes. - - - - - - - Level of duration at which the proportion given by the @num and @numbase ratio applies. - - - - - - - - Attributes that provide information about a structure’s conformance to the prevailing - meter. - - - meter conformance - Indicates the relationship between the content of a staff or layer and the prevailing - meter. - - - Complete; i.e., conformant with the prevailing meter. - - - Incomplete; i.e., not enough beats. - - - Overfull; i.e., too many beats. - - - - - - - Attributes that provide information about a measure’s conformance to the prevailing - meter. - - - meter conformance - Indicates the relationship between the content of a measure and the prevailing - meter. - - - - - - Indicates whether or not a bar line is "controlling"; that is, if it indicates a point - of alignment across all the parts. Bar lines within a score are usually controlling; that - is, they "line up". Bar lines within parts may or may not be controlling. When applied to - measure, this attribute indicates the nature of the right bar line - but not the left. - - - - - - - - Logical domain attributes. - - - Captures the number of beats in a measure, that is, the top number of the meter - signature. It must contain a decimal number or an expression that evaluates to a - decimal number, such as 2+3 or 3*2. - - - \d+(\.\d+)?(\s*[\+\-\*/]\s*\d+(\.\d+)?)* - - - - - symbol - Indicates the use of a meter symbol instead of a numeric meter signature, that is, 'C' - for common time or 'C' with a slash for cut time. - - - - - - Contains the number indicating the beat unit, that is, the bottom number of the meter - signature. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the logical - domain related to meter signature. - - - Captures the number of beats in a measure, that is, the top number of the meter - signature. It must contain a decimal number or an expression that evaluates to a - decimal number, such as 2+3 or 3*2. - - - \d+(\.\d+)?(\s*[\+\-\*/]\s*\d+(\.\d+)?)* - - - - - Contains the number indicating the beat unit, that is, the bottom number of the meter - signature. - - - 0 - - - - - Indicates the use of a meter symbol instead of a numeric meter signature, that is, 'C' - for common time or 'C' with a slash for cut time. - - - - - - - - Attributes that record tempo in terms of beats per minute. - - - Used to describe tempo in terms of beats (often the meter signature denominator) per - minute, ala M.M. (Maelzel’s Metronome). Do not confuse this attribute with midi.bpm or - midi.mspb. In MIDI, a beat is always defined as a quarter note, *not the numerator of the - time signature or the metronomic indication*. - - - - - - Captures the metronomic unit. - - - - - - Records the number of augmentation dots required by a dotted metronome unit. - - - - - - - - Attributes that indicate programmatic numbering. - - - Indicates whether programmatically calculated counts of multiple measures of rest - (mRest) and whole measure repeats (mRpt) in parts should be rendered. - - - - - - - - Attributes shared by names. - - - - - - - - Used to record a pointer to the regularized form of the name elsewhere in the - document. - - - - - - - @nymref attribute - should have content. - The - value in @nymref should correspond to the @xml:id attribute of an - element. - - - - - - Used to specify further information about the entity referenced by this name, for - example, the occupation of a person or the status of a place. - - - - -

When applicable, values from the MARC relator term list (http://www.loc.gov/marc/relators/relaterm.html) or code list (http://www.loc.gov/marc/relators/relacode.html) are recommended for - role.

- - - - - - Attributes used to supply an integer number designation for an element. - - - Provides a numeric designation that indicates an element’s position in a sequence of - similar elements. Its value must be a non-negative integer. - - - - - - - - Attributes used to supply a number-like designation for an element. - - - Provides a number-like designation that indicates an element’s position in a sequence - of similar elements. May not contain space characters. - - - - - - - - Attributes that capture music font name and size. - - - Sets the default music font name. - - - - - - Sets the default music font size. - - - - - - - - Logical domain attributes. - - - - - - - - - - - - - - Attributes pertaining to the notehead part of a note. - - - Provides a way of pointing to a user-defined symbol. It must contain a reference to an - ID of a symbolDef element elsewhere in the document. - - - - - - - @head.altsym attribute - should have content. - The value in @head.altsym should correspond to the @xml:id attribute of a symbolDef - element. - - - - - - A name or label associated with the controlled vocabulary from which a numerical value - of head.shape is taken. - - - - - - - When - @head.auth matches 'smufl', @head.shape must contain a numeric glyph reference in - hexadecimal notation, like "#xE000" or "U+E000". - - - - - - Standard Music Font Layout. - - - - - Captures the overall color of a notehead. - - - - - - Describes how/if the notehead is filled. - - - - - - Captures the fill color of a notehead if different from the overall note color. - - - - - - Records any additional symbols applied to the notehead. - - - - - - Describes rotation applied to the basic notehead shape. A positive value rotates the - notehead in a counter-clockwise fashion, while negative values produce clockwise - rotation. - - - - - - Used to override the head shape normally used for the given duration. - - - - - - - SMuFL version 1.18 uses the range U+E000 - U+ECBF. - - - - - - Indicates if a feature should be rendered when the notation is presented graphically - or sounded when it is presented in an aural form. - - - - - - - - Attributes that record written octave. - - - octave - Captures written octave information. - - - - - - - - Attributes that record a default value for octave. - - - Contains a default octave specification for use when the first note, rest, chord, etc. - in a measure does not have an octave value specified. - - - - - - - - Attributes describing the amount and direction of octave displacement. - - - Records the amount of octave displacement. - - - - - - Records the direction of octave displacement. - - - - - - - - Attributes that record placement of notes on a single-line staff. - - - Determines the placement of notes on a 1-line staff. A value of true places all - notes on the line, while a value of false places stems-up notes above the line and - stems-down notes below the line. - - - - - - - - Attributes pertaining to layout optimization. - - - Indicates whether staves without notes, rests, etc. should be displayed. When the - value is 'true', empty staves are displayed. - - - - - - - - Attributes that identify the layer associated with a distant feature. - - - identifies the layer on which referenced notation occurs. - - - - - - - - - - - - Attributes for identifying the staff associated with a distant feature. - - - signifies the staff on which referenced notation occurs. Defaults to the same value as - the local staff. Mandatory when applicable. - - - - - - - - - - - - Attributes recording the identifiers of the first and last elements of a sequence of - distant elements. - - - indicates the first element in a sequence of events. - - - - - - indicates the final element in a sequence of events. - - - - - - - - Attributes that identify a musical range in terms of musical time. - - - encodes the starting point of musical material in terms of musical time, i.e., a - (potentially negative) count of measures plus a beat location. - - - - - - encodes the ending point of musical material in terms of musical time, i.e., a count - of measures plus a beat location. The values are relative to the measure identified by - origin.tstamp. - - - - - - - When @origin.tstamp2 is used @origin.tstamp must - also be present. - - - - - - - - Logical domain attributes. - - - - - - - - - - Logical domain attributes. - - - - - - - Attributes that record page-level layout information. - - - Specifies the height of the page; may be expressed in real-world units or staff - steps. - - - - - - Describes the width of the page; may be expressed in real-world units or staff - steps. - - - - - - page top margin - Indicates the amount of whitespace at the top of a page. - - - - - - page bottom margin - Indicates the amount of whitespace at the bottom of a page. - - - - - - page left margin - Indicates the amount of whitespace at the left side of a page. - - - - - - page right margin - Indicates the amount of whitespace at the right side of a page. - - - - - - Indicates the number of logical pages to be rendered on a single physical page. - - - - - - Indicates how the page should be scaled when rendered. - - - - - - - - Logical domain attributes. - - - Attributes for identifying the part in which the current feature appears. - - - Indicates the part in which the current feature should appear. Use '%all' when the - feature should occur in every part. - - - (%all|#[\i][\c]+) - - - - - - '%all' cannot be mixed with other - values. - - - - - - Signifies the part staff on which a notated feature occurs. Use '%all' when the - feature should occur on every staff. - - - (%all|\d+(-\d+)?) - - - - - - '%all' cannot be mixed with other - values. - - - - - - - - Logical domain attributes. - - - Logical domain attributes. - - - - - - Logical domain attributes. - - - - - - - - - Attributes that record written pitch name. - - - pitch name - Contains a written pitch name. - - - - - - - - Attributes that record written pitch name and octave number. - - - - - - - Attributes capturing placement on a staff. - - - Indicates the placement of the item within the staff. A value of true means on the staff, and false off the staff. - - - - - - - - Attributes capturing placement information with respect to an event. - - - Captures the placement of the item with respect to the event with which it is - associated. - - - - - - - - Attributes capturing placement information with respect to the staff. - - - Captures the placement of the item with respect to the staff with which it is - associated. - - - - - - - - Attributes listing the active participants in a user-defined collection. - - - When the target attribute is present, plist identifies the active participants; that - is, those entities pointed "from", in a relationship with the specified target(s). When - the target attribute is not present, it identifies participants in a mutual - relationship. - - - - - - - @plist attribute - should have content. - Each - value in @plist should correspond to the @xml:id attribute of an - element. - - - - - - - - Attributes common to all pointing/linking elements. - - - - Defines whether a link occurs automatically or must be requested by the user. - - - Load the target resource(s) immediately. - - - Load the target resource(s) upon user request. - - - Do not permit loading of the target resource(s). - - - Behavior other than allowed by the other values of this attribute. - - - - - - Characterization of the relationship between resources. The value of the role - attribute must be a URI. - - - - - - - Defines how a remote resource is rendered. - - - Open in a new window. - - - Load the referenced resource in the same window. - - - Embed the referenced resource at the point of the link. - - - Do not permit traversal to the referenced resource. - - - Behavior other than permitted by the other values of this attribute. - - - - - Identifies passive participants in a relationship; that is, the entities pointed - "to". - - - - - - Characterization of target resource(s) using any convenient classification scheme or - typology. - - - - - - - - - - - Attributes that specify a measurement in numerical terms. - - - - - - - Numeric value capturing a measurement or count. Can only be interpreted in combination - with the unit attribute. - - - 0 - - - - - - - Groups attributes that describe a numerical range. - - - Gives a minimum estimated value for an approximate measurement. - - - - - - Gives a maximum estimated value for an approximate measurement. - - - - - - Where the measurement summarizes more than one observation or a range of values, - supplies the minimum value observed. - - - - - - Where the measurement summarizes more than one observation or a range of values, - supplies the maximum value observed. - - - - - - Specifies the degree of statistical confidence (between zero and one) that a value - falls within the range specified by min and max, or the proportion of observed values that - fall within that range. - - - - - - - The attributes @min and @max are required when - @confidence is present. - - - - - - - - Logical domain attributes. - - - - - - - - - Indicates the function of the mark, usually implying a corresponding form. - - - Coda (SMuFL E048 or Unicode 1D10C). - - - Segno (SMuFL E047 or Unicode 1D10B). - - - Dal segno (SMuFL E045 or Unicode 1D109). - - - Da capo (SMuFL E046 or Unicode 1D10A). - - - Fine. (text) - - - - - - - Attributes capturing information regarding responsibility for some aspect of the text's - creation, transcription, editing, or encoding. - - - Indicates the agent(s) responsible for some aspect of the text’s transcription, - editing, or encoding. Its value must point to one or more identifiers declared in the - document header. - - - - - - - @resp attribute should - have content. - The value in @resp should correspond to the @xml:id attribute of an element within - the metadata header. - - - - - - - - Logical domain attributes. - - - - - - - - - - Attributes that express duration of rests in musical terms. - - - Records the duration of a rest using the relative durational values provided by the - data.DURATIONRESTS datatype. - - - - - - - - Logical domain attributes. - - - - - - Attributes that describe relative size. - - - Scale factor to be applied to the feature to make it the desired display size. - - - - - - - - Logical domain attributes. - - - Logical domain attributes for scoreDef in the CMN repertoire. The values set in these - attributes act as score-wide defaults for attributes that are not set in descendant - elements. - - - - - - - - - - - - - Logical domain attributes. - - - - - - Attributes that describe order within a collection of features. - - - Used to assign a sequence number related to the order in which the encoded features - carrying this attribute are believed to have occurred. - - - - - - - - Attributes for recording the number of slashes that accompany a feature. - - - Indicates the number of slashes present. - - - - - - - - Attributes for marking the presence of a slur. - - - Indicates that this element participates in a slur. If visual information about the - slur needs to be recorded, then a slur element should be - employed. - - - - - - - - Attributes common to elements that may refer to a source. - - - Contains a list of one or more pointers indicating the sources which attest to a given - reading. Each value should correspond to the ID of a source or manifestationelement located in the document header. - - - - - - - @source attribute - should have content. - Each value in @source should correspond to the @xml:id attribute of a source or - manifestation element. - - - - - - - - Logical domain attributes. - - - - - - - - - Attributes that capture notation spacing information. - - - Describes a note’s spacing relative to its time value. - - - - - - Describes the note spacing of output. - - - - - - Specifies the minimum amount of space between adjacent staves in the same system; - measured from the bottom line of the staff above to the top line of the staff - below. - - - - - - Describes the space between adjacent systems; a pair of space-separated values - (minimum and maximum, respectively) provides a range between which a rendering - system-supplied value may fall, while a single value indicates a fixed amount of space; - that is, the minimum and maximum values are equal. - - - - - - - - Logical domain attributes. - - - - - - Provides a mechanism for linking the staff to a staffDef element. - - - - - - - @def attribute should - have content. - The value in @def should correspond to the @xml:id attribute of a staffDef - element. - - - - - - - - Logical domain attributes for staffDef. - - - - - - - - - - - - - - Indicates the number of staff lines. - - - - - - - - Attributes that describe the symbol used to group a set of staves. - - - Specifies the symbol used to group a set of staves. - - - Curved symbol, i.e., {. - - - Square symbol, i.e., [, but with curved/angled top and bottom segments. - - - Square symbol, i.e., [, with horizontal top and bottom segments. - - - Line symbol, i.e., |, (wide) line without top and bottom curved/horizontal - segments. - - - Grouping symbol missing. - - - - - - - Logical domain attributes. - - - Attributes for identifying the staff associated with the current feature. - - - Signifies the staff on which a notated event occurs or to which a control event - applies. Mandatory when applicable. - - - - - - - - Attributes that describe items printed near (above, below, or between) staves - - - Describes vertical order of items printed above a staff, from closest to farthest away - from the staff. - - - - - - Describes vertical order of items printed below a staff, from closest to farthest away - from the staff. - - - - - - Describes vertical order of items printed between staves, from top to bottom. - - - - - - - - Attributes that identify location on a staff in terms of lines and spaces. - - - Holds the staff location of the feature. - - - - - - - - Attributes that identify location on a staff in terms of pitch and octave. - - - Captures staff location in terms of written pitch name. - - - - - - Records staff location in terms of written octave. - - - - - - - - Attributes recording the identifiers of the first and last elements of a sequence of - elements to which the current element is associated. - - - - - - Indicates the final element in a sequence of events to which the feature - applies. - - - - - - - @endid attribute - should have content. - The - value in @endid should correspond to the @xml:id attribute of an - element. - - - - - - - - Attributes that identify a relative starting point. - - - Holds a reference to the first element in a sequence of events to which the feature - applies. - - - - - - - @startid attribute - should have content. - The - value in @startid should correspond to the @xml:id attribute of an - element. - - - - - - - - Attributes that describe the properties of stemmed features; that is, chords and - notes. - - - - - - - Describes the direction of a stem. - - - - - - Encodes the stem length. - - - - - - Encodes any stem "modifiers"; that is, symbols rendered on the stem, such as tremolo - or Sprechstimme indicators. - - - - - - Records the position of the stem in relation to the note head(s). - - - - - - Points to a note element in a different layer whose stem is shared. - The linked notes should be rendered like a chord though they are part of different layers. - - - - - - - - - - @stem.sameas attribute - should have content. - - The value in @stem.sameas should correspond to the @xml:id attribute of the linked note - element of a different layer. - - The linked notes by @stem.sameas should have the same @dur values. - - - - - - - Determines whether a stem should be displayed. - - - - - - Records the output x coordinate of the stem’s attachment point. - - - - - - Records the output y coordinate of the stem’s attachment point. - - - - - - - - Logical domain attributes. - - - Describes the symbols typically used to indicate breaks between syllables and their - functions. - - - Space (word separator). - - - Dash (syllable separator). - - - Underscore (syllable extension). - - - Tilde (syllable elision). - - - Circumflex [angled line above] (syllable elision). - - - Caron [angled line below] (syllable elision). - - - Inverted breve [curved line above] (syllable elision). - - - Breve [curved line below] (syllable elision). - - - - - Records the position of a syllable within a word. - - - (initial) first syllable. - - - (medial) neither first nor last syllable. - - - (single) single syllable. - - - (terminal) last syllable. - - - - - - - Attributes that hold associated sung text syllables. - - - Holds an associated sung text syllable. - - - - - - - - Logical domain attributes. - - - - - - Attributes that capture system layout information. - - - Indicates whether the system starts with a continuous line connecting all staves, - including single-staff systems. Do not confuse this with the heavy vertical line used as a grouping - symbol. - - - - - - Describes the amount of whitespace at the left system margin relative to - page.leftmar. - - - - - - Describes the amount of whitespace at the right system margin relative to - page.rightmar. - - - - - - Describes the distance from page’s top edge to the first system; used for first page - only. - - - - - - - - Attributes that deal with resolution of values in plist or target attributes. - - - Specifies the intended meaning when a participant in a relationship is itself a - pointer. - - - If an element pointed to is itself a pointer, then the target of that pointer will - be taken, and so on, until an element is found which is not a pointer. - - - If an element pointed to is itself a pointer, then its target (whether a pointer - or not) is taken as the target of this pointer. - - - No further evaluation of targets is carried out beyond that needed to find the - element(s) specified in plist or target attribute. - - - -

If no value is given, the application program is responsible for deciding (possibly on - the basis of user input) how far to trace a chain of pointers.

- - - - - - Logical domain attributes. - - - - - - - - - Records the function of a tempo indication. - - - Marks a gradual change of tempo, such as "accel." or "rit." - - - Represents a static tempo instruction, such as a textual term like "Adagio", a - metronome marking like "♩=70", or a combination of text and metronome - indication. - - - Captures a change in pulse rate (tempo) and/or pulse grouping (subdivision) in an - "equation" of the form [tempo before change] = [tempo after change]. - - - Indicates a change in pulse rate (tempo) and/or pulse grouping (subdivision) in an - "equation" of the form [tempo after change] = [tempo before change]. The term - "precedente" often appears following the "equation" to distinguish this kind of - historical usage from the modern metric modulation form. - - - - - - - Attributes that record renditional characteristics. - - - Used to extend the values of the rend attribute. - - - - - - rendition - Captures the appearance of the element’s contents using MEI-defined - descriptors. - - - - - - - - Attributes that describe default text typography. - - - Provides a default value for the font family name of text (other than lyrics) when - this information is not provided on the individual elements. - - - - - - Provides a default value for the font name of text (other than lyrics) when this - information is not provided on the individual elements. - - - - - - Provides a default value for the font size of text (other than lyrics) when this - information is not provided on the individual elements. - - - - - - Provides a default value for the font style of text (other than lyrics) when this - information is not provided on the individual elements. - - - - - - Provides a default value for the font weight for text (other than lyrics) when this - information is not provided on the individual elements. - - - - - - - - Attributes that indicate the presence of a tie. - - - Indicates that this element participates in a tie. If visual information about the tie - needs to be recorded, then a tie element should be employed. - - - - - - - - Attributes that record a time stamp in terms of musical time, i.e., beats[.fractional beat - part]. - - - time stamp - Encodes the onset time in terms of musical time, i.e., beats[.fractional beat part], - as expressed in the written time signature. - - - - - - - - Attributes that record a time stamp for the end of an event in terms of musical - time. - - - Encodes the ending point of an event, i.e., a count of measures plus a beat location - in the ending measure. - - - - - - - - Attributes that describe transposition. - - - transposition (diatonic) - Records the amount of diatonic pitch shift, e.g., C to C♯ = 0, C to D♭ = 1, necessary - to calculate the sounded pitch from the written one. - - - - - - transposition (semitones) - Records the amount of pitch shift in semitones, e.g., C to C♯ = 1, C to D♭ = 1, - necessary to calculate the sounded pitch from the written one. - - - - - - -

Diatonic transposition requires both trans.diat and trans.semi - attributes in order to distinguish the difference, for example, between a transposition from - C to C♯ and one from C to D♭.

- - - - Attributes that describe tuning. - - - Holds a value for cycles per second, i.e., Hertz, for a tuning reference pitch. - - - - - - Holds the pitch name of a tuning reference pitch, i.e., the central tone of a tuning system. - - - - - - Provides an indication of the tuning system, just, for example. - - - - - - - - Attributes for indicating the presence of a tuplet. - - - Indicates that this feature participates in a tuplet. If visual information about the - tuplet needs to be recorded, then a tuplet element should be - employed. - - - - - - - - Attributes which can be used to classify features. - - - - - - Designation which characterizes the element in some sense, using any convenient - classification scheme or typology that employs single-token labels. - - - - - - -

When appropriate, values from an established typology should be used.

- - - - Typographical attributes. - - - Contains the name of a font-family. - - - - - - Holds the name of a font. - - - - - - Indicates the size of a font expressed in printers' points, i.e., 1/72nd of an inch, - relative terms, e.g., small, larger, etc., or percentage values relative to normal - size, e.g., 125%. - - - - - - Records the style of a font, i.e., italic, oblique, or normal. - - - - - - Used to indicate bold type. - - - - - - Indicates letter spacing (aka tracking) in analogy to the CSS letter-spacing - property. - - - - - - Indicates line height in analogy to the CSS line-height property. - - - - - - - - - - - Attributes that record vertical alignment. - - - Records vertical alignment. - - - - - - - - Attributes that record grouping of vertically aligned elements. - - - Provides a label for members of a vertically aligned group. - - - - - - - - Attributes describing whether a feature should be displayed. - - - Indicates if a feature should be rendered when the notation is presented graphically - or sounded when it is presented in an aural form. - - - - - - - - Visual offset attributes. Some items may have their location recorded in terms of offsets - from their programmatically-determined location. The ho attribute records the horizontal - offset while vo records the vertical. The to attribute holds a timestamp offset, the most - common use of which is as an alternative to the ho attribute. - - - - - - - - Horizontal offset attributes. - - - Records a horizontal adjustment to a feature’s programmatically-determined location in - terms of staff interline distance; that is, in units of 1/2 the distance between adjacent - staff lines. - - - - - - - - Horizontal offset attributes specified in terms of time. - - - Records a timestamp adjustment of a feature’s programmatically-determined location in - terms of musical time; that is, beats. - - - - - - - - Vertical offset attributes. - - - Records the vertical adjustment of a feature’s programmatically-determined location in - terms of staff interline distance; that is, in units of 1/2 the distance between adjacent - staff lines. - - - - - - - - Visual offset attributes. Some items may have their location recorded in terms of pairs of - offsets from their programmatically-determined location. The startho and endho attributes - record the horizontal offsets of the start and end points of the item, respectively. - Similarly, the startvo and endvo attributes record the vertical offsets of the start and end - points of the item. The startto and endto attributes hold timestamp offsets, the most common - use of which is as alternatives to the ho attributes. - - - - - - - - Horizontal offset requiring a pair of attributes. - - - Records the horizontal adjustment of a feature’s programmatically-determined start - point. - - - - - - Records the horizontal adjustment of a feature’s programmatically-determined end - point. - - - - - - - - Horizontal offset attributes requiring a pair of attributes specified in terms of - time. - - - Records a timestamp adjustment of a feature’s programmatically-determined start - point. - - - - - - Records a timestamp adjustment of a feature’s programmatically-determined end - point. - - - - - - - - Vertical offset attributes requiring a pair of attributes. - - - Records a vertical adjustment of a feature’s programmatically-determined start - point. - - - - - - Records a vertical adjustment of a feature’s programmatically-determined end - point. - - - - - - - - Attributes that describe the symbol used to group volta elements. - - - Specifies the symbol used to group lyrics. - - - Curved symbol, i.e., {. - - - Square symbol, i.e., [, but with curved/angled top and bottom segments. - - - Square symbol, i.e., [, with horizontal top and bottom segments. - - - Line symbol, i.e., |, (wide) line without top and bottom curved/horizontal - segments. - - - Grouping symbol missing. - - - - - - - Attributes that address whitespace processing. - - - - Allows one to signal to an application whether an element’s white space is - "significant". The behavior of xml:space cascades to all descendant elements, but it can - be turned off locally by setting the xml:space attribute to the value default. - - - Allows the application to handle white space as necessary. Not including an - xml:space attribute produces the same result as using the default value. - - - Instructs the application to maintain white space "as-is", suggesting that it - might have meaning. - - - - - - - Attributes that describe horizontal size. - - - Measurement of the horizontal dimension of an entity. - - - - - - -

The width attribute may be used to capture measure width data for interchange with music - printing systems that utilize this information for printing. On barLine the width - attribute captures the width of the preceding measure.

- - - - Output coordinate attributes. Some elements may have their exact rendered *output* - coordinates recorded. x and y attributes indicate where to place the rendered output. - Recording the coordinates of a feature in a facsimile requires the use of the facs - attribute. - - - Encodes an x coordinate for a feature in an output coordinate system. When it is - necessary to record the placement of a feature in a facsimile image, use the facs - attribute. - - - - - - Encodes a y coordinate for a feature in an output coordinate system. When it is - necessary to record the placement of a feature in a facsimile image, use the facs - attribute. - - - - - - - - Output coordinate attributes. Some elements may need 2 coordinate pairs to record their - rendered *output* coordinates. The attributes indicate where to place the rendered output. - Recording the coordinates of a feature in a facsimile requires the use of the facs - attribute. - - - Encodes the optional 2nd x coordinate. - - - - - - Encodes the optional 2nd y coordinate. - - - - - - - - Groups elements used to represent a postal address. - - - - - - - - Groups annotation-like elements. - - - - - - Groups elements containing a bibliographic description. - - - - - - Groups elements that may appear as part of a bibliographic description. - - - Groups elements that contain the text of a caption or other text displayed along with a - figure. - - - Groups elements that may appear as part of the content of a chord element. - - - Groups elements, such as dynamics, ties, phrase marks, pedal marks, etc., which depend - upon other events, such as notes or rests, for their existence. - - - - - - - - - - Groups elements containing date expressions. - - - - - - - - - Groups elements which provide a description of their parent entity. - - - Groups elements which describe a measurement forming part of the physical dimensions of an - object. - - - - - - Groups elements containing bibliographic edition information. - - - - - - - Groups editorial intervention elements. - - - - - - - Groups elements that represent alternative endings. - - - - - - - Groups event elements that occur in all notational repertoires. - - - - - - Groups elements used to provide a heading at the start of a text division or other markup - component. - - - Groups identifier-like elements. - - - - - - - - Groups elements that may appear as part of a bibliographic imprint. - - - Groups elements used to represent a textual or musical incipit. - - - - - - - Groups elements used to declare a MIDI instrument. - - - Groups elements that represent accidentals in a key signature. - - - Groups elements that have the same function as a key signature. - - - - - - - Groups elements used to assign a label to other parts of a document. - - - Groups elements that permit declaration of layer properties. - - - Groups elements that function as notational layers within a staff. - - - - - - - - Groups notated events that may appear at the layer level in all repertoires. - - - Groups notated events at the layer level that are shared by the mensural and neume - repertoires. - - - - - - Groups elements that function like line beginnings. - - - - - - - Groups elements used to represent generic structural divisions of music notation. - - - Groups elements that represent a measurement. - - - - - - Groups elements that represent a meter signature. - - - - - - - Groups milestone-style elements found in music notation. - - - Groups milestone-style elements found in text. - - - Groups elements that contain names. - - - - - - Groups elements that modify note-like features. - - - - - - Groups elements that denote a number or a quantity. - - - - - - Groups elements which may appear as part of the paragraph content model. A paragraph may - contain inline elements and all other block-level elements except itself. - - - Groups elements that represent a separate performer part. - - - Groups elements that collect separate performer parts. - - - Groups page beginning-like elements. - - - - - - - - Groups paragraph-like elements. - - - - - - Collects elements that express a relationship. - - - - - - Groups elements that mark typographical features. - - - - - - Groups elements that denote a corporate entity that holds a bibliographic item. - - - - - - Groups non-text components that represent the content of the musical text. - - - Groups elements that are used to indicate intellectual or other significant - responsibility, for example within a bibliographic citation. - - - - - - Groups elements that delineate particular responsibilities as opposed to the respStmt - element that provides for generic statements of responsibility. - - - - - - - Groups elements that provide score meta-information. - - - - - - Groups elements that represent a score. - - - Groups elements that may appear as part of a score. - - - - Groups elements that represent a segment of music notation. - - - - - - - Groups elements that may appear as part of a section. - - - Groups elements that may appear as part of a section in the mensural and neume - repertoires. - - - - - - Groups elements that permit declaration of staff properties. - - - - - - Groups elements that may appear in the declaration of staff features. - - - Groups elements that permit declaration of staff group properties. - - - Groups elements that function like staves. - - - - - - - Groups elements that are components of a staff. - - - Groups elements that are components of a staff in the mensural and neume - repertoires. - - - - - - Groups elements that contain a lyric syllable. - - - - - - - - Groups block-level text elements. - - - - - - - Groups textual elements that occur at the level of individual words or phrases. - - - - - - Groups textual elements that occur at the level of individual words or phrases. This class - is equivalent to the model.textPhraseLike class without the pb element. - - - - - - - - Groups elements that denote the name of a bibliographic item. - - - - - - - Groups elements that may appear as part of a title page transcription. - - - accidental - Records a temporary alteration to the pitch of a note. - - - - - - - - - - - - - - -

An accidental may raise a pitch by one or two semitones or it may cancel a previous - accidental or part of a key signature. This element provides an alternative to the - accid and accid.ges attributes on the note - element. The element may be used when specific display info, such as size or color, needs to - be recorded for the accidental or when multiple accidentals occur on a single note. The - func attribute can be used to differentiate between the accidental’s functions, - such as 'cautionary' or 'editorial'.

- - - - Name of an actor appearing within a cast list. - - - - - - - - - - - - - - -

The model of this element is based on the actor element of the Text Encoding Initiative (TEI).

- - - - Contains a postal address, for example of a publisher, an organization, or an - individual. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the address element of the Text Encoding Initiative (TEI) and the address element of the Encoded - Archival Description (EAD).

- - - - address line - Single line of a postal address. - - - - - - - - - - - - - - - - -

addrLine may be repeated as many times as necessary to enter all - lines of an address.

- - -

The model of this element is based on the addrLine element of the Text Encoding Initiative (TEI) and the addressline element of the Encoded - Archival Description (EAD).

- - - - Range of a voice, instrument or piece. - - - - - - - - - - - - - - - - Highest or lowest pitch in a score, staff, or layer. - - - - - - - - - - - - - - analytic level - Contains bibliographic elements describing an item (e.g., an article or - poem) published within a monograph or journal and not as an independent publication. - - - - - - - - - - - - - - - - - - - - - - - - - - - annotation - Provides a statement explaining the text or indicating the basis for an - assertion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The @data attribute may only occur on an - annotation within the notesStmt element. - - - - -

The annot element can be used for both general comments and for - annotations of the musical text. It provides a way to group participating *events* and/or - *control events*, for example, the notes that form a descending bass line, and provide a - label for and comment regarding the group. Participating entities may be identified in the - plist attribute. An editorial or analytical comment or observation may be - included directly within the annot element. The starting point of the - annotation may be indicated by either a tstamp, tstamp.ges, - tstamp.real or startid attribute, while the ending point may be - recorded by either a dur, dur.ges or endid attribute. The - resp attribute records the editor(s) responsible for identifying or creating the - annotation.

- - - - A person or organization who transcribes a musical composition, usually for a different - medium from that of the original; in an arrangement the musical substance remains essentially - unchanged. - - - - - - - - - - - - - - - - - - - articulation - An indication of how to play a note or chord. - - - - - - - - - - - - - - -

Articulations typically affect duration, such as staccato marks, or the force of attack, - such as accents. This element provides an alternative to the artic attribute on - the note and chord elements. It may be used when - specific display info, such as size or color, needs to be recorded for the articulation or - when multiple articulation marks occur on a single note or chord.

- - - - The name of the creator of the intellectual content of a non-musical, literary - work. - - - - - - - - - - - - - - - - - -

The model of this element is based on the author element of the Text Encoding Initiative (TEI) and the author element of the Encoded - Archival Description (EAD).

- - - - Vertical line drawn through one or more staves that divides musical notation into metrical - units. - - - - - - - - - - - - - - - -

This element is provided for repertoires, such as mensural notation, that lack measures. - Because the barLine element’s attributes, from which the logical and - visual characteristics of the bar line can be discerned, largely duplicate those of measure, - the use of barLine is not necessary within measure elements in - CMN.

- - - - bibliographic reference - Provides a loosely-structured bibliographic citation in which - the sub-components may or may not be explicitly marked. - - - - - - - - - - - - - - - - - - - - - -

bibl may contain a mix of text and more specific elements such as - title, edition, persName, - and corpName. This element may also function as a hypertext reference - to an external electronic resource. Do not confuse this element with ref, which does not provide special bibliographic sub-elements.

- - -

The model of this element is based on the bibl element of the Text Encoding Initiative (TEI) and the bibref element of the Encoded - Archival Description (EAD).

- - - - List of bibliographic references. - - - - - - - - - - - - - - - - - - - - - - - - - - - When labels are used, - usually each bibliographic item has one. - - - - -

The model of this element is based on the listBibl element of the Text Encoding Initiative (TEI).

- - - - scope of citation - Defines the scope of a bibliographic reference, for example as a - list of page numbers, or a named subdivision of a larger work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Use the from and to attributes to regularize the beginning and ending - values provided in the element content.

-

The model of this element is based on the biblScope element of the Text Encoding Initiative (TEI).

- - - - structured bibliographic citation - Contains a bibliographic citation in which - bibliographic sub-elements must appear in a specified order. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Contains the whole of a single musical text, excluding any front or back matter. - - - - - - - - - - - - - - -

When the music can be broken into high-level, discrete, linear segments, such as movements - of a symphony, there may be multiple mdiv elements within body. This is the highest level indication of the structure of the - music.

-

The content model of body also allows blocks of text and music - notation to be interleaved. This permits the encoding of a wide range of musical documents, - including those that are primarily textual with only occasional musical material or even - those which completely lack music notation.

- - - - Break, pause, or interruption in the normal tempo of a composition. Typically indicated by - "railroad tracks", i.e., two diagonal slashes. - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

The caesura often indicates an abrupt interruption in the performance followed by an - equally sudden resumption. Its duration is typically shorter than a grand pause (G.P.) or - long pause (L.P.), but longer than that indicated by a breath mark. - When combined with a fermata a longer silence is usually implied. The - starting point of the caesura may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute. It is a - semantic error not to specify a starting point attribute.

-

Unlike the breath mark, a caesura may have a performed duration. - Also, while the default value for place on the breath mark is above, the - default value for place for a caesura is within. Unless indicated by other - attributes, a caesura will be rendered as a pair of slanted lines through the top line of - the staff.

-

- - - - A label which accompanies an illustration or a table. - - - - - - - - - - - - - - - - - - - cast group - Groups one or more individual castItem elements within a cast list. - - - - - - - - - - - - - - - -

The model of this element is based on the castGroup element of the Text Encoding Initiative (TEI).

- - - - Contains a single entry within a cast list, describing either a single role or a list of - non-speaking roles. - - - - - - - - - - - - - - - - - - -

The model of this element is based on the castItem element of the Text Encoding Initiative (TEI).

- - - - Contains a single cast list or dramatis personae. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the castList element of the Text Encoding Initiative (TEI).

- - - - column beginning - An empty formatting element that forces text to begin in a new - column. - - - - - - - - - - - - - - - - - Records the column number. - - - - - - - - Column beginning must be preceded by a - colLayout element. - The value of @n should be less than or equal - to the value of @cols () of the preceding - colLayout element. - - - - - - -

The model of this element is based on the cb element of the Text Encoding Initiative (TEI).

- - - - A simultaneous sounding of two or more notes in the same layer *with the same - duration*. - - - - - - - - - - - - - - - - - - - - - - - - Indication of the exact location of a particular note on the staff and, therefore, the - other notes as well. - - - - - - - - - - - - - - - - - - - - The clef position must be less than or equal to the number of lines of an ancestor - staff. - - - - - - - - The clef position must be less than or equal to the number of lines of a preceding - staff. - - - - -

This element can be used as an alternative to the staff element's - clef.* attributes. It should be used when specific display info, such as size or color, - needs to be recorded for the clef or when multiple, simultaneous clefs occur on a single - staff. This element may also be used within the staff context to indicate changes of - clef.

- - - - clef group - A set of simultaneously-occurring clefs. - - - - - - - - - - - - - - - - - - - column layout - An empty formatting element that signals the start of columnar - layout. - - - - - - - - - - - - Records the number of columns. - - - - - - - - The name of the creator of the intellectual content of a musical work. - - - - - - - - - - - - - - - - - - - Names of individuals, institutions, or organizations responsible for contributions to the - intellectual content of a work, where the specialized elements for authors, editors, etc. do - not suffice or do not apply. - - - - - - - - - - - - - - - - - - - - The value of @role must not contain the name of another element available in this - context. - - - - - - Used to specify the contributor’s function. - - - - -

When applicable, values from the MARC relator term list (http://www.loc.gov/marc/relators/relaterm.html) or code list (http://www.loc.gov/marc/relators/relacode.html) are recommended for - role.

- - - - - - Non-bibliographic details of the creation of an intellectual entity, in narrative form, - such as the date, place, and circumstances of its composition. More detailed information may - be captured within the history element. - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the creation element of the Text Encoding Initiative (TEI).

- - - - Symbol placed at the end of a line of music to indicate the first note of the next line. - Sometimes called a "direct". - - - - - - - - - - - - - - - - -

The most common visual form is a sign resembling a mordent. Other graphical forms may be - indicated by the altsym attribute. Together the pname and - oct attributes identify the location where the custos appears.

- - - - A string identifying a point in time or the time period between two such points. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the date element of the Text Encoding Initiative (TEI) and the date element of the Encoded - Archival Description (EAD).

- - - - Entity to whom a creative work is formally offered. - - - - - - - - - - - - - - - - - - - The dedicatee element may not be - recursively nested. - - - - - - Description of a measurement taken through a three-dimensional object. - - - - - - - - - - - - - - - - - - description - Container for text that briefly describes the feature to which it is - attached, including its intended usage, purpose, or application as appropriate. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the desc element of the Text Encoding Initiative (TEI).

- - - - dimension - Any single dimensional specification. - - - - - - - - - - - - - - - - - - Aspect of the object being measured. - - - - - - Altitude. Refers to the distance above a given level, commonly mean sea - level. - - - Angle. Amount of rotation needed to bring one line or plane into coincidence with - another. - - - Circumference of a circular area. - - - Dimension taken through an object or body of material, usually downward from an - upper surface, horizontally inward from an outer surface, or from top to bottom of - something regarded as one of several layers. - - - Length of a straight line passing through the center of a circle or sphere and - meeting the circumference or surface at each end. - - - Distance to which something has been raised or uplifted above a level, e.g., a - hill’s elevation above the surrounding country. - - - Denotes extent upward (as from foot to head) as well as any measurable distance - above a given level. - - - Measure of the greatest dimension of a plane or solid figure. - - - Half the diameter of a circular, spherical, or cylindrical object. - - - Projection of a figure or part from the plane on which it is formed. - - - Extent from side to side; breadth. - - - - - -

The height, width, and depth elements are preferred when appropriate.

- - - - Information about the physical size of an entity; usually includes numerical data. - - - - - - - - - - - - - - - - The depth element may only appear - once. - The height element may only appear - once. - The width element may only appear - once. - - - - -

The elements height, width, depth, and dim are available for circumstances that require the - capture of the individual dimensions of an object. Do not confuse this element with the extent element, which is used to indicate the quantity of described - materials.

- - -

The model of this element is based on the dimensions element of the Text Encoding Initiative (TEI) and the dimensions element of the Encoded - Archival Description (EAD).

- - - - directive - An instruction expressed as a combination of text and symbols, typically above, - below, or between staves, but not on the staff — that is not encoded elsewhere in more specific - elements, like tempo, dynam or repeatMark. - - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

Examples include text strings, such as 'affettuoso', and music symbols, such as segno and - coda symbols, fermatas over a bar line, etc. Directives can be control elements. That is, - they can be linked via their attributes to other events. The starting point of the directive - may be indicated by either a startid, tstamp, tstamp.ges, - or tstamp.real attribute, while the ending point may be recorded by either a - dur, dur.ges, endid, or tstamp2 attribute. It is - a semantic error not to specify a starting point attribute.

- - - - Person or agency, other than a publisher, from which access (including electronic access) - to a bibliographic entity may be obtained. - - - - - - - - - - - - - - - - - -

The model of this element is based on the distributor element of the Text Encoding Initiative (TEI).

- - - - division - Major structural division of text, such as a preface, chapter or - section. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Characterizes the textual division in some sense, using any convenient classification - scheme or typology that employs single-token labels. - - - - - - A summary of the content of a text as continuous prose. - - - A formal declaration of acknowledgment by the author in which persons and - institutions are thanked for their part in the creation of a text. - - - An ancillary self-contained section of a work, often providing additional but in - some sense extra-canonical text. - - - A list of bibliographic citations. - - - A statement appearing at the end of a book describing the conditions of its - physical production. - - - A table of contents, specifying the structure of a work and listing its - constituents. The list element should be used to mark its structure. - - - A formal offering or dedication of a text to one or more persons or institutions - by the author. - - - A pictorial frontispiece, possibly including some text. - - - A list of terms associated with definition texts (‘glosses’). - - - A page containing only the title of a book — as opposed to the title page, which - also lists subtitle, author, imprint and similar data. - - - Any form of index to the work. - - - A section in which annotations on the text are gathered together. - - - A foreword or preface addressed to the reader in which the author or publisher - explains the content, purpose, or origin of the text. - - - - - -

Often, the head sub-element identifies the div’s purpose. The model of this element is based on the div element of the Text Encoding Initiative - (TEI).

- - - - Dot of augmentation or division. - - - - - - - - - - - - - - -

This element provides an alternative to the dots attribute on note and rest elements. It should be used when specific display - info, such as size or color, needs to be recorded for the dot. This element may also be used - for dots of division in the mensural repertoire.

- - - - dynamic - Indication of the volume of a note, phrase, or section of music. - - - - - - - - - - - - - - - - - - - - - - - - Must have one of - the attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - - When @val2 is present, either - @dur, @dur.ges, @endid, or @tstamp2 must also be present. - - - - -

This element may be used for instantaneous or continuous textual dynamics, - e.g., 'p', 'mf', or 'cresc. poco a poco'. The hairpin element should be - used for graphical, i.e., crescendo and diminuendo, dynamic markings. The - starting point of the dynamic marking may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify a - starting point attribute. MIDI values associated with the graphical dynamic sign may be - recorded in the val and val2 attributes.

- - - - edition designation - A word or text phrase that indicates a difference in either - content or form between the item being described and a related item previously issued by the - same publisher/distributor (e.g., 2nd edition, version 2.0, etc.), or simultaneously issued by - either the same publisher/distributor or another publisher/distributor (e.g., large print - edition, British edition, etc.). - - - - - - - - - - - - - - - - - - -

The model of this element is based on the edition element of the Text Encoding Initiative (TEI) and the edition element of the Encoded - Archival Description (EAD).

- - - - The name of the individual(s), institution(s) or organization(s) acting in an editorial - capacity. - - - - - - - - - - - - - - - - - -

The model of this element is based on the editor element of the Text Encoding Initiative (TEI).

- - - - Alternative ending for a repeated passage of music; i.e., prima volta, seconda volta, - etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The scoreDef element is allowed as a sub-element so that an ending - may have its own meta-data without the overhead of child section - elements. div sub-elements are not allowed within ending. They may, - however, be contained by the children of ending, e.g., measures. Endings may not contain - other ending elements.

- - - - Contains a free-text event description. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Contains historical information given as a sequence of significant past events. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

An eventList contains event elements that - capture a brief description of the associated event, including dates and locations where the - event took place. An eventList describes events associated with a work - when it appears in the workList element or events associated with the - custodial history of a given copy of a source for the encoding when it appears within the - sourceDesc or relatedItem elements. The - type attribute may be used to distinguish between event lists with different - functions, such as a list of events in the compositional process and a list of performance - dates.

- - - - Indicates how a section may be programmatically expanded into its 'through-composed' - form. - - - - - - - - - - -

The plist attribute contains an ordered list of identifiers of descendant section, ending, lem, or rdg elements. For example, the sequence "#A #End1 #A #End2" indicates that - the section labelled 'A' comes first, then the ending labelled 'End1', followed by the 'A' - section again, and finally the ending labelled 'End2'.

- - - - Used to express size in terms other than physical dimensions, such as number of pages, - records, bytes, physical components, etc. - - - - - - - - - - - - - - - - - - -

Use the dimensions element when it is necessary to specify the physical size of materials being described, for example, height and - width.

- - -

The model of this element is based on the extent element of the Text Encoding Initiative (TEI).

- - - - extended data - Provides a container element for non-MEI data formats. - - - - - - - - - - - - - - - - - - - - -

Container for holding non-MEI data formats, similar to extMeta but available in when rather than in meiHead. The content of this element, by virtue of being inside a when element, is associated with a particular point in time in a media file and this point in time may be linked to symbolic data, such as notes, chords, rests, etc., recorded elsewhere. When the data in extData contains left angle bracket (less-than) or ampersand characters, or when it contains white space that should be preserved (such as line breaks), then the data should be enclosed in a CDATA section (e.g., for JSON formatted data).

- - - - Names of individuals, institutions, or organizations responsible for funding. Funders - provide financial support for a project; they are distinct from sponsors, who provide - intellectual support and authority. - - - - - - - - - - - - - - - - - -

The model of this element is based on the funder element of the Text Encoding Initiative (TEI).

- - - - Term or terms that designate a category characterizing a particular style, form, or - content. - - - - - - - - - - - - - - - - - - - Contains a composite musical text, grouping together a sequence of distinct musical texts - (or groups of such musical texts) which are regarded as a unit for some purpose, for example, - the collected works of a composer. - - - - - - - - - - - - - - - - - - -

Because its model contains the music element, each of the subordinate MEI documents can - have its own front and back matter.

- - -

The model of this element is based on the group element of the Text Encoding Initiative (TEI).

- - - - group symbol - A brace or bracket used to group two or more staves of a score or - part. - - - - - - - - - - - - - - - - - In scoreDef, grpSym must have startid, - endid, and level attributes. - - - - - - - In staffGrp, grpSym must not have - startid, endid, or level attributes. - - - - -

This element provides an alternative to the staffGrp element's - symbol attribute. It may be used when exact placement or editorial details for - the grouping symbol must be recorded.

- - - - heading - Contains any heading, for example, the title of a section of text, or the - heading of a list. - - - - - - - - - - - - - - - - - - -

One or more head elements usually identify the parent element and/or - its purpose.

- - -

The model of this element is based on the head element of the Encoded Archival Description (EAD), the head element of the Text Encoding - Initiative (TEI), and the head element of HTML.

- - - - Description of the vertical size of an object. - - - - - - - - - - - - - - - - - - An alpha-numeric string that establishes the identity of the described material. - - - - - - - - - - - - - - - - - - -

Examples include an International Standard Book/Music Number, Library of Congress Control - Number, publisher’s number, a personal identification number, an entry in a bibliography or - catalog, etc. The type attribute may be used to indicate the system from which - the identifier was derived.

- - - - Information relating to the publication or distribution of a bibliographic item. - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the imprint element of the Text Encoding Initiative (TEI).

- - - - incipit - The opening music and/or words of a musical or textual work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The incipText element may be used to capture a text incipit, while - score is available to provide an MEI-encoded musical incipit. Images - of an incipit may be referenced using the graphic element. An incipit - encoded in a text format other than MEI may be placed in the incipCode - element.

- - - - key accidental - Accidental in a key signature. - - - - - - - - - - - - - - - - One of the following is required: @x and - @y attribute pair, @pname attribute, or @loc attribute. - - - - - - Specifies whether enharmonic (written) values or implicit ("perform-able") values are - allowed. - - - Only performed values (sharp, flat, natural) allowed. - - - All enharmonic (written) values allowed. - - - - - -

It is a semantic error not to provide one of the following: the x and - y pair of attributes, the pname and oct pair of attributes, - or the loc attribute.

- - - - key signature - Written key signature. - - - - - - - - - - - - - - - - - - - - - If the @oct attribute - appears on any keyAccid element, it must be provided on all keyAccid - elements. - - - - - - - Only keyAccid elements are allowed - here. - - - - - - A container for document text that identifies the feature to which it is attached. For a - "tool tip" or other generated label, use the label attribute. - - - - - - - - - - - - - - - - - - -

The model of this element is based on the label element of the Text Encoding Initiative (TEI).

-

Don't confuse this element, which is used to capture labelling text appearing in the - document, with the label attribute, which records text to be used to generate a - designation for the element to which it’s attached, a "tool tip" or prefatory text, for - example.

- - - - A label on the pages following the first. - - - - - - - - - - - - - - - - - - - - An independent stream of events on a staff. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The term 'layer' is used instead of 'voice' in order to avoid confusion between 'voice' and - 'voice leading' and 'voicing'. The def attribute may be used to create a - connection with a layerDef element where logical and visual - information about the layer is recorded. Alternatively, the n attribute may be - used as a reference to a layerDef element with the same value in its - n attribute. If neither def nor n attributes are present, - then encoding order of the layers is presumed to match the encoding order of the layer - definitions.

- - - - layer definition - Container for layer meta-information. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - line beginning - An empty formatting element that forces text to begin on a new - line. - - - - - - - - - - -

The n attribute should be used to record a number associated with this textual - line. See comment on verse element for description of func - attribute. Do not confuse this element with the sb element, which - performs a similar function for musical notation.

- - -

The model of this element is based on the lb element of the Text Encoding Initiative (TEI).

- - - - line group - May be used for any section of text that is organized as a group of lines; - however, it is most often used for a group of verse lines functioning as a formal unit, e.g., a - stanza, refrain, verse paragraph, etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the lg element of the Text Encoding Initiative (TEI).

- - - - Person or organization who is a writer of the text of an opera, oratorio, etc. - - - - - - - - - - - - - - - - - - - Person or organization who is a writer of the text of a song. - - - - - - - - - - - - - - - - - - - musical division - Contains a subdivision of the body of a musical text. - - - - - - - - - - - - - - - - - - - - - - - - - - -

The mdiv element may contain one or both of 2 possible views of the - music. The score view is the traditional full and open score while the parts view contains - each performer’s view of the score; that is, his part. These 2 views are necessary because - it is not always possible or desirable to generate one from the other. The score and parts elements are placed here and not directly within - the body element because score and part characteristics may change - from mdiv to mdiv. For example, the 2nd movement - of a symphony may require different performing forces (and therefore different score and - part layout) than the other movements. The mdiv element may be - recursively nested in order to represent music which exhibits this kind of structure. For - example, an opera is normally divided into acts, which are in turn divided into scenes.

- - - - Contains a single MEI-conformant document, consisting of an MEI header and a musical text, - either in isolation or as part of an meiCorpus element. - - - - - - - - - - - - - The values in @staff must correspond to @n attribute of a staffDef - element. - - - - -

The mei element defines an instance of a document encoded with the - MEI schema. It is the document element for a single document containing a header and data. - The name of this element should not be changed by any customization in order to assure an - absolute minimum level of MEI compliance.

- - - - monograph level - Contains bibliographic elements describing an item, for example, a - published book or journal, score, recording, or an unpublished manuscript. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Contains a single musical text of any kind, whether unitary or composite, for example, an - etude, opera, song cycle, symphony, or anthology of piano solos. - - - - - - - - - - - - - - Proper noun or noun phrase. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Recommended practice is to use name elements to capture sub-parts of a generic - name. - - - - - - Characterizes the name in some sense, using any convenient classification scheme or - typology that employs single-token labels. - - - - - - A personal name. - - - Name of a corporate body. - - - Name of a location. - - - Name of a process or software application. - - - Name of a musical style; i.e., form, genre, technique, etc. - - - Name of a period of time. - - - - - -

Contains the name of an entity that is difficult to tag more specifically, for example, as - a corpName, geogName, persName, or title. The name element may - be used in place of the more specific elements when it is not known what kind of name is - being described or when a high degree of precision is not necessary. For example, the name element might be used when it is not clear whether the name "Bach" - refers to a person or a geographic feature. The name element may be - used for an individual, such as 'Henry VIII, King of England'; a corporate body, such as - 'The Beatles'; a geographical place; an expanse of time, such as 'The Romantic Era'; or a - mechanical (often generative) process. When name parts are needed, name sub-elements are recommended. The recommended values for the type - attribute are: person, corporation, location, period, and process. Dates associated with - the name (not necessarily the same as those pertaining to the entity - described by the name) may be recorded using startdate, - enddate, notbefore, notafter, and isodate - attributes. The name of the list from which a controlled value is taken, such as the - Thesaurus of Geographic Names (TGN) or Library of Congress Name Authority File (LCNAF), and - its electronically-available location may be recorded using the auth and - auth.uri attributes.

- - -

The model of this element is based on the name element of the Encoded Archival Description (EAD).

- - - - A single pitched event. - - - - - - - - - - - - - - - - - - - - - - - - - -

The accid and artic sub-elements may be used - instead of the note element’s attributes when accid and artic represent first-class objects, - e.g., when they require attributes, such as x and y location - attributes. Similarly, the syl sub-element may be used instead of the - syl attribute. The verse sub-element may be used to group text syllables by - verse. The colored attribute may be used to indicate coloration. In the mensural - repertoire, coloration is a temporary change in the underlying mensuration from perfect to - imperfect. In the CMN repertoire, coloration is an inversion of the note head’s normal - rendition, that is, the note head is void when it would otherwise be filled and vice versa. - Do not confuse this with visual color.

- - - - number - Numeric information in any form. - - - - - - - - - - - - - - - - - - - - - Numeric value capturing a measurement or count. Can only be interpreted in combination - with the unit attribute. - - - - - - -

Use this element only when it is necessary to display a number in a special way or to - identify it with a type attribute.

- - - - An element indicating an ornament that is not a mordent, turn, or trill. - - - - - - - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - -

If it is not textual, the glyph of the ornament may be indicated with the altsym - attribute, and it is recommended to provide an expansion of the ornament on the staff content. - The starting point of the ornament may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute. It is a semantic - error not to specify one of these attributes.

- - - - paragraph - One or more text phrases that form a logical prose passage. - - - - - - - - - - - - - - - - - -

A paragraph is usually typographically distinct: The text usually begins on a new line and - the first letter of the content is often indented, enlarged, or both.

- - -

The model of this element is based on the p element of the Encoded Archival Description, the p element of the Text Encoding - Initiative (TEI), and the p element of HTML.

- - - - padding - An indication of extra visual space between notational elements. - - - - - - - - - - - - - - An alternative visual rendition of the score from the point of view of a particular - performer (or group of performers). - - - - - - - - - - - - - - - - - - - - - - - - - - -

part elements are not used in MEI to indicate voice leading. - next attributes on event elements should be used for this purpose. part elements are useful for encoding individual parts when there is no - score, such as early music part books, when the music has non-aligning bar lines, when - different layout, such as page turns, are needed for the score and parts, or for - accommodating software that requires part-by-part encoding. When assembly of the parts into - a score is desired and there are non-aligning bar lines, bar lines which indicate points of - alignment across all the parts may be marked as 'controlling', while non-aligning ones may - be marked as 'non-controlling'.

- - - - Provides a container for performers' parts. - - - - - - - - - - - - - - - - - page beginning - An empty formatting element that forces text to begin on a new - page. - - - - - - - - - - - - - - - -

The n attribute should be used to record the page number displayed in the - source. It need not be an integer, e.g., 'iv', or 'p17-3'. The logical page number can be - calculated by counting previous pb ancestor elements. When used in a - score context, a page beginning implies an accompanying system beginning.

- - -

The model of this element is based on the pb element of the Text Encoding Initiative (TEI).

- - - - page description - Contains a brief prose description of the appearance or description - of the content of a physical page. - - - - - - - - - - - - - - - - - -

Best practice suggests the use of controlled vocabulary. Don't confuse this element with a - figure caption. A caption is text primarily intended for display with an illustration. It - may or may not function as a description of the illustration.

- - - - page footer - A running footer. - - - - - - - - - - - - - - - - - - - - - -

This element is used to capture the textual data that often appears in - printed music. It may also be used for similarly formatted material in manuscripts. When - used within pb, it records a temporary suspension of the pattern of - page footers established by the use of pgFoot within a previous scoreDef. Auto-generated page numbers may be indicated with a processing - instruction. The pgHead and pgFoot elements should *not* be used to encode textual notes/annotations.

- - - - page header - A running header. - - - - - - - - - - - - - - - - - - - - - -

This element is used to capture the textual data that often appears in - printed music. It may also be used for similarly formatted material in manuscripts. When - used within pb, it records a temporary suspension of the pattern of - page headers established by the use of pgHead within a previous scoreDef. Auto-generated page numbers may be indicated with a processing - instruction. The pgHead and pgFoot elements should *not* be used to encode textual notes/annotations.

- - - - Indication of 1) a "unified melodic idea" or 2) performance technique. - - - - - - - - - - - - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - Must have one of the attributes: - dur, dur.ges, endid, or tstamp2. - - - - - - - The visual attributes of the phrase (@bezier, @bulge, @curvedir, @lform, - @lwidth, @ho, @startho, @endho, @to, @startto, @endto, @vo, @startvo, @endvo, @x, @y, - @x2, and @y2) will be overridden by visual attributes of the contained curve - elements. - - - - -

Historically, the term "slur" indicated two notes performed legato, while the term "phrase" - was used for a "unified melodic idea". Nowadays, however, "slur" often has the same meaning - as "phrase" (See Read, p. 265-266), since the visual rendition of the two concepts is the - same. MEI provides two distinct elements so that those users wishing to maintain a - distinction for historical reasons may do so. If the user does not want to maintain the - distinction, then the more generic slur element should be employed. - The starting point of the phrase/slur may be indicated by either a startid, - tstamp, tstamp.ges, or tstamp.real attribute, while the - ending point may be recorded by either a dur, dur.ges, - endid, or tstamp2 attribute. It is a semantic error not to specify one - starting and one ending type of attribute. Either place, bulge, or - bezier attributes may be used to record the curvature of the phrase/slur. The slur and tie elements may be used instead of the - slur.* and tie.* attributes provided on chord and note elements when 1) they are required by software, or 2) multiple, alternative slurs - are needed.

- - - - physical location - Groups information about the current physical location of a - bibliographic item, such as the repository in which it is located and its shelf mark(s), and - its previous locations. - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the physloc element of the Encoded Archival Description (EAD).

- - - - Name of the organization responsible for the publication of a bibliographic item. - - - - - - - - - - - - - - - - - -

The model of this element is based on the publisher element of the Text Encoding Initiative (TEI).

- - - - publication place - Name of the place where a bibliographic item was published. - - - - - - - - - - - - - - - - - -

The model of this element is based on the pubPlace element of the Text Encoding Initiative (TEI).

- - - - The name of the individual(s), institution(s) or organization(s) receiving - correspondence. - - - - - - - - - - - - - - - - - - related item - Contains or references another bibliographic item which is related to the - present one. - - - - - - - - - - - - - - - - - - - - Describes the relationship between the entity identified by the relatedItem element and the resource described in the parent element, i.e., bibl, source or relatedItem. - - - - - - - - Describes a relationship or linkage amongst entities. - - - - - - - - - - - - - - - - - - - Within work, expression, source, or item, the value of the rel attribute must match one - of the following: hasAbridgement, isAbridgementOf, hasAdaptation, isAdaptationOf, - hasAlternate, isAlternateOf, hasArrangement, isArrangementOf, hasComplement, - isComplementOf, hasEmbodiment, isEmbodimentOf, hasExemplar, isExemplarOf, hasImitation, - isImitationOf, hasPart, isPartOf, hasRealization, isRealizationOf, hasReconfiguration, - isReconfigurationOf, hasReproduction, isReproductionOf, hasRevision, isRevisionOf, - hasSuccessor, isSuccessorOf, hasSummarization, isSummarizationOf, hasSupplement, - isSupplementOf, hasTransformation, isTransformationOf, hasTranslation, - isTranslationOf - Within work, expression, source or item, the target attribute - must be present. - - - - - - Describes the relationship between the entities identified by the plist and target - attributes. - - - - - - -

The plist and target attributes identify the participants in a - relationship, while the rel attribute describes the nature of their relationship. - A mutual relationship can be described using only the plist attribute – the - target attribute is not necessary. In a non-mutual relationship, plist - identifies the entities pointed "from", while target specifies the entities - pointed "to". If the target attribute is present, but the plist is - not, the relationship is presumed to exist between the parent of the current relation - element and the entities identified by target.

- - - - Gathers relation elements. - - - - - - - - - - - - - - - render - A formatting element indicating special visual rendering, e.g., bold or - italicized, of a text word or phrase. - - - - - - - - - - - - - - - - - - - - - - - - - A positive value for rotation rotates the text in a counter-clockwise fashion, while - negative values produce clockwise rotation. - - - - - - -

When an entire element should be rendered in a special way, a style sheet function should - be used instead of the rend element. The glyph.auth and glyph.uri - attributes may be used to specify an external authority, e.g., SMuFL, to be used for - displaying code points in the textual content of the element.

- - - - Institution, agency, or individual which holds a bibliographic item. - - - - - - - - - - - - - - - - - -

Sub-units of the holding institution may be marked with repository - sub-elements. The name of the list from which a controlled value is taken may be recorded - using the auth attribute.

- - -

The model of this element is based on the repository element of the Encoded Archival Description (EAD).

- - - - responsibility - A phrase describing the nature of intellectual responsibility. - - - - - - - - - - - - - - - - - -

The name of the list from which a controlled value is taken may be recorded using the - auth attribute.

- - -

The model of this element is based on the resp element of the Text Encoding Initiative (TEI).

- - - - responsibility statement - Transcription of text that names one or more individuals, - groups, or in rare cases, mechanical processes, responsible for creation, realization, - production, funding, or distribution of the intellectual or artistic content. - - - - - - - - - - - - - - - - - - - - - - - At least one element pair (a resp element and a name-like element) is - recommended. Alternatively, each name-like element may have a @role - attribute. - - - - -

The model of this element is based on the respStmt element of the Text Encoding Initiative (TEI).

- - - - A non-sounding event found in the source being transcribed. - - - - - - - - - - - - - - - - - - - - - - - - The value of @line must be less than or equal to the number of lines on the - staff. - - - - -

See (Read, p. 96-102). Do not confuse this element with the space - element, which is used as an aid for visual alignment.

- - - - Name of a dramatic role, as given in a cast list. - - - - - - - - - - - - - - -

The model of this element is based on the role element of the Text Encoding Initiative (TEI).

- - - - role description - Describes a character’s role in a drama. - - - - - - - - - - - - - - -

The model of this element is based on the roleDesc element of the Text Encoding Initiative (TEI).

- - - - system beginning - An empty formatting element that forces musical notation to begin on - a new line. - - - - - - - - - - - - - - -

Do not confuse this element with the lb element, which performs a - similar function in prose.

- - - - Full score view of the musical content. - - - - - - - - - - - - - - - - - - - - - - - - - - - -

A score may consist entirely of page beginnings, each of which points to a page - image. div elements are allowed preceding and following sections - of music data in order to accommodate blocks of explanatory text.

- - - - score definition - Container for score meta-information. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Segment of music data. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A - section containing an expansion element must have descendant section, ending, or rdg - elements. - - - - -

This element functions as a container for actual music data. Pointing attributes make it - possible to connect this element to other internal or external entities, such as media - objects or annotations.

- - - - Contains information about the serial publication in which a bibliographic item has - appeared. - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the series element of the Text Encoding Initiative (TEI).

- - - - A placeholder used to fill an incomplete measure, layer, etc. most often so that the - combined duration of the events equals the number of beats in the measure. - - - - - - - - - - - - - - - - Contains a specialized form of heading or label, giving the name of one or more speakers - in a dramatic text or fragment. - - - - - - - - - - - - - - - - -

The model of this element is based on the speaker element of the Text Encoding Initiative (TEI).

- - - - Names of sponsoring individuals, organizations or institutions. Sponsors give their - intellectual authority to a project; they are to be distinguished from funders, who provide - the funding but do not necessarily take intellectual responsibility. - - - - - - - - - - - - - - - - - -

The model of this element is based on the sponsor element of the Text Encoding Initiative (TEI) and the sponsor element of the Encoded - Archival Description (EAD).

- - - - stacked text - An inline table with a single column. - - - - - - - - - - - - - - - - - Indicates the delimiter used to mark the portions of text that are to be - stacked. - - - - - - Specifies how the stacked text components should be aligned. - - - Left justified. - - - Right justified. - - - Centered. - - - Aligned on right-most digit. - - - - - - - A group of equidistant horizontal lines on which notes are placed in order to represent - pitch or a grouping element for individual 'strands' of notes, rests, etc. that may or may not - actually be rendered on staff lines; that is, both diastematic and non-diastematic - signs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - There must be a preceding staffDef with a matching value of @n, a preceding staff with - a matching @n value containing a staffDef, or a staffDef child element. - - - - -

The def attribute may be used to create a connection with a staffDef element where logical and visual information about the staff is recorded. - Alternatively, the n attribute may be used as a reference to a staffDef element with the same value in its n attribute or the staff may - contain a staffDef element that defines it. If neither def nor n - attributes are present, then the encoding order of the staves is presumed to match the - encoding order of the staff definitions.

- - - - staff definition - Container for staff meta-information. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - StaffDef must have an n attribute. - Either - @lines must be present or a preceding staffDef with the same value for @n and @lines - must exist. - Only one clef or clefGrp is - permitted. - - - - - - - - @n must have the same value as the - current staff. - - - - - - - - Either - @lines must be present or a preceding staffDef with matching @n value and @lines must - exist. - - - - - - - The clef position must be less - than or equal to the number of lines on the staff. - - - - - - - - - The clef position must be - less than or equal to the number of lines on the staff. - - - - - - - - The tab.strings attribute must have the same - number of values as there are staff lines. - - - - - - - - - The - tab.strings attribute must have the same number of values as there are staff - lines. - - - - - - - - - The lines.color attribute - must have either 1) a single value or 2) the same number of values as there are staff - lines. - - - - - The lines.color attribute must have either 1) a single value or 2) the same number of - values as there are staff lines. - - - - - - - - - - - The value of ppq must be a factor of - the value of ppq on an ancestor scoreDef. - - - - - - - - - - - The value of ppq must be a factor of - the value of ppq on a preceding scoreDef. - - - - - - - staff group - A group of bracketed or braced staves. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Each staffDef must have a unique value - for the n attribute. - - - - -

System is the more proper name for this concept (Read, p. 37-38). Bracketed staff groups - may contain other bracketed or braced staff groups or single staves. See Read, p. 35-38, - examples p. 434, 438.

- - - - syllable - Individual lyric syllable. - - - - - - - - - - - - - - - - - - - - - - -

Do not confuse this element with the syllable element, which is used - to organize neume notation.

- - - - A reference to a previously defined symbol. - - - - - - - - - - - - - - - - In the symbolDef context, symbol must have - either a startid attribute or x and y attributes. - In the symbolDef context, symbol - must have one of the following attributes: altsym, glyph.name, or - glyph.num. - - - - -

The starting point, e.g., "hotspot", of the symbol may be identified in absolute output - coordinate terms using the x and y attributes or relative to another - element using the startid attribute. Attributes in the att.visualOffset class may - be used to record horizontal, vertical, or time offsets from the absolute coordinates or - from the location of the referenced element. The altsym attribute must contain the - id of a symbolDef element. The scale attribute indicates - that the printed output must be scaled by the specified percentage.

- - - - Text and symbols descriptive of tempo, mood, or style, e.g., "allarg.", "a tempo", - "cantabile", "Moderato", "♩=60", "Moderato ♩ =60"). - - - - - - - - - - - - - - - - - - - - - - - - - - - Only analog, class, label, mm, mm.dots, mm.unit, n, translit, type, xml:base, xml:id, - and xml:lang attributes are allowed when tempo is not a descendant of a score or - part. - - - - - - - Must have one of the - attributes: startid, tstamp, tstamp.ges or tstamp.real. - - - - - - Keyword or phrase which describes a resource. - - - - - - - - - - - - - - - - - - - The @data attribute may only occur on a - term which is a descendant of a classification element. - - - - -

The term element may include other term - elements in order to allow the creation of coordinated terms; i.e., terms created from a - combination of other, independent terms.

-

To associate a term with a taxonomy category defined in the MEI metadata header, the value - of class must contain a fragment identifier corresponding to the appropriate term element. To associate a term with category in an externally-defined - taxonomy, class must contain an absolute URI, which may include the fragment - identifier of the element containing the category label.

- - -

The model of this element is based on the term element of the Text Encoding Initiative (TEI).

- - - - text language - Identifies the languages and writing systems within the work described - by a bibliographic description, not the language of the description. - - - - - - - - - - - - - - - - - - (main language) supplies a code which identifies the chief language used in the - bibliographic work. - - - - - - (other languages) one or more codes identifying any other languages used in the - bibliographic work. - - - - - - - - Title of a bibliographic entity. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Indicates the bibliographic level of the title. - - - Analyzed component, such as an article or chapter, within a larger bibliographic - entity. - - - Collection. A group of items that were not originally published, distributed, or - produced together. - - - Subunit of a collection, e.g., item, folder, box, archival series, subgroup, or - subcollection. - - - Integrating resource, such as a continuously updated loose-leaf service or Web - site. - - - Monograph. - - - Journal. - - - Series. - - - Unpublished (including theses and dissertations unless published by a commercial - press). - - - - - Characterizes the title in some sense, using any convenient classification scheme or - typology that employs single-token labels. - - - - - - Main title. - - - Subtitle or title of part. - - - Abbreviated form of title. - - - Alternate title by which the item is also known. - - - Translated form of title. - - - Collective title. - - - Descriptive paraphrase of the work. - - - - - -

The type attribute may be used to classify the title according to some - convenient typology. Sample values include: main (main title), subordinate (subtitle, title - of part), abbreviated (abbreviated form of title), alternative (alternate title by which the - work is also known), translated (translated form of title), uniform (collective title), and - desc (descriptive title). The type attribute is provided for convenience in - analysing titles and processing them according to their type; where such specialized - processing is not necessary, there is no need for such analysis, and the entire title, - including subtitles and any parallel titles, may be enclosed within a single title element. Title parts may be encoded in titlePart sub-elements. The name of the list from which a controlled value is taken - may be recorded using the auth attribute. The number of initial characters (such - as those constituting an article or preposition) that should not be used for sorting a title - or name may be indicated in the nonfiling attribute.

- - -

The model of this element is based on the title element of the Text Encoding Initiative (TEI).

- - - - Contains a transcription of the title page of a text. - - - - - - - - - - - - - - - - - - - - - - - - -

This element may be used within the physDesc element when no other - transcription is provided.

- - -

The model of this element is based on the titlePage element of the Text Encoding Initiative (TEI).

- - - - Contains a subsection or division of the title of a bibliographic entity. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Characterizes this title component in some sense, using any convenient classification - scheme or typology that employs single-token labels. - - - - - - Alternate title by which the item is also known. - - - Arranged statement for music. Analogous to MARC 240 subfield o. - - - Medium of the carrier. Analogous to MARC 240 subfield h. - - - Publication/creation date(s) of work. Analogous to MARC 240 subfield f. - - - Descriptive paraphrase of the work. - - - Form subheading. Analogous to MARC 240 subfield k. - - - Key for music. Analogous to MARC 240 subfield r. - - - Language of a work. Analogous to MARC 240 subfield l (el). - - - Main title. - - - Name of a part or section of a work. Analogous to MARC 240 subfield p. - - - Standard number designation of a work or of a part or section of a work. Analogous - to MARC 240 subfield n. - - - Performance medium. Analogous to MARC 240 subfield m. - - - Subtitle. - - - Translated form of title. - - - Version. Analogous to MARC 240 subfield s. - - - - - -

The model of this element is based on the titlePart element of the Text Encoding Initiative (TEI).

- - - - Description of the horizontal size of an object. - - - - - - - - - - - - - - - - - - - - Tablature component declarations. - - - String tablature string and fret information. - - - Indicates which finger, if any, should be used to play an individual string. The - index, middle, ring, and little fingers are represented by the values 1-4, while t is - for the thumb. The values x and o indicate muffled and open strings, - respectively. - - - - - - Records the location at which a string should be stopped against a fret. - - - - - - Records which string is to be played. - - - - - - - - String tablature position information. - - - Records fret position. - - - - - - - - String tablature tuning information. - - - Provides a *written* pitch and octave for each open string or course of - strings. - - - - - [a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?([a-g][0-9](s|f|ss|x|ff|xs|sx|ts|tf|n|nf|ns|su|sd|fu|fd|nu|nd|1qf|3qf|1qs|3qs)?)* - - - - - - - - - A barre in a chord tablature grid. - - - - - - - - - - Records the location at which the strings should be stopped against a fret in a - fretboard diagram. This may or may not be the same as the actual location on the fretboard - of the instrument in performance. - - - 1 - 5 - - - - - -

The startid and endid attributes are used to indicate the chordMember elements on which the barre starts and finishes respectively. - The fret at which the barre should be created is recorded by the fret - attribute.

- - - - - - Text component declarations. - - - Groups elements that may contain back matter. - - - - - - Groups elements used to represent generic structural divisions of text. - - - Groups elements that may contain front matter. - - - - - - Groups elements that have a line-grouping function. - - - - - - - Groups list-like elements. - - - - - - - Groups elements representing metrical components such as verse lines. - - - Groups elements related to highlighting which can appear at the phrase-level. - - - - - - Groups elements used to directly contain quotations. - - - - - - - Contains a formal list or prose description of topics addressed. - - - - - - - - - - - - - - - - - - - - - - - - - - -

The model of this element is based on the argument element of the Text Encoding Initiative (TEI).

- - - - back matter - Contains any appendixes, advertisements, indexes, etc. following the main - body of a musical text. - - - - - - - - - - - - - - - - - - -

The model of this element is based on the back element of the Text Encoding Initiative (TEI).

- - - - Contains a quotation, anonymous or attributed, appearing on a title page. - - - - - - - - - - - - - - - - - -

The model of this element is based on the epigraph element of the Text Encoding Initiative (TEI).

- - - - front matter - Bundles prefatory text found before the start of the musical text. - - - - - - - - - - - - - - - - - - -

titlePage may be used to transcribe the item’s title page. Other - front matter structures, such as a preface, dedication, or table of contents, may be encoded - as textual divisions; that is, as div elements, with an optional head sub-element describing the nature of the division. The pb element is allowed here in order to accommodate page images, e.g., - cover, endpapers, etc. before and after the actual textual matter.

- - -

The model of this element is based on the front element of the Text Encoding Initiative (TEI).

- - - - Contains a formal statement authorizing the publication of a work, sometimes required to - appear on a title page or its verso. - - - - - - - - - - - - - - - - -

The model of this element is based on the imprimatur element of the Text Encoding Initiative (TEI).

- - - - line of text - Contains a single line of text within a line group. - - - - - - - - - - - - - - - - - - - - - - Used to specify a rhythm for the lyric syllables that differs from that of the notes - on the staff, e.g., '4,4,4,4' when the rhythm of the notes is '4.,8,4.,8'. - - - - - - -

Do not confuse this element with the line element, which is used for - graphical lines that occur in music notation.

- - -

The model of this element is based on the l element of the Text Encoding Initiative (TEI).

- - - - list item - Single item in a list. - - - - - - - - - - - - - - - - - -

The model of this element is based on the item elements of the Encoded Archival Description (EAD), the item element of the Text - Encoding Initiative (TEI), and the li element of HTML.

- - - - A formatting element that contains a series of items separated from one another and - arranged in a linear, often vertical, sequence. - - - - - - - - - - - - - - - - - - - - - - - - - - - In a list of type "gloss" all items - must be immediately preceded by a label. - - - - - - Used to indicate the format of a list. In a simple list, li - elements are not numbered or bulleted. In a marked list, the sequence of the list items - is not critical, and a bullet, box, dash, or other character is displayed at the start of - each item. In an ordered list, the sequence of the items is - important, and each li is lettered or numbered. Style sheet - functions should be used to specify the mark or numeration system for each li. - - - Items are not numbered or bulleted. - - - Bullet, box, dash, or other character is displayed before each item. - - - Each item is numbered or lettered. - - - - - Captures the nature of the content of a list. - - - - - - Each list item glosses some term or concept, which is given by a label element - preceding the list item. - - - Each list item is an entry in an index such as the alphabetical topical index at - the back of a print volume. - - - Each list item is a step in a sequence of instructions, as in a recipe. - - - Each list item is one of a sequence of petitions, supplications or invocations, - typically in a religious ritual. - - - Each list item is part of an argument consisting of two or more propositions and a - final conclusion derived from them. - - - -

In a list of type gloss it is a semantic error not to precede each list item with a - label.

- - - - -

The model of this element is based on the list element of the Encoded Archival Description (EAD), the list element of the Text Encoding - Initiative (TEI), and the respective elements of HTML.

- - - - quoted - Contains material which is distinguished from the surrounding phrase-level text - using quotation marks or a similar method. Use quote for block-level - quotations. - - - - - - - - - - - - - - - - - - - - - - - - - - Representation of speech. - - - Representation of thought, e.g., internal monologue. - - - Quotation from a written source. - - - Authorial distance. - - - Linguistically distinct. - - - Linguistically distinct. - - - Technical term. - - - Rhetorically emphasized. - - - Refering to itself, not its normal referent. - - - - - -

This element may be used for a variety of reasons including, but not limited to: direct - speech or thought, technical terms or jargon, authorial distance, quotations from elsewhere, - and passages that are mentioned but not used.

-

Do not confuse this element, used to capture phrase-level quotations, and quote, intended for block quotations.

- - -

The model of this element is based on the q element of HTML and the q element of the Text Encoding Initiative (TEI).

- - - - quoted material - Contains a paragraph-like block of text attributed to an external - source, normally set off from the surrounding text by spacing or other typographic - distinction. - - - - - - - - - - - - - - - - - - -

The source for the quote may be included in a bibl sub-element.

-

Do not confuse this element, used to capture block-level quotations, and q, intended for inline quotations.

- - -

The model of this element is based on the quote element of the Text Encoding Initiative (TEI) and the quote element of the Encoded Archival Description (EAD).

- - - - arbitrary segment - represents any segmentation of text below the "text component" level. - - - - - - - - - - - - - - - - - - -

The model of this element is based on the seg element of the Text Encoding Initiative (TEI).

- - - - - - User-defined symbols component declarations. - - - Attributes supplying pointers to user-defined symbols. - - - Provides a way of pointing to a user-defined symbol. It must contain a reference to an - ID of a symbolDef element elsewhere in the document. - - - - - - - @altsym attribute - should have content. - The value in @altsym should correspond to the @xml:id attribute of a symbolDef - element. - The value - in @altsym must not correspond to the @xml:id attribute of a symbolDef - ancestor. - - - - - - - - Logical domain attributes. - - - - - - Indicates the function of the text. - - - - - - The function of the text is unknown. - - - - - - - Logical domain attributes. - - - - - - Indicates the function of the curve. - - - - - - The function of the curve is unknown. - - - - - - - Attributes for describing the logical behavior of a line. - - - - - - - - - Indicates the function of the line. - - - - - - Indicates coloration in material transcribed from a source originally in mensural - notation. - - - Marks a ligature in material transcribed from a source originally in mensural - notation. - - - The function of the line is unknown. - - - - - - - Groups elements that function as drawing primitives. - - - Groups elements that group symbol definitions. - - - Container for text that is fixed to a particular page location, regardless of changes made - to the layout of the measures around it. - - - - - - - - - - - - - - - - - - - - - -

This element may be used where semantic markup of the text is neither possible nor - desirable, such as in optical music recognition (OMR) applications. The content model here - is similar to paragraph without model.textcomponent and pb - sub-elements. The starting point of the text may be identified in absolute output coordinate - terms using the x and y attributes or relative to the location of - another element using the startid attribute. The attributes in the - att.visualOffset class may be used to record horizontal, vertical, or time offsets from the - absolute coordinates or from the location of the referenced element.

- - - - A curved line that cannot be represented by a more specific element, such as a - slur. - - - - - - - - - - - - - - - - In the symbolDef context, curve must have - either a startid attribute or x and y attributes. - In the symbolDef context, curve must have - either an endid attribute or both x2 and y2 attributes. - In the symbolDef context, curve must have either a - bezier or bulge attribute. - - - - -

The starting point of the curve may be identified in absolute output coordinate terms using - the x and y attributes or relative to the location of another element - using the startid attribute. The attributes in the att.visualOffset class may be - used to record horizontal, vertical, or time offsets from the absolute coordinates or from - the location of the referenced element. Similarly, the terminal point of the curve may be - recorded using either the x2 and y2 coordinates or in relation to the - location of another element using the endid attribute. Attributes in the - att.visualOffset2 class maybe used to record the offsets of the ending point. The - bulge attribute or, alternatively, the bezier attribute, describe the - shape of the curve and the lform and lwidth attributes capture its - appearance.

- - - - A visual line that cannot be represented by a more specific; i.e., semantic, - element. - - - - - - - - - - - - - - - - - - - - - When used in the symbolDef context, must have - either a startid attribute or x and y attributes. - When used in the symbolDef context, must have - either an endid attribute or both x2 and y2 attributes. - - - When - used in the score context, must have a startid, tstamp, tstamp.ges or tstamp.real - attribute or both x and y attributes. - When used in - the score context, must have an endid, dur, dur.ges, or tstamp2 attribute or both x2 and - y2 attributes. - - - - -

The starting point of the line may be identified in absolute output coordinate terms using - the x and y attributes. The attributes in the att.visualOffset class - may be used to record horizontal, vertical, or time offsets from these absolute coordinates - or from the location of the element reference in the startid attribute. - Similarly, the terminal point of the line may be recorded using the x2 and - y2 attributes. Attributes in the att.visualOffset2 class maybe used to record the - offsets of the ending point. Textual content of the line element, e.g., - 'gliss.', may be rendered with the line. The appearance of the line is captured in the - color, form and width attributes.

- - - - One or more characters which are related to the parent symbol in some respect, as - specified by the type attribute. - - - - - - - - - - - - - - property name - Name of a property of the symbol. - - - - - - - - - - - - - Characterizes the property name. - - - A registered Unicode normative or informative property name. - - - A locally defined name. - - - - - - - property value - A single property value. - - - - - - - - - symbol definition - Declaration of an individual symbol in a symbolTable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Like a chord table, a symbolTable may be shared between MEI instances through the use of an - external parsed entity containing the symbolTable to be shared.

- - - - symbol name - Contains the name of a symbol, expressed following Unicode - conventions. - - - - - - - - - symbol property - Provides a name and value for some property of the parent - symbol. - - - - - - - - - - Contains a set of user-defined symbols. - - - - - - - - - - -

Like a chord table, a symbolTable may be shared between mei instances through the use of an - external parsed entity containing the symbolTable to be shared.

- - - - - - Visual component declarations. - - - Visual domain attributes. - - - - - - - - - - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - - - - - Visual domain attributes. - - - Location of the annotation. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - Indicates if an arrowhead is to be drawn as part of the arpeggiation symbol. - - - - - - Symbol rendered at end of the line. - - - - - - Holds the relative size of the arrow symbol. - - - - - - Captures the overall color of the arrow. - - - - - - Captures the fill color of the arrow if different from the line color. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - length - States the length of bar lines in virtual units. The value must be greater than 0 and - is typically equal to 2 times (the number of staff lines - 1); e.g., a value of 8 for a - 5-line staff. - - - 0 - - - -

This attribute is ignored if the value of the style attribute is mensur.

- - - - Records the method of barring. - - - - - - Denotes the staff location of the bar line if its length is non-standard. - - - - -

The location may include staff lines, the spaces between the lines, and the spaces - directly above and below the staff. The value ranges between 0 (just below the staff) to - 2 * number of staff lines (directly above the staff). For example, on a 5-line staff the - lines would be numbered 1, 3, 5, 7, and 9 while the spaces would be numbered 0, 2, 4, 6, - 8, and 10. So, a value of 9 puts the bar line through the top line of the staff.

-

This attribute is ignored if the value of the style attribute is mensur.

- - - - - - Visual domain attributes. - - - - - - - - - Used by layerDef, staffDef, and scoreDef to provide default values for attributes in the - visual domain related to beaming. - - - Color of beams, including those associated with tuplets. - - - - - - Encodes whether a beam is "feathered" and in which direction. - - - Beam lines grow farther apart from left to right. - - - Beam lines grow closer together from left to right. - - - Beam lines are equally-spaced over the entire length of the beam. - - - - - Captures beam slope. - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - Indicates the number of slashes required to render the appropriate beat repeat symbol. - When a single beat consisting of a single note or chord is repeated, the repetition symbol - is a single thick, slanting slash; therefore, the value 1 should be used. When the beat - is divided into even notes, the following values should be used: 4ths or 8ths=1, 16ths=2, - 32nds=3, 64ths=4, 128ths=5. When the beat is comprised of mixed duration values, the - default rendition is 2 slashes and 2 dots. - - - - - - - - Visual domain attributes. If the bulge or bezier attributes are present, the bend should - be rendered as a curve. Otherwise, it should be rendered using lines. The ho and vo attributes - describe the visual offset of the entire rendered bend. The endho, endvo and startho, startvo - attribute pairs may be used to encode start and end points relative to their programmatic - placement. For exact placement of the endpoints of the bend, use the x and y - attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes for chord. The slur, slur.dir, slur.rend, tie, tie.dir, and - tie.rend attributes here are syntactic sugar for these attributes on each of the chord's - individual notes. The values here apply to all the notes in the chord. If some notes are - slurred or tied while others aren't, then the individual note attributes must be used. - - - - - - - - - - - - - - - - Indicates a single, alternative note head should be displayed instead of individual - note heads. The highest and lowest notes of the chord usually indicate the upper and lower - boundaries of the cluster note head. - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the visual - domain related to clefs. - - - Describes the color of the clef. - - - - - - Determines whether the clef is to be displayed. - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - - Attributes describing the direction of curvature. - - - Records direction of curvature. - - - Anti-clockwise curvature. - - - Clockwise curvature. - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - - - Horizontal stroke. - - - Vertical stroke. - - - - - Captures the placement of the episema with respect to the neume or neume component - with which it is associated. - - - - - - - - Visual domain attributes. - - - - - - - - -

If tstamp2 is not provided, then the extender should be drawn based on the value - of tstamp2 on the harm ancestor.

- - - - Visual domain attributes. - - - - - - - - - - - - - Describes the visual appearance of the fermata; that is, whether it occurs as upright - or inverted. - - - Inverted, i.e., curve or bracket below the dot. - - - Upright; i.e., curve or bracket above the dot. - - - - - Describes the visual appearance of the fermata; that is, whether it has a curved, - square, or angular shape. - - - A curve above or below the dot. - - - A bracket above or below the dot. - - - A triangle above or below the dot. - - - - - - - Visual domain attributes. - - - - - - - - -

If tstamp2 is not provided, then the extender should be drawn based on the value - of tstamp2 on a fingering ancestor.

- - - - Visual domain attributes. - - - - - - - - - - orientation - - - Combination expressed horizontally, as for brass instruments. - - - Combination expressed vertically, as for woodwind instruments or piano. - - - - - - - Visual domain attributes. - - - Indicates the number of beams present. - - - 1 - 6 - - - - - Captures the number of "floating" beams, i.e., those not attached to stems. - - - - - - - The number of floating beams must be less - than or equal to the total number of beams. - - - - - - Records the amount of separation between floating beams and stems. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes - - - Determines whether to display guitar chord grids. - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. The startho and startvo attributes record the horizontal and - vertical offsets of the left end, endho and endvo record the horizontal and vertical offsets - of the right end, and the opening attribute records the width of the opening in staff - inter-line units. The x and y attributes give the absolute coordinates of the left end point, - and x2 and y2 the right end point, of an imaginary line that defines the length of the hairpin - and horizontally bifurcates it. The so-called "pitch" of hairpin may be controlled by use of - the startho, endho, startvo, and endvo attributes, while the placement of the entire rendered - mark may be controlled by use of the ho and vo attributes. - - - - - - - - - - - - - Specifies the distance between the lines at the open end of a hairpin dynamic - mark. - - - - - - Applies to a "Rossini" hairpin, i.e., one where the normally open side is closed by a connecting line. - - - - - - Indicates that the opening points are aligned with an imaginary line that is always 90° perpendicular to the horizontal plane, regardless of any angle or start/end adjustments, including when the hairpin is angled with @angle.optimize or through @endvo/@startvo adjustments. - - - - - - Indicates that the slope of the hairpin can be adjusted to follow the content in order to optimize spacing. - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - Describes how the harmonic indication should be rendered. - - - Chord tablature grid. - - - Chord tablature grid and the element’s textual content. - - - Textual content of the element. - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Captures the placement of the tick mark with respect to the neume or neume component - with which it is associated. - - - - - - Direction toward which the mark points. - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - Determines where cautionary accidentals should be displayed at a key change. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the visual - domain related to key signatures. - - - Determines where cautionary accidentals should be displayed at a key change. - - - - - - Determines whether the key signature is to be displayed. - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - Visual domain attributes. - - - - - - Provides an indication of the function of the ligature. - - - - - - - - Attributes for describing the visual appearance of a line. - - - - - - - - - - - Visual form of the line. - - - - - - - Width of the line. - - - - - - - Symbol rendered at end of line. - - - - - - Holds the relative size of the line-end symbol. - - - - - - - Symbol rendered at start of line. - - - - - - Holds the relative size of the line-start symbol. - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - Indicates whether curve is closed. - - - - - - - - Visual domain attributes. The vo attribute is the vertical offset (from its normal - position) of the entire rendered tie. The startho, startvo, endho, and endvo attributes - describe the horizontal and vertical offsets of the start and end points of the sign in terms - of staff interline distance; that is, in units of 1/2 the distance between adjacent staff - lines. Startto and endto describe the start and end points in terms of time; that is, - beats. - - - - - - - - - - - - Visual domain attributes. - - - - - - - Visual domain attributes. - - - - - - - Visual domain attributes. These attributes describe the physical appearance of the - mensuration sign/time signature of mensural notation. - - - - - - - - - - - Specifies whether a dot is to be added to the base symbol. - - - - - - Indicates whether the base symbol is written vertically or horizontally. - - - Horizontally oriented. - - - Vertically oriented. - - - - - Describes the rotation or reflection of the base symbol. - - - - - - The base symbol in the mensuration sign/time signature of mensural notation. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the visual - domain related to mensuration. - - - Records the color of the mensuration sign. Do not confuse this with the musical term - 'color' as used in pre-CMN notation. - - - - - - Determines if a dot is to be added to the base symbol. - - - - - - Indicates whether the base symbol is written vertically or horizontally. - - - Horizontally oriented. - - - Vertically oriented. - - - - - Holds the staff location of the mensuration sign. - - - - - - Describes the rotation or reflection of the base symbol. - - - - - - The base symbol in the mensuration sign/time signature of mensural notation. - - - - - - Describes the relative size of the mensuration sign. - - - - - - Indicates the number lines added to the mensuration sign. For example, one slash is - added for what we now call 'alla breve'. - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - - Contains an indication of how the meter signature should be rendered. - - - - - - - - Used by staffDef and scoreDef to provide default values for attributes in the visual - domain related to meter signature. - - - Contains an indication of how the meter signature should be rendered. - - - - - - Determines whether the old meter signature should be displayed when the meter - signature changes. - - - - - - Determines whether the meter signature is to be displayed. - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - The block attribute controls whether the multimeasure rest should be rendered as a block rest - or as church rests ("Kirchenpausen"), that are combinations of longa, breve and semibreve rests. - - - - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - Visual domain attributes. - - - Visual domain attributes. - - - Visual domain attributes. - - - States the side of a leaf (as in a manuscript) on which the content following the pb element occurs. - - - The back of a manuscript page. - - - The front of a manuscript page. - - - - - - - Visual domain attributes. The place attribute captures the placement of the pedal marking - with respect to the staff with which it is associated. Modern publishing standards require the - place to be below; however, for transcriptions of manuscript works, this attribute class - allows the full range of values. - - - - - - - - - - - - - - Determines whether piano pedal marks should be rendered as lines or as terms. - - - - - - - - Visual domain attributes. - - - - - - - - - - - Visual domain attributes that describe the properties of a plica stem in the mensural repertoire. - - - direction - Describes the direction of a stem. - - - - - - length - Encodes the stem length. - - - - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Number of "crests" of a wavy line. - - - 2 - 4 - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - Indicates whether hash marks should be rendered between systems. See Read, p. 436, ex. - 26-3. - - - Display hash marks between systems. - - - - - - - Visual domain attributes. - - - Visual domain attributes for scoreDef in the CMN repertoire. - - - - - - - - - - - - - - - - - - - - - - - - Defines the height of a "virtual unit" (vu) in terms of real-world units. A single vu - is half the distance between adjacent staff lines where the interline space is measured - from the middle of a staff line. - - - - \d+(\.\d+)?(cm|mm|in|pt|pc) - - - - - - - Visual domain attributes. - - - Indicates that staves begin again with this section. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Captures the placement of the sequence of characters with respect to the neume or - neume component with which it is associated. - - - - - - - - Visual domain attributes for slur. The vo attribute is the vertical offset (from its - normal position) of the entire rendered slur/phrase mark. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes. - - - - - - Indicates whether a space is 'compressible', i.e., if it may be removed at the - discretion of processing software. - - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes for staffDef. - - - - - - - - - - - - - - - - - - - - - Indicates the number of layers and their stem directions. - - - - - - Captures the colors of the staff lines. - - - - -

The value is structured; that is, it should contain a single color value or have - the same number of space-separated values as the number of lines indicated by the - lines attribute. The first value then applies to the lowest line of the staff.

-

All values from data.COLOR are allowed.

- - - - Records whether all staff lines are visible. - - - - - - Records the absolute distance (as opposed to the relative distances recorded in scoreDef elements) between this staff and the preceding one in the same - system. This value is meaningless for the first staff in a system since the spacing.system - attribute indicates the spacing between systems. - - - - - - - - Visual domain attributes. - - - - - - - - bar lines through - Indicates whether bar lines go across the space between staves (true) or are only - drawn across the lines of each staff (false). - - - - -

This attribute is ignored when the bar.method attribute’s value is mensur - or takt.

- - - - - - Visual domain attributes. - - - - - - - - - - Visual domain attributes that describe the properties of a stem in the mensural repertoire. - - - - - - - - - position - Records the position of the stem in relation to the note head(s). - - - - - - length - Encodes the stem length. - - - - - - Encodes the form of the stem using the values provided by the data.STEMFORM.mensural datatype. - - - - - - direction - Describes the direction of a stem. - - - - - - Records the position of the flag using the values provided by the data.FLAGPOS.mensural datatype. - - - - - - Encodes the form of the flag using the values provided by the data.FLAGFORM.mensural datatype. - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. The vo attribute is the vertical offset (from its normal - position) of the entire rendered tie. The startho, startvo, endho, and endvo attributes - describe the horizontal and vertical offsets of the start and end points of the tie in terms - of staff interline distance; that is, in units of 1/2 the distance between adjacent staff - lines. Startto and endto describe the start and end points in terms of time; that is, - beats. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - - - - - Visual domain attributes. - - - - - - - Used to state where a tuplet bracket will be placed in relation to the note - heads. - - - - - - States whether a bracket should be rendered with a tuplet. - - - - - - Determines if the tuplet duration is visible. - - - - - - Controls how the num:numbase ratio is to be displayed. - - - Only the num attribute is displayed, e.g., '7'. - - - Both the num and numbase attributes are displayed, e.g., '7:4'. - - - - - - - Visual domain attributes. - - - - - - Visual domain attributes. - - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - - - Visual domain attributes. - - - - - - - - - - -
- - - \ No newline at end of file