Byzantine Notation Support

[t-bullock]

Are there any plans to support Byzantine Notation (New Method, 1814)?

[bwbohl]

@t-bullock at the moment I'm not aware of any advances in that direction. @annplaksin are you aware of any notions? How close is that to your ottoman notation, are there any overlaps?
But of course, if you're able to provide the musicological expertise we could at least assist you in the modelling aspects ;-)

[annplaksin]

Yes, Byzantine Notation is used in Ottoman sources too. So we're thinking about preparing a proposal for its support in MEI, but it's not our highest priority yet.
@t-bullock I'm repeating the invitation: If you're able to provide some expertise, you are happily invited to join our task. We already have a turkish-music channel at the MEI Slack

[nsiklafidis]

@bwbohl , @annplaksin @t-bullock I have a master in Byzantine Musicology at the Aristotle University of Thessaloniki and a good knowledge on xml. I would like to contribute for the MEI schema. The signs (notes) for the Byzantine Music in unicode system are between 1D000-1D0FF (246 signs). The problem is that we need more signs to write in varius notational types e.g. for the Greek chant repertories belonging to the 3rd-21st centuries A.D. It is necessary to use the unicode system? Can we create a font for the contact with the MEI schema?
Please help us about the modelling aspects so we can start this task.
Thank you!

[bwbohl]

Welcome @nsiklafidis , and sorry for my late reply!!
It's great to hear hat you are seeking yet for another repertoire to be encoded in MEI. First MEI is absolutely unconnected to the unicode code blocks. What MEI does is capture the semantics of musical symbols. To get a first glimpse of how MEI works in generals I'd recommend the tutorial on the websit, e.g. https://music-encoding.org/tutorials/101-quickstart.html
If you want to see other notation systems covered please have a look at the customisations for Neues or Mensural notation.
If MEI tags do not cover your needs a first step would be to make a logical model of your needs, e.g. for Common Western Notation this might be something like:

• Notation
  • staff
    • measure
      • multiple voices

As you might not want to transliterate your notation systems into CWN, but instead capture the original semantics you might have to introduce new elements that reflect the semantics of your notation system.
If you have any questions or need of assistance please feel free to contact me ;-)

[nsiklafidis]

@bwbohl thank you for your answer!!

1. I saw that with the code <note pname="c" oct="4" dur="4"/> we render the musical note C (Do).
2. Do you use a font to render this? I create an example for one byzantine musical note here: https://nsiklafidis.github.io/ but I use html, css and a font. Can you give me an example something like that for the musical note C?

[bwbohl]

1. The Tutorials render the notation using Verovio (https://www.verovio.org/index.xhtml).
2. What is the meaning of the ions character? That would be the first question to answer for all symbols, probably more than those e.g. on https://decodeunicode.org/en/u+1D000?

[bwbohl]

Do you know whether the https://decodeunicode.org/en/u+1D000 symbols are covered in the Standard Music Font Layout (SMuFL https://www.smufl.org)?

[rettinghaus]

@bwbohl Daniel doesn't want to duplicate those, see w3c/smufl#45.

[bwbohl]

@bwbohl Daniel doesn't want to duplicate those, see w3c/smufl#45.

thanks for adding, missed that one as I didn't look in the closed issues :-/

[nsiklafidis]

@bwbohl @rettinghaus
Thank you for your answers!
I agree, we have a unicode system for Byzantine Music.
So the only way to render Byzantine Music in MEI schema is to write with this unicode system?

[rettinghaus]

@nsiklafidis Yes, to render the music you should rely on the unicode system. However, it is unclear to me how this music should be encoded in MEI as I don't know enough about this kind of music.

[ahankinson]

I'm moving this to Discussions.

[t-bullock]

I think the current Neumes module in MEI is a good starting place for a Byzantine Notation structure. Here's my attempt at explaining the basic structure of the New Method (others can jump in and correct me).

• score
  • section
    • (byz notation doesn't use a staff, so no "staff" or "layer" elements?)
    • syllable
      • syl
      • neume
        • nc

Neumes in Byzantine Notation specify relative movements up or down from the previous pitch (rather than absolute pitches on a staff), so I guess we could use nc without pitch name or octave attributes. One thing we would need is the neume and neume component name. Unicode provides most neume component names for the New Method (1814). Would we create a new attribute for nc, like "name" or "nname"?

Neume components can also change the pitch in different ways depending on how they are positioned on the primary/base neume component. An ypsili (U+1D050) placed in the upper right is a jump up of 4 pitches, but placed in the upper left, it's a jump up of 5 pitches. Somehow we would need to specify nc position. Encoding Byzantine Notation suggests a grid.

There are also a few different types of neumes. Optical Recognition of Psaltic Byzantine Chant Notation suggests the following.

• Ordinary
• Martyria (indicates what the current pitch and scale should be. appears mid-score and at the end of a score. doesn't take a lyric)
• Chronagogic (tempo marking. doesn't take a lyric)

And types of neume components.

• Primary
• Secondary (combines with primary to affect pitch somehow)
  • Linking (usually qualitative. doesn't affect pitch)
  • Accidental (sharp, flat)
    • Fthora (placed on neume, changes scale)
    • Chronos (could be component of a chronagogic neume, or could be accidental for ordinary neume that changes the duration of a neume, ex: remove half beat from both current neume and previous neume)
• Martyria (component of a martyria neume)
• Rest

I'm only getting the discussion started for the New Method. Supporting notations before the New Method is much more complicated (we might need different types/categories of neumes and neume components), and I don't know much about it. I do know that we would need to come up with unique names for hundreds of other neumes that Unicode does not provide. @nsiklafidis would be the expert on what's needed for anything before the New Method. I'm not sure if older notations should be part of a different discussion or not.

[nsiklafidis]

@t-bullock
All these thoughts are very good.
But first of all we need to answer some questions:
What we need with the data of a MEI schema in Byzantine Notation? For example search musical phrases, or neumes. Also, production of Byzantine music scores in printed or electronic editions and others...
Trevor I agree that we need a demo schema to test if this can answer all our questions but first we need the goals.

[t-bullock]

I think the initial goal should be to represent a New Method Byzantine Music score in MEI, maybe through customizations. Our Kassia project does this already. It's missing some features, but it represents a basic score. But... a standard file format like MEI is better than a custom one. Once we have a standard way to represent scores, we'll have a standard way to represent a thesis or neume, and we could search for thesis or neumes across scores that are in a database. If we can find a way to use MEI to represent a Byz score, I would try to make changes to Kassia so it uses the new MEI file format, rather than our custom one. Then Kassia would be one option for people to generate PDF's of the music.

[ahankinson]

I thought I would write with some background on our thinking from the existing Western neumes module. It is possible that there are some ideas that are cross-compatible and useful!

(byz notation doesn't use a staff, so no "staff" or "layer" elements?)

There are also cases in Western neume notations where there is no visible staff -- the so-called "campo aperto" style. In MEI, the staff element is primarily a logical element that functions to group musical events in a progression. A "staff" doesn't need to have visible lines or absolute pitch values, so it can function as an invisible element for organizing progressions of musical events. Otherwise, you would need some other parent element, with basically the same purpose, to say that there is a linear progression of events -- making syllables child elements of section directly wouldn't really work, since <section> is designed as a higher-level document grouping function. You will probably also need to have other 'configuration' elements that set some global values in there, like <scoreDef>, etc.

(A tangential note that also might help illustrate the logical operation of staff: MEI makes a distinction between staff and systems -- a staff is a single unbroken continuous sequence of events. If you need to wrap it when rendering it to accommodate page margins, then you use the sb, or "system break" element to indicate this. In common language, 'system' and 'staff' are interchangeable, but in MEI they have specific and distinct meanings).

Likewise, layer indicates a performing instrument, including a human voice. Assuming that there is at least one instrumental voice in your repertoire, you would probably want to keep that as well.

Neumes in Byzantine Notation specify relative movements up or down from the previous pitch (rather than absolute pitches on a staff)
One thing we would need is the neume and neume component name

The previous version of the neume module used names almost exclusively to indicate the contour. What we found was that this made direct comparison of different notation traditions tricky, since some used different names for the same neume, and some notated the same tune with different neume shapes, depending on the repertoire. It also meant that anything named 'compound', or ones that had no pre-determined names, were a mish-mash of unrelated shapes. From the paper you linked, I suspect there would be similar problems in Byzantine repertoires: "The presented signs are many and they shape formulas that are not clearly defined and concrete." (§4)

In the current version of the MEI module, neumes are identified by their contour using the @intm values.

Names are still available, but it is suggested that you use the @type attribute. This is pre-populated with some Western names, but the attribute is an open list so you can provide other values as well. Another way you could do it is use the @class attribute and provide a fully qualified URI for classifying the shape somehow -- this would fit in better with Linked Data approaches, since you could develop an external authority for these shapes that could be shared and integrated into other projects.

Looking at some of your Kassia encodings, it's probably also worth pointing out a possible terminology divide. In MEI, <neume>s are equivalent to your <neume-group>, I believe, while <nc> is equivalent to <neume>. This is a bit of a legacy from the idea of a "compound neume" that could group "sub-neumes" on the same syllable. We decided to keep the idea that a neume is on a syllable, while the other shapes inside of that are "components" of that neume.

Somehow we would need to specify nc position. Encoding Byzantine Notation suggests a grid.

I would advise caution in encoding melodic function using visual positioning. It is tempting to do this -- it allows you to simply mark down what you see on the page without supplying any interpretation. But it also makes later interpretation of this as notation much harder, especially if you don't have access to the original appearance of the score. If you don't want to visually render the notation but instead analyze its pitch contents, for example, then you need to add extra logic to the software to interpret the visual encoding into some sort of musical effect, and the impact of this effect might not be immediately obvious to the software developer who is trying to interpret it, leading to diverging interpretations of the pitch content.

There are also a few different types of neumes.

Based on a cursory look at this, I would suggest that a distinction be made between "musical events" (those things which take time, and optionally pitch) and "control events" (those things which modify time and pitch, but have no time or pitch of their own). In the Western module, "neumes" and rests are specifically musical events. Elements such as clefs or time signatures are control events.

It seems to me, from a very basic look, that "Martyria" and "Chronagogic" shapes are control events? You might consider separating them from the "neumes" themselves and elevating them to their own elements, or possibly modifying existing control events, like <clef> and <meterSig> to accommodate the required behaviours. These are, of course, just suggestions, but they may help make any Byzantine notation encoding interoperable with other encoded repertoires.

As a general note, MEI provides enough flexibility to customize it to ensure we capture the essence of what makes a particular musical repertoire unique, BUT we we also want to make sure it uses enough of the well-understood mechanics of musical content so that repertoires can be made interoperable. In my opinion this is the greatest difficulty in designing any new module for different repertoires -- knowing where this line is! What we probably don't want is a completely custom notation format wrapped in an MEI shell.

(To be clear: I'm not saying this is at all what I see happening here! I just know from previous experience that it's easy to go too far down the customization rabbit-hole, so it's something to look out for as this progresses).

Many, many thanks for getting this discussion going! I look forward to seeing how it progresses!

[t-bullock]

This was really helpful. Thank you!