implement <annot> display

craigsapp commented 7 years ago

Rendering of <annot> data would be useful to have in verovio. This would function in a very similar manner to the current <harm> implementation, but both should add horizontal collision avoidance between adjacent <annot> and <harm> entries (similar to the current implementation of <verse>.

It would also be useful if @n were implemented for <annot> (and perhaps <harm>) which would stack annotations in a similar manner to <verse>; i.e., @n would handle vertical collision avoidance between separate streams of annotations.

Test data:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="3.0.0">
    <meiHead>
        <fileDesc>
            <titleStmt>
                <title />
            </titleStmt>
            <pubStmt>
                <date>2016-12-19 17:26:49</date>
            </pubStmt>
        </fileDesc>
        <encodingDesc>
            <projectDesc>
                <p>Transcoded from Humdrum with Verovio version 0.9.13-dev-1745ac2</p>
            </projectDesc>
        </encodingDesc>
    </meiHead>
    <music>
        <body>
            <mdiv>
                <score>
                    <scoreDef>
                        <staffGrp>
                            <staffDef clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5" />
                        </staffGrp>
                    </scoreDef>
                    <section>
                        <measure n="1">
                            <staff n="1">
                                <layer n="1">
                                    <note dur="4" oct="4" pname="c" accid.ges="n" />
                                    <note dur="4" oct="4" pname="d" accid.ges="n" />
                                    <note dur="4" oct="4" pname="e" accid.ges="n" />
                                    <note dur="4" oct="4" pname="f" accid.ges="n" />
                                </layer>
                            </staff>
                            <annot n="1" label="test"   staff="1" tstamp="1.000000">this</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="1.000000">0</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="2.000000">1</annot>
                            <annot n="1" label="test"   staff="1" tstamp="3.000000">is</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="3.000000">2</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="4.000000">3</annot>
                        </measure>
                        <measure n="2" right="end">
                            <staff n="1">
                                <layer n="1">
                                    <note dur="4" oct="4" pname="g" accid.ges="n" />
                                    <note dur="4" oct="4" pname="a" accid.ges="n" />
                                    <note dur="4" oct="4" pname="b" accid.ges="n" />
                                    <note dur="4" oct="5" pname="c" accid.ges="n" />
                                </layer>
                            </staff>
                            <annot n="1" label="test"   staff="1" tstamp="1.000000">a</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="1.000000">4</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="2.000000">5</annot>
                            <annot n="1" label="test"   staff="1" tstamp="3.000000">test</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="3.000000">6</annot>
                            <annot n="2" label="qstamp" staff="1" tstamp="4.000000">7</annot>
                        </measure>
                    </section>
                </score>
            </mdiv>
        </body>
    </music>
</mei>

Target rendering (placement above/below the staff could be similar to <verse> or <harm> with default above or below the staff).

Also see discussion for issue #388.

pe-ro commented 7 years ago

@kepper: I think you're right, I was just raising the question.

kepper commented 7 years ago

My impression is that we're actually all on the same page, and just fighting for words and how to deal with specific examples… ;-)

Am 21.12.2016 um 18:07 schrieb pe-ro notifications@github.com:

@kepper: I think you're right, I was just raising the question.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

pe-ro commented 7 years ago

Yes, I think so.

craigsapp commented 7 years ago

What should be done if @tstamp2 is absent?

If there is no @tstamp2, then the text should probably be be boundless, and keep going as long as there is text. System breaks should probably be allowed to break long text between systems (with a layout preference to avoid breaking a dir). Or dirs would automatically be bounded by a linebreak.

Here are two possible handlings of dirs which extend past the last measure on a line:

(A) poorly placed dir which the system layout system should try to avoid. If it cannot be avoided, then do one of two things: (B) Insert an automatic @tstamp2 to bound the dir to the end of the system. (C) split the dir and continue the overfull text onto the next system.

craigsapp commented 7 years ago

Here is my interpretation of examples of annotations:

The italic and outline styled text are not part of the music, and they are also outside of the layout considerations (I typeset the music first and then added the text annotations). The text is analytical, as it is marking structural aspects of the form, but seems to be in a different category from the initial example (where the relationship between the annotations needs to be preserved, such as verses in lyrics).

craigsapp commented 7 years ago

And here is a "manuscript" version of annotations:

http://www.willemmengelberg.nl/?q=discografie

pe-ro commented 7 years ago

@craigsapp: I like what you're suggesting because --

it maintains separation between <dir> (something part of the score) and <annot> (not part of the score, but "layered" on top),
the rendition can be essentially the same for both. The difference is whether the text is considered during the layout process (<dir>) or not (<annot>),
it gives the encoder control over when/how the text is drawn. If line breaks are present, they should be respected. But, I think we still need to work out what happens if there are line breaks without @tstamp2. Should the line breaks imply an @tstamp2 value at/just before the bar line? What happens if there's no bar line?

I agree with your assessment of extensive text --

It should continue into the following measure(s), and even across systems if necessary. (But, the text has to be associated with the same staff. It's not clear to me that your "C" example shows this. I'm looking at this as a 2-staff system, so the text should continue on to the 1st staff in the next system, even on to the next page if necessary.)
If there aren't any more measures/systems (i.e., this is the last measure), then a @tstamp2 value can be assumed in measured music; that is, it should be just before the bar line of the measure. Since time stamps ain't so useful in mensural notation, there has to be a different routine, somehow using @endid.

pe-ro commented 7 years ago

@craigsapp: Yep, those are annotations all right! 😀

pe-ro commented 7 years ago

Let me qualify that last statement -- some of those things are MEI annotations since <annot> at present only accommodates text (i.e., word-like) annotations. That is, the added dynamics, graphical signs, etc. aren't currently available. But, we might be able to extend the content model to allow at least some of them.

lpugin commented 7 years ago

Since time stamps ain't so useful in mensural notation, there has to be a different routine, somehow using @endid.

I agree. Mensural music should use exclusively @startid and @endid anyway and cannot reasonably rely on timestamps.

pe-ro commented 7 years ago

I don't know about you guys, but I feel like we've made a break through. From here on, it's just details. 😉

lpugin commented 7 years ago

Yes, this is good. If we do not want to make any distinction between annotations I think adding an attribute @visible would be good in order to make the distinction between something like, let's say, a conductor annotation, and an annotation of the encoding that is not expected to be rendered at all. Tools can decide if they shows them or not when @visible is not given.

pe-ro commented 7 years ago

@lpugin: Adding @visible sounds reasonable.

pe-ro commented 7 years ago

Circling back to address where <dir> can occur --

Here's a test file that allows <dir> inside <staff>. It shows all of the elements that can occur within <layer>, followed by all those that can occur in <staff>. <dir> has effectively been moved from <layer> to <staff>.

@lpugin: Is this what you had in mind? Note that this change is not backwards compatible, so should we allow <dir> in both places for the time being with deprecation in <layer> later, or just go all the way and break existing encodings and fix them in the next up-conversion stylesheet?

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="mensuralControlEventTest.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="mensuralControlEventTest.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<!--
  For this test, the cmn, neumes, cmnOrnaments, corpus, frbr, and performance modules are all inactive.
-->
<score xmlns="http://www.music-encoding.org/ns/mei" xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <scoreDef>
    <staffGrp barthru="true" symbol="line">
      <staffDef xml:id="P1" n="1" clef.shape="G" clef.line="2" lines="5">
        <label>Superius</label>
      </staffDef>
    </staffGrp>
  </scoreDef>
  <section>
    <staff n="1">      
      <layer>
        <!-- elements allowed in <layer> -->
        <accid/>
        <add/>
        <anchoredText/>
        <annot/>
        <app>
          <rdg/>
        </app>
        <artic/>
        <barLine/>
        <choice/>
        <chord/>
        <clef/>
        <clefGrp>
          <clef/>
        </clefGrp>
        <corr/>
        <curve/>
        <custos/>
        <damage/>
        <del/>
        <!-- <dir> is no longer allowed in <layer> -->
        <!-- startid and endid have bogus value just to satisfy the need for one -->
        <!--<dir startid="#P1" endid="#P1">
          <rend fontstyle="normal">
            <choice>
              <orig xml:lang="ru">Между тем пионер Петя, который остался<lb/>стоять за запертой
                калиткой и видел всё<lb/> происходящее, нисколько не испугался.</orig>
              <reg xml:lang="en">"Meanwhile pioneer Peter, who stood behind a locked gate and saw
                everything that happened, was not at all frightened."</reg>
            </choice>
          </rend>
        </dir>-->      
        <div/>
        <dot/>
        <gap/>
        <handShift/>
        <keySig/>
        <ligature/>
        <line startid="#P1" endid="#P1"/>
        <lyrics>
          <verse>
            <syl/>
          </verse>
        </lyrics>
        <mensur/>
        <note/>
        <orig/>
        <pad num="0"/>
        <pb/>
        <proport/>
        <reg/>
        <rest/>
        <restore/>
        <sb/>
        <scoreDef/>
        <sic/>
        <space/>
        <staffDef/>
        <subst>
          <del/>
          <add/>
        </subst>
        <supplied/>
        <unclear/>
      </layer>

      <!-- elements (in addition to <layer>) allowed in <staff> -->
      <add/>
      <annot/>
      <app>
        <rdg/>
      </app>
      <choice/>
      <corr/>
      <damage/>
      <del/>
      <!-- <dir> is now allowed within <staff> -->
      <!-- startid and endid have bogus value just to satisfy the need for one -->
      <dir startid="#P1" endid="#P1">
        <rend fontstyle="normal">
          <choice>
            <orig xml:lang="ru">Между тем пионер Петя, который остался<lb/>стоять за запертой
              калиткой и видел всё<lb/> происходящее, нисколько не испугался.</orig>
            <reg xml:lang="en">"Meanwhile pioneer Peter, who stood behind a locked gate and saw
              everything that happened, was not at all frightened."</reg>
          </choice>
        </rend>
      </dir>
      <div/>
      <gap/>
      <handShift/>
      <orig/>
      <pb/>
      <reg/>
      <restore/>
      <sb/>
      <scoreDef/>
      <sic/>
      <staffDef/>
      <subst>
        <del/>
        <add/>
      </subst>
      <supplied/>
      <unclear/>
    </staff>
  </section>
</score>

pe-ro commented 7 years ago

More details 😀 --

If <dir> is for those things that are part of the score and <annot> is for stuff "on top" of the score, then <div> can be removed in "score context" (ending, layer, measure, part, score, section, staff, and syllable) and retained in "text context" (back, div, front, history, lem, and rdg), correct?

Also, <annot> should have the same model as <dir>; that is, --

<rng:zeroOrMore>
  <rng:choice>
    <rng:text/>
    <rng:ref name="model.textPhraseLike.limited"/>
    <rng:ref name="model.graphicPrimitiveLike"/>
    <rng:ref name="model.editLike"/>
    <rng:ref name="model.transcriptionLike"/>
  </rng:choice>
</rng:zeroOrMore>

which permits text and in-line markup, where in-line markup includes editorial and transcriptional elements when those modules are activated. Lines and curves are also included, but I'm wondering if we should suppress those now. SMuFL-defined items can be included via <symbol>.

With the original purpose of <div> now subsumed into <dir>, I propose to add a <commentary> (or other suitably named) element to capture textual comments. This element will have the same content model as <div> and will permit the encoder to capture commentary at or near the place where said thing occurs. This commentary is not intended to be rendered by Verovio at this time. Other software, however, may want to take the opposite approach; that is, render it instead of the notation, perhaps making it part of the front or back matter of an edition via a generic referencing/copying mechanism.

Sound like a plan?

donbyrd commented 7 years ago

Re fonts: I couldn't find anything useful in Read's Music Notation, 2nd edition -- no surprise; it's so much less complete and less well organized than Gould's Behind Bars. But, as I said before, page 492 of Gould goes into quite some detail; she begins "[R]oman type is used for player allocation, instrument changes, and technical instructions, with bold roman for tempi; italic type is used for expression marks, with stylised bold italics for dynamics." She goes on to list some exceptions and to discuss general principles, but she doesn't mention Times Roman or any other specific font. (Times Roman didn't exist until around 1930, so it certainly wasn't the standard font when CMN was getting standardized!)

The examples of tempo indications on p. 183 of Gould are all in bold roman; they include "accel." and "allarg.", so it's clear how broadly she agrees with @pe-ro that "anything affecting speed/time is appropriate for ". To double-check, I just looked at six random scores on my shelf: works by Bartok (Boosey & Hawkes edition), Bartok (Universal), Beethoven (Eulenberg), Beethoven (Philharmonia), Dvorak (Kalmus; I'd guess a reprint from Simrock), and Rimsky-Korsakov (Belaieff). All of them print relative tempo changes as well as standard tempo marks in the same bold roman font, except the Bartok/Universal edition, which prints both in the same bold italic font. So @pe-ro seems to be correct. The degree of consistency surprises me; I would have guessed that 19th century editions would often use different fonts for relative and "absolute" tempo marks, but I think at least half the scores I looked at are 19th century editions.

As for dynamics, all of the scores I looked at use italic for "cresc.", "diminuendo", etc., as well as "ff", "mp", etc., though the former type of dynamics aren't in the "stylized" font. So again @pe-ro is correct, and agrees with Gould.

And re technical instructions, I didn't look as closely, but everyone seems to use regular roman, as Gould says.

Finally, she gives an example of an expression mark, "dolce e...", and it's in italic.

kepper commented 7 years ago

Am 21.12.2016 um 22:25 schrieb pe-ro notifications@github.com:

Sound like a plan?

Sort of. However, I start to feel a little bit antsy. We're discussing this in an issue of Verovio, but I believe these changes are so drastic that we really need to have this discussion on MEI-L instead!

donbyrd commented 7 years ago

I agree with @kepper; we should discuss on MEI-L. Otherwise, it sounds like a plan!

pe-ro commented 7 years ago

@kepper: Ok, will you summarize the discussion here on MEI-L and solicit additional input? Thanks, honey. 😀

donbyrd commented 7 years ago

W/r/t fonts: As @pe-ro says, this is minor; encoding semantics is the thing. Still, to round out earlier comments: I noticed that one of @craigsapp's examples from the Chopin Etudes Op. 25 has "a tempo" in non-bold italics instead of roman bold. Following that up, I looked at my copy of the Chopin Preludes and Etudes, Paderewski edition. Tempo-related markings like "a tempo", "accel.", and "retin." are always in non-bold italics in the Preludes, Etudes Op. 10, and Etudes Op. 25.

craigsapp commented 7 years ago

@pe-ro said:

It's not clear to me that your "C" example shows this. I'm looking at this as a 2-staff system, so the text should continue on to the 1st staff in the next system, even on to the next page if necessary.)

That was a single-staff system, so it behaves as you are thinking.

pe-ro commented 7 years ago

@craigsapp, Great!

donbyrd commented 7 years ago

Say, there's been a fair amount of discussion of <dir> etc. on the mensural-ig list recently. But this topic is certainly not relevant only to mensural music; shouldn't it be moved to MEI-L?

rism-digital / verovio

implement <annot> display #389