[MEI-L] Annotations visible on the music and arbitrary segmentation
Byrd, Donald A.
donbyrd at indiana.edu
Sat Mar 4 01:36:36 CET 2017
For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for <harm>"), and especially 389 ("implement <annot> display"). You can read #389 at
https://github.com/rism-ch/verovio/issues/389
and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here.
We've talked about using one of two existing tags for these annotations, namely <dir> and <annot>. It seems clear that <dir> is not what we want because it's specifically intended for performance directions. As for <annot>s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to <annot>, but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible <annot>s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want.
Giuliano has raised a related concern. He wrote yesterday that
"[N]ot only something like <dir> for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...).
"If I understand correctly, most of the problem with <dir> originates from the missing <measure> level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag <segment> at that level could be useful. The latter, contrary to <measure> would be totally optional, and contrary to <measure> or <section> would be used without any structural meaning.
"This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it <seg> when the portion of text is shorter than a paragraph, and <ab> when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a <seg>-like tag available at any level."
Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them.
I'm looking forward to hearing people's thoughts on all of this!
--Don
---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington
More information about the mei-l
mailing list