5.0 Resources for OMR
Note
This page is currently under construction, with more information added over the Winter 2024 and Summer 2024 semesters.
This area is under construction and will be updated over time.
This area is under construction and will be updated over time.
IIIF manifest URLs can be found in a variety of ways, most often directly from the collection hosting the manuscript, which will often either have the URL directly listed or will have a IIIF logo [LOGO] which can be clicked or dragged so that you can open the manifest in a new tab, or drag into a viewer. IIIF has put together a guide for finding URLs, with a list of participating collections: https://iiif.io/guides/finding_resources/ and a resource for how to find the IIIF link from each participating viewer IIF resources - IIIF link from within participating collections.pdf.
Many tools and project utilising IIIF will list their manifests in some place- Cantus Ultimus lists their manuscript IIIF images here.
This area is under construction and will be updated over time.
Once a IIIF manifest is located, the issue becomes rendering what is seen in the text to the images you need. This is where a variety of tools come in handy, depending upon what you seek to accomplish.
An excellent option for quick viewing a manuscript quickly- essentially all of the following tools can be utilised for viewing, with ultimate preference being up to how each user prefers to view and navigate images. We strongly encourage giving each tool a try and seeing which view and interface works best for your purposes. Preference in this guide will be given to in-browser tools not requiring any separate setup, though more in depth options will be discussed below.
Viewing a manuscript can be a helpful first step for quickly navigating through a manuscript to locate explicit images- finding an illumination within a book, or a section of music within a mostly-prose context. There are various viewers which allow for others tools, such as annotation.
Universal Viewer is the final version of the Wellcome Player made by Digirati, and is the most commonly used IIIF viewer by National Cultural Heritage Institutions.
Mirador is a viewer created, maintained, and collaborated upon by Project Mirador.
IIIF Curation Viewer, created and maintained by the Center for Open Data in the Humanities
Note
In the above link, in the URL following "iiif-curation-viewer/demo/?manifest=" you can also drop the URL to the manifest you would like to view instead of navigating back to the main screen of the viewer, but can be accessed here.
Digital Bodleian, by the University of Oxford.
Tify by the Universitätbibliothek Gröningen is an excellent manifest viewer and editor (brightness, contrast, saturation). Can be downloaded and embedded in other websites.
Diva.js by two parties: the Distributed Digital Music Archives and Libraries Lab (DDMAL) and Swiss RISM. Has an in browser viewer, as well as options for local implementation and embedding in your website (see "Tools"). Diva.js allows for extremely nuanced visual manipulation of the manuscript pages you wish to utilise (from rotation and transformation to brightness, saturation, etc.).
There are a variety of use cases wherein you may want to be able to annotate or curate what images you are looking at within a manifest. To curate images within a manifest, or to select specific images within a manifest into a curated collection for your later use, the IIIF Curation Viewer is singularly effective.
Tip
Inside this tool, once you've uploaded your manifest/edited your URL per the above step, click on the "?" icon, which will show you the relevant steps for curating and viewing your curations. Similarly, this button will direct you to a link which contains the tutorial for the viewer (note: is in Japanese, but at the top right of the page is a language toggle).
For annotating an image, the Digital Bodleian manifest editor is excellent.
There are a variety of IIIF tools which can download a manifest. However, priority here is given to items which can function in-browser and do not require separate steps (such options can be found below under "Tools").
Singularly helpful is the free and open source tool produced by Liz Fischer: https://www.lizmfischer.com/iiif-tools/download . She also has a viewer.
This area is under construction and will be updated over time. The following are helpful tools for a variety of manifest viewing, editing, annotating, etc., tasks. This list will also include powerful IIIF viewers which require extra steps, such as downloading.
-
Diva.js A singularly powerful tool for the editing, viewing, and manipulation of IIIF images, Diva.js requires some extra steps to utilise either as a user, or as a developer for implementation in your website or tool (see the Diva.js directions and documentation). An example of its capabilities are available in its demo. The default instance demonstrates its basic functionality, but by clicking on the small slider icon at the top of the pages viewed you will see the full array of the excellent image manipulation tools Diva offers.
-
Tify Is a IIIF document viewer built using Vue.js by the Universitätbibliothek Göttingen, which can be embedded into a website or used in-browser- see their Github for instructions.
-
JRegimbal/iiif-downloader Uses the IIIF image API to download images from a IIIF manifest. Requires Python 3.x (up to date), and can be installed in the command line. Instructions and other information can be found on their GitHub.
For some manifests where their images are stored on a unoptimized image server, or one using Cantaloupe (such as Archive.org uses for their IIIF hosting), there may be some issues with viewing and timing out. It is strongly recommended that, should you encounter a manifest which cannot seem to load, to check where it is hosted, and if you absolutely need the image to contact the organization which digitized the collection directly (such as the library or archive).
Make sure you check what version of the IIIF API is being utilised. IIIF recently updated its versions, and some previous IIIF tools, particularly downloaders, have said they will not update (such as the popular Docker configured container built by ryanfb) and as such will not work as well or safely.
This page is meant to stand as a reference section for users unfamiliar with the various terminology associated with medieval manuscripts, music, and music notation, such as neumes, with a particular focus (for the time being) on square notation.
For now, the following document contains basic shapes and terminology for the notes, staff, clef, and directions you will most commonly encounter. This reference section will be expanded.
Note shapes, clefs, staffs, etc: Liber Usualis - Preface and Guide to Interpretation.pdf
Modes: Hiley Modes.pdf
| Bibliography |
|---|
Important
Catholic Church. eds. Benedictines of Solesmes. 1961. The Liber Usualis: with Introduction and Rubrics in English. Tournai; New York: Desclee Company. Full text.
Hiley, David. 2009. Gregorian Chant. Cambridge: Cambridge University Press, 44. https://doi.org/10.1017/CBO9780511807848 .
This section is meant to give a general understanding of what MEI looks like and does. For an in-depth documentation, please consult the following:
Music Encoding - webpage, tools and resources.
MEI friend: https://mei-friend.mdw.ac.at/
Documentation: https://github.com/mei-friend/mei-friend
The purpose of the MEI mapping, or .csv, file is to assign the correct MEI description to each glyph identified by the Interactive Classifier. The file is a spreadsheet that contains every name that was given to a glyph category in the IC—such as clef.c or neume.punctum—and matches it with its MEI description.
There are four important columns in the csv spreadsheet: the name, the classification, the width, and the MEI.
-
Name: The name column contains the common names of the glyphs being classified, such as punctum, virga, inclinatum, c clef. This column is for the humans' use only, so the names don't have to be standard, as long as they're recognizable by anyone who might be using the spreadsheet.
-
Classification: The classification column contains the names that were given each glyph in the Interactive Classifier.
Caution
It is extremely important that these classifications match exactly. It doesn't matter what they are, as long as they match. If a punctum was classified as neume.punctum in the IC, then the punctum in the spreadsheet must be a neume.punctum in the classification column. If a given classification doesn't match, the MEI_encoding job won't be able to assign that glyph its MEI description and the glyph will be completely absent from the resulting MEI file.
- Width: The width column is used to describe the spatial organization of glyphs with more than one neume component. (The name "width" is not ideal, it's just the best we could come up with.) If a glyph has, say, two neume components, both neume components will be given the same x coordinate by default; visually, this means that both neume components will be stacked one on top of the other. This is fine for a neume such as the podatus, but not for neumes like the torculus, where the neume components should be appearing one after the other. Therefore, the width of the neume describes how many neume components should be stacked for each unit of x axis one neume component wide. This is undoubtedly best described with images:
Important
The width of any single-neume component neume is 1. The width of a ligature is also 1.
- MEI: The MEI column contains the MEI description of each glyph. MEI is a code meant to be read by computers, not humans, but the system is consistent and straightforward. (The following explanation is not exhaustive and is meant only for general understanding. For a full and thorough explanation of MEI neume formatting, please consult MEI documentation.)
Every neume starts and ends with a tag. Each neume component within the neume then has its own line between the opening and closing lines.
The MEI of a punctum, the most basic neume, is this:
<neume>
<nc/>
</neume>
Other symbols have attributes that distinguish it from the basic punctum. The MEI of an inclinatum includes a tilt="se" to describe it's diagonal shape. In other situations, a tilt attribute indicates the presence of a tail, with tilt="s" being a tail on the right, and tilt="n" being a tail on the left. Similarly, a liquescent is described with a curve attribute.
If a neume has more than one neume component, the interval between each neume component is described in steps: 1S is one step up, 2S is two steps up, etc., and 1S is one step down, -2S is two steps down, etc.
In the end, neumes in the csv file will be described something like this:
