search

rism-digital / verovio

🎵 Music notation engraving library for MEI with MusicXML and Humdrum support and various toolkits (JavaScript, Python)
https://www.verovio.org
GNU Lesser General Public License v3.0
681 stars 185 forks source link

implement <annot> display #389

Closed craigsapp closed 7 years ago

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).

screen shot 2016-12-19 at 17 45 03

Also see discussion for issue #388.

donbyrd commented 7 years ago

I'd love to see Verovio rendering <annot>s! I've been using <syl> to label things in mensural notation tests; aside from making no sense, it screws up horizontal spacing. <dir> would be better, but it's not implemented for mensural staves and Laurent tells me it'd be difficult to implement it. But what I really want is an annotation visible in the graphic output, not just the MEI file -- and I'll bet Craig and I aren't the only customers for this feature. I'll remove the "low priority" label from this issue.

craigsapp commented 7 years ago

+1 :-)

lpugin commented 7 years ago

I am confused with annotation. It is not clear to me that they actually have to be rendered. In the guidelines, (http://music-encoding.org/documentation/3.0.0/shared/#sharedAnnotations) it reads:

In all cases, annot provides a comment upon a feature of the encoding, but never contains textual transcription.

The guidelines also say:

it [annotation] may lead to markup that cannot be effectively processed mechanistically.

So they can happen more or less everywhere, so rendering them as harm seems to be a very specific approach

lpugin commented 7 years ago

Reading this confirms that we need to wait until it is clarified in MEI

kepper commented 7 years ago

I'm more than reluctant to follow. What is an annotation, and how should it look like? Are we really able to define that once and forever? Considering the simplicity of interacting with Verovio output in Javascript, I'd rather not unify this, but leave it to something later in the chain. Admittedly, this doesn't allow to consider the required space when doing the layout of the score, but if that is the top priority, it should be fairly easy to convert <annot>s into other markup that is considered as static content of the score (like <harm> or some other suggestions from this thread) during runtime. Otherwise, Verovio would effectively kill the possibility of dynamic annotations – one of its best features.

lpugin commented 7 years ago

One more note: annot are actually already taken into account by Verovio. They are treated as the editorial markup and allowed more or less anywhere. In the SVG output they are given as empty <g class="annot"/> and as always the id is provided to access them. So JavaScript / CSS can indeed be used to display them as desired.

pe-ro commented 7 years ago

Taking a "wait-and-see" or "phased-implementation" approach to <annot> is fine with me.

One question, though:

Do all <annot> elements end up in the SVG as empty, even when the annotation has textual content? For example, what happens to --

<annot startid="#n1" plist="#n1 #n2 #n3">These 3 notes are special.</annot>

It seems to me that annotations with textual content can be treated in the same way as <dir>. An annotation could also be handled the same way as a <div>; that is, as a textual block between systems.

lpugin commented 7 years ago

<annot startid="#n1" plist="#n1 #n2 #n3">These 3 notes are special.</annot>

Remains empty. <g>These 3 notes are special.</g> is not valid SVG. You would need to add a <text> element, and this would make sense only with positioning, wouldn't it? (Otherwise they will not show up). And here is this issue: since <annot> is allowed more or less anywhere (including in the header) it is not clear to me how they can be laid out and how they they can be represented. Handling them as <dir> sounds like a very specific type of annotation, so why not use <dir> in the first place?

I understand them as annotations to the encoding (more some sort of analytical data) and I would not expect them to be laid out and rendered by Verovio. At least until we agree on what the are (and are not) and how they should look like.

donbyrd commented 7 years ago

As I understand it, <dir> is intended for directions to performers; that clearly isn't what Craig and I are talking about. Still, I'd use <dir>, but, as I said, it isn't implemented for mensural staves and there seems to be no prospect it will be any time soon. I don't suppose we could agree on something like <annot pos="above"...>? An attribute like "pos" would obviously be intended to be visible in the SVG.

lpugin commented 7 years ago

I precisely want to avoid to implement things before they are clear in MEI because it should not be the implementation that sets them. For <dir> in mensural notation, the issue is also that MEI needs to be clarified and quite likely adjusted because they are not allowed in <staff> where I think they should be. Then of course they will not implement themselves automatically ;-)

pe-ro commented 7 years ago

I see your point. The reason for not encoding them as directives in the first place is that <dir> is intended to be transcriptional; that is, it contains text that appears on the score being encoded. If this is a born-digital score, then the "annotations" aren't really annotations, they're "directives". On the other hand, if the encoding represents an existing, probably non-digital score, then the annotations are "comments" on the score and should be handled separately from directives that were part of the original. They're very much like editorial markup which may be rendered or not depending on the needs of the encoder/consumer of the edition.

A quick comparison of the attributes of <annot> and <dir> shows that they mostly share attributes in the logical, analytical, and gestural domains. <annot>, however, lacks all of the visual domain attributes of <dir>. If these were allowed, then <annot> elements with these attributes could be rendered the same way as <dir>s, while maintaining the semantic difference between them. In addition, it might be helpful to add a @visible attribute to both elements to allow quick toggling between visible and invisible states.

pe-ro commented 7 years ago

@lpugin, It's true that <dir> isn't allowed directly within <staff>, but it is allowed within <layer>. Can you say why this isn't sufficient for implementing <dir> in mensural notation?

lpugin commented 7 years ago

See this one https://github.com/rism-ch/verovio/issues/248

kepper commented 7 years ago

I would argue that when Craig and Don need annotations to behave like

, why don't you convert your to during runtime, just for displaying it with Verovio. I wholeheartedly agree that Verovio should not try to define what an annotation is or looks like. I also think that a reference to a
as a block of text between systems isn't particularly helpful when thinking about a continuous staff… The way annotations need to be displayed is always project-specific and shouldn't be standardized, which in this case means restricted to a specific perspective…

Am 20.12.2016 um 17:37 schrieb pe-ro notifications@github.com:

I see your point. The reason for not encoding them as directives in the first place is that

is intended to be transcriptional; that is, it contains text that appears on the score being encoded. If this is a born-digital score, then the "annotations" aren't really annotations, they're "directives". On the other hand, if the encoding represents an existing, probably non-digital score, then the annotations are "comments" on the score and should be handled separately from directives that were part of the original. They're very much like editorial markup which may be rendered or not depending on the needs of the encoder/consumer of the edition.

A quick comparison of the attributes of and

shows that they mostly share attributes in the logical, analytical, and gestural domains. , however, lacks all of the visual domain attributes of . If these were allowed, then elements with these attributes could be rendered the same way as s, while maintaining the semantic difference between them. In addition, it might be helpful to add a @visible attribute to both elements to allow quick toggling between visible and invisible states.

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

craigsapp commented 7 years ago

Then of course they will not implement themselves automatically ;-)

I always thought they were done by the implementation fairy :-)

I would argue that when Craig and Don need annotations to behave like

, why don't you convert your to during runtime, just for displaying it with Verovio.

That would be possible. <harm> still seems closer and would work fine with the addition of @n for vertical offsets, but I will have to test <dir> as i was not thinking of that. One problem: can the font be set for dir? I do not want to display the analytic data in italic. A secondary but general problem which occurs in dirs near linebreaks where the text goes off the side of the page:

screen shot 2016-12-20 at 10 52 45

And another thing I will have to study is how multiple dirs behave at the same timepoint (and can they be positioned with @n for example).

donbyrd commented 7 years ago

@pe-ro , you say 'If this is a born-digital score, then the "annotations" aren't really annotations, they're "directives". On the other hand, if the encoding represents an existing, probably non-digital score, then the annotations are "comments" on the score...' But I'm talking about a born-digital score -- one intended for demonstration purposes, not real music, so admittedly unusual -- in which the "annotations" I want really are annotations, not directives.

@kepper, yet again, since <dir> isn't implemented for mensural staves, converting <annot> to <dir> wouldn't help me.

lpugin commented 7 years ago

I think support for for @n on harm makes sense. We should actually think about support of @n on control events more generally.

@craigsapp system breaks is also a general issue to consider not only for dir but also for tempo, for example. One way to look at it is to check if we have any of these overlapping measures (in terms for rendering) and then avoid system breaks to happen there. (Breaking them nicely could be another approach but certainly more complicated)

Font: you can change it with rend. Something like

<dir><rend fontstyle="normal">Your directive</rend></dir>
lpugin commented 7 years ago

@donbyrd rendering annot as dir is really a shortcut for me. This works but only of a very specific type of annotation (e.g., the ones that are equivalent to directives). What about the others?

I would rather do something like:

<supplied reason="documentation"><dir>mensural black</dir></supplied>
pe-ro commented 7 years ago

Thanks, I'd forgotten about that. (#248, that is.)

The main reason they're in <layer> is to isolate them; that is, to have them be in one place in CMN and another in Mensural notation. Re-reading my own statements, I think what I meant was that they can be allowed within <staff> (instead of <layer>) in Mensural notation and remain in <measure> in CMN, but I'll have to verify this. Of course, they will be available in both places when mei-all is used. The solution there remains the same: Use mei-all very sparingly. :-)

pe-ro commented 7 years ago

I would rather do something like:

mensural black

That's going to be a hard-sell for lots of folks. If it helps, think of 

<annot>mensural black</annot>

as syntactic sugar for

<supplied reason="documentation"><dir>mensural black</dir></supplied>

😀

lpugin commented 7 years ago

Yes, I can understand this. But then, what would you expect to see with something like this

<section>
    <annot startid="#m1" endid="#m20">The exposition goes from measure 1 to 25</annot>
    <measure n="1" xml:id="m1">
        <!-- ... --->
    </measure>
    <!-- ... --->
</section>

or this

<note>
    <verse>
        <syl><annot>What is this?</annot>The</syl>
    </verse>
</note>
pe-ro commented 7 years ago

@kepper, there's nothing necessarily problematic about treating a <div> as a "block between systems" in the context of a continuous system. But it does require re-thinking what the so-called "continuous system" consists of. (And perhaps instead of "block between systems", I should have said "block above/below systems".)

In my view, a "continuous system" consists of a single system, made up of several "staves", where "staff" denotes a stream of events. It's made up of streams of events; not just the traditional staves with ruled lines, but also "staves" of text accompanying the lined-ones. Conceptually, one can think of <tempo>, <dir>, <harm>, and even <div> and <annot> as "staves". It's just that these are discontinuous staves, so the best way to say where they appear and what's on them is to provide their information relative to the lined staves. These "staves" have vertical size, in much the same way that a traditional staff has. The difference is that sometimes the "events" on these "staves" get compressed horizontally and so grow vertically. For instance, text written above a measure, unlike the measure itself, will grow in height when it's given horizontal limitations, in spite of whether it's a <dir>, <div> or <annot>.

Most text blocks will occur above or below the lined staves, but it's possible to imagine text blocks between staves. I think we're getting close to that in the discussion of dynamics that occur between staves and are associated with both staves. What if, instead of a string like "mf", the dynamic was a 103-character string? One option would be to allow that string to continue "to the right" until it was completely displayed. Another would be to find places where it could be broken into lines, and extra space created between the staves to fit those lines of text. What differentiates these two possibilities is the setting of the right-side boundary of the text. If there's no boundary or the boundary exists far to the "right", then the text can be rendered on a single line. If the boundary is the right bar line, then the text either has to be truncated there, or wrapped around. With <dir> one can set the left and right boundaries with @tstamp and @tstamp2. Why not allow the same with <annot>?

pe-ro commented 7 years ago

@lpugin, for your first example, I would expect to see the string "The exposition goes from measure 1 to 25" "left justified" starting at the left edge of measure 1. I wouldn't expect to see the second example at all because no data has been provided for rendering it.

lpugin commented 7 years ago

What to you mean by data for rendering it? A @startid?

<note>
    <verse>
        <syl xml:id="s"><annot startid="#s">What is this?</annot>The</syl>
    </verse>
</note>
pe-ro commented 7 years ago

@startid is a good start (no pun intended), but it probably should point to an event, like a note, chord, or rest, maybe a bar line; in other words, a "timed event". <syl> isn't a timed event because it gets its time/location from its parent note. If @startid doesn't point to a timed event, then Verovio shouldn't be required to render the annotation. The same kind of "rules" could be made with regard to other info, like @staff, @place, etc. This way, annotations can be loosy-goosy as Jo suggests, but Verovio can impose its limitations.

craigsapp commented 7 years ago

@craigsapp system breaks is also a general issue to consider not only for dir but also for tempo, for example. One way to look at it is to check if we have any of these overlapping measures (in terms for rendering) and then avoid system breaks to happen there. (Breaking them nicely could be another approach but certainly more complicated)

Yes, it would need an elaboration on the system breaking algorithm to identify cases where text wants to flow to the next measure. The MuseData system has some compensation for these cases: system breaks can be forbidden at certain barlines, and I think there is a "discourage" linebreak option for layout control (and of course forcing a linebreak at a specfic measure). It will work better for longer piece, but the constraints might fail on short pieces, or piece where there are too many text overlaps between measures.

It is a problem for tempos, but these are often only at the start of a movement and therefor system, so they cause problems less often.

Font: you can change it with rend. Something like

<dir><rend fontstyle="normal">Your directive</rend></dir>

Thanks, that is working for me:

screen shot 2016-12-20 at 2 31 52 pm

It is funny that a fontstyle of "normal" is not the default ("italic" is). Who defines "italic" as the default font? Verovio or MIE?

craigsapp commented 7 years ago

Related to blocks (maybe in a different context), how would paragraph-style directives (or whatever they should be called) be encoded? Such as the spoken text below the whole-measure rest in this example from Peter and the Wolf by Prokofiev?:

screen shot 2016-12-20 at 2 23 33 pm

This is spoken text so similar to <verse> in once sense, but treated more as a multi-line performance directive.

pe-ro commented 7 years ago

I'm pretty sure style manuals (Ross, Gould, Schirmer) recommend that the default font and style for <dir> (and other non-notation text) should be unadorned Times Roman. For <dynam>; however, the default style should be italic.

<div> is allowed with certain music elements expressly for the purpose of handling text blocks that are neither directives nor annotations, such as the spoken text here in Peter and the Wolf. The visual rendering of <div> (in the music notation context) and <annot> should be the same; it's the semantics that's different.

That being said, one could always "cheat" and encode each line of the spoken text as a <dir> and position them to get the rendered effect. Not supporting <div> and <annot> will encourage this undesirable behavior.

craigsapp commented 7 years ago

That being said, one could always "cheat" and encode each line of the spoken text as a

and position them to get the rendered effect. Not supporting
and will encourage this undesirable behavior.

Would the proper way be to give a duration to the dir? This would force the text to line-wrap at that duration point. It would be something like @tstamp="3" and @dur=2+1m?

<dir tstamp="3" dur="2+1m"><rend fontstyle="normal">Между тем пионер Петя, 
который остался стоять за запертой калиткой и видел всё происходящее, нисколько 
не испугался.</rend></dir>

In addition to hacking to three separate <dirs> could linebreaks be encoded inside the dir (a bit dangerous for flexible layouts though)?

<dir tstamp="3" dur="2+1m"><rend fontstyle="normal">Между тем пионер Петя, 
который остался<br/> стоять за запертой калиткой и видел всё<br/>
происходящее, нисколько не испугался.</rend></dir>

How would translations be given for this sort of case, where the English is approximately:

"Meanwhile pioneer Peter, who stood behind a locked gate and saw everything that happened, was not at all frightened."

Perhaps with app lemma/reading, or is this a choice?

donbyrd commented 7 years ago

I see the discussion has been intense over the last six or eight hours! I won't try to comment on everything, but re <dir>, Sec. 1.2.5.1 of the 3.0.0 Guidelines says "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." So it would seem that using <dir> for my purposes and some of Craig's purposes, as people keep suggesting, is not kosher. Maybe that's not a big deal, but, as I've said three times before in this thread, <dir> isn't implemented for mensural staves, and it's not obvious that it will be any time soon; that's a big deal.

donbyrd commented 7 years ago

@pe-ro said that "the default font and style for <dir> (and other non-notation text) should be unadorned Times Roman. For <dynam>, however, the default style should be italic". But things aren't so simple. 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.

craigsapp commented 7 years ago

Sec. 1.2.5.1 of the 3.0.0 Guidelines says "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."

I would infer <dir> then to mean specifically textual directions that are visual in the score intended as instructions for the performer. In my case I want something which is not performance based, but primarily analytic based text, such as <harm> currently being the most similar, or also basso continuo. This sort of text is not typically displayed in performance scores, since it is not for use in performance.

Storing it in a similar manner to <recording> data is also interesting.

lpugin commented 7 years ago

I am still not convinced at all. When I think of an annotation, I think of something that is added on top of an object. Typically, for a music score, conductor annotations would be a good example. It is added on top of the score and it does not change it. In a digital environment, we can think of something like a comment in MS Word that gets displayed on the side. In digital scores they are also examples of tool offering annotations, where additional symbols can be displayed on top of the score. But here too they do not change the original (layout) of the score.

This is why treating some annot as dir is wrong to me. If <supplied><dir></supplied> or <dir type="annotated-by-myself"/> is not acceptable, then I would suggest to add another element or another attribute to make a clear distinction between directives that are original and the one added. (However for me this would duplicate the editorial markup we have.)

Now it seems that annot are also thought as something added on top of the encoding. Hence their presence in the header, outside measures, and so on. We can see them as encoding annotation. In any case, if they need to be visualised, which is probably debatable and will vary from one project to another, they reinforce the idea that annot cannot be integrated in the rendering of the content but instead should be rendered on top of it. In their case I think we also need further thinking because a control event in header or a control event outside a measure does not make much sense. (If I have a @tstamp outside a measure, where does it point to?)

So as @pe-ro said, we probably need work on it. Maybe one direction is to make a distinction between encoding annotation and source (content) annotation?

lpugin commented 7 years ago

@craigsapp

Who defines "italic" as the default font? [for dir]

Verovio

lpugin commented 7 years ago

BTW, there is documentation about it there http://www.verovio.org/features.xhtml?id=tempi-directives It reads:

"By default, tempi indications are rendered in bold. This can be modified by including a <rend> element in the text. It is also possible to have nested <rend> elements. [...] By default, directive indications are placed below the staff and are rendered in italic. [...] Typographic formatting within directive elements is supported as with tempi (see above)."

pe-ro commented 7 years ago

@craigsapp, First, I want to make sure we're talking about the same thing -- For the P&TW text I suggested the <div> element (that's D-I-V), not <dir> (D-I-R). Even so, the rendering options for these things should be the same. Same rendering, different semantics.

Here's one possible encoding of the text block --

<div>
  <p>
    <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>
  </p>
</div>

<div> captures the block of text, and <choice> indicates the choice between Russian and English. <orig> is used for the original text and <reg> for the English, as translation is a kind of "regularization". Line breaks are encoded in the Russian using <lb/>, not <br/> since that's HTML. :-)

Right now, <div> doesn't allow time-related attributes, but if it did then it would look similar to the following (just exchanging <div> for <dir> and adding @tstamp and @tstamp2) --

<dir tstamp="3" tstamp2="1m+4">
  <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>
pe-ro commented 7 years ago

@donbyrd, Ok, Roman, not Times Roman.

pe-ro commented 7 years ago

@lpugin, It's fine for dynamics to be italicized by default, but directives should be plain Roman text.

pe-ro commented 7 years ago

@lpugin makes a good argument for not rendering annotations, or if they are, then placing them "on top" of an already-laid out score. But, I'm not yet ready to embrace <supplied><dir>...</dir><supplied> because it can't make a distinction between performance directions originally in the score, performance directions added by an editor, and "real" annotations, which are always added by an editor and don't function as "performance directions". I read the <supplied> example markup as a performance direction that is supplied by the editor (perhaps because it's in all the other parts, but missing in this one). So, we may need a different element after all.

Having just marked up the P&TW example, I'm now realizing that <div> isn't a good choice either. In this case, confusion is created between a block of text in running prose (where <div> is fine) and a block of text appearing in a score. Again, I think we need a different element, since <div> comes with a lot of extra "baggage"; that is, it requires text component children, such as <p>, <list>, etc. This is fine in prose, but not good for "score text". I believe <dir> has the right content model (it doesn't allow text components), but it's semantics don't match with capturing a block of text in the score.

There is another text-y element (<anchoredText>), but it doesn't fit well either, since it's intended to capture page-anchored text; that is, text that keeps its page position regardless of any changes made to the lay out of the score. Honestly, I don't see it being very useful -- it was added for conformance with other markup systems, mostly Mup, but also my (flawed?) understanding of MusicXML. I think we can ignore it for now.

This is certainly a lot to untangle, and it will have far-reaching consequences. For example, <annot> is used to capture annotations generically (functioning as the equivalent of the TEI <note> element). So, it appears in the header and in body of MEI. Obviously, those in the header are meant to be rendered (in catalogs, for instance). But, if we decide those in the body should not be rendered, it will create inconsistency. One or the other (annotations in the header vs those in the body) will have to get a new name.

craigsapp commented 7 years ago

@lpugin, It's fine for dynamics to be italicized by default, but directives should be plain Roman text.

Are these all directives (from Chopin Etudes op 25)?:

http://conquest.imslp.info/files/imglnks/usimg/a/ad/IMSLP112921-PMLP01970-FChopin_Etudes__Op.25_Scholtz.pdf

screen shot 2016-12-21 at 06 37 31 screen shot 2016-12-21 at 06 37 54 screen shot 2016-12-21 at 06 38 00 screen shot 2016-12-21 at 06 38 17 screen shot 2016-12-21 at 06 38 25 screen shot 2016-12-21 at 06 38 30 screen shot 2016-12-21 at 06 38 39 screen shot 2016-12-21 at 06 38 48

They seem to be <dir> but they always are in italics.

From Schoenberg's Verklerte Nacht: http://ks.imslp.net/files/imglnks/usimg/8/8f/IMSLP03938-Sch__nberg_Verkl__rte_Nacht_for_String_Sextett2.pdf

Two categories of directives can be seen. With italic for more musical directives (what should be conveyed through the performance), and roman for perhaps more technical directives (what should be done to accomplish the performance).

screen shot 2016-12-21 at 06 49 22 screen shot 2016-12-21 at 06 49 35 screen shot 2016-12-21 at 06 49 49 screen shot 2016-12-21 at 06 50 25 screen shot 2016-12-21 at 06 50 46 screen shot 2016-12-21 at 06 51 14 screen shot 2016-12-21 at 06 52 07 screen shot 2016-12-21 at 06 52 15 screen shot 2016-12-21 at 06 53 05 screen shot 2016-12-21 at 06 53 48 screen shot 2016-12-21 at 06 54 04 screen shot 2016-12-21 at 06 54 15 screen shot 2016-12-21 at 06 54 24 screen shot 2016-12-21 at 06 54 42 screen shot 2016-12-21 at 06 54 53 screen shot 2016-12-21 at 06 55 12 screen shot 2016-12-21 at 06 56 13

Can the cases of roman and italic directives be semantically separated into categories which have an obvious default typeface? Then assigning a default typeface is less of a problem. If verovio specifies the default, then I would have to be more explicit in my converter from Humdrum to MEI to ensure similar rendering in other (hypothetical) typesetting programs.

pe-ro commented 7 years ago

Can anything in music notation be "semantically separated into categories which have an obvious default typeface"? 😀 I don't think so. But <dir> is intended for what you're calling "technical" directives (where the default should be Roman). Your items in category "musical" directives, e.g., "poco a poco cresc." and "a tempo" are better marked as either <dynam> or <tempo> (where the default should be italics). The remaining uncategorized markings can be either, and the encoder has to indicate the proper font style. Like dynamics and tempo markings, fingerings have their own element, <fing>, but a default style is not as easily discernable.

pe-ro commented 7 years ago

In any case, what's important is the semantic markup, not the typeface.

craigsapp commented 7 years ago

Having just marked up the P&TW example, I'm now realizing that

isn't a good choice either. In this case, confusion is created between a block of text in running prose (where
is fine) and a block of text appearing in a score. Again, I think we need a different element, since
comes with a lot of extra "baggage"; that is, it requires text component children, such as

, , etc. This is fine in prose, but not good for "score text". I believe

has the right content model (it doesn't allow text components), but it's semantics don't match with capturing a block of text in the score.

There is another text-y element (), but it doesn't fit well either, since it's intended to capture page-anchored text; that is, text that keeps its page position regardless of any changes made to the lay out of the score. Honestly, I don't see it being very useful -- it was added for conformance with other markup systems, mostly Mup, but also my (flawed?) understanding of MusicXML. I think we can ignore it for now.

Would @dur given to a <dir> not be a good way to force a text block (or @startid/@endid), along with @tstamp it would form the left/right boundaries of a box. The height of the box would be defined by how much text is to placed:

screen shot 2016-12-21 at 07 40 33

Text boxes below the staff would extend downwards to fill their contents; text boxes above the staff would extend upwards to fill their contents.

craigsapp commented 7 years ago

Your items in category "musical" directives, e.g., "poco a poco cresc." and "a tempo" are better marked as either <dynam> or <tempo> (where the default should be italics).

OK, I have been not paying much attention to those yet, and thinking along the lines that <dynam> is mostly reserved for the symbols such as "f" or "mp".

For <tempo> there is usually a big rendering difference between "a tempo" and "Lento". Are these both <tempo> elements?

What would dolce be categorized under? It is always italic but is that a dynamic or a tempo or something other than a <dir>? Then there would be the word agogically which would mean play with temporal accents...

pe-ro commented 7 years ago

@craigsapp: In MEI, @dur captures the written duration of a notational symbol, e.g., <note dur="4"/>. Other things use @dur.ges or @tstamp2. Since gestural duration doesn't make much sense, @tstamp2 is the right approach. And it forms nice a pair with @tstamp. 😄

pe-ro commented 7 years ago

OK, I have been not paying much attention to those yet, and thinking along the lines that <dynam> is mostly reserved for the symbols such as "f" or "mp".

In my mind, anything affecting volume is a dynamic.

For <tempo> there is usually a big rendering difference between "a tempo" and "Lento". Are these both <tempo> elements?

And anything affecting speed/time is appropriate for <tempo>.

What would dolce be categorized under? It is always italic but is that a dynamic or a tempo or something other than a <dir>? Then there would be the word agogically which would mean play with temporal accents...

These defy categorization and so, like the Guidelines say, should go into a more generic "bin"; that is, <dir>, whose default rendering, I contend, should be Roman. If that's not what's needed, then use <rend> to change their appearance.

pe-ro commented 7 years ago

@craigsapp: Even if "a tempo" and "Lento" are both marked using <tempo>, their visual appearance can be controlled using <rend>. Again, the idea is to mark semantic categories of things, not visual categories.

pe-ro commented 7 years ago

That being said, there's never going to be total agreement about the classification of these things. We can only offer the "bins" -- it's up to encoders to use them appropriately. And even "appropriately" might mean different things to different people.

The only "absolute" approach would be to not differentiate the various kinds of text at all, and just allow for controlling the visual rendition. But that way leads back to a "drawing program" that is musically illiterate.

kepper commented 7 years ago

This is certainly a lot to untangle, and it will have far-reaching consequences. For example, is used to capture annotations generically (functioning as the equivalent of the TEI element). So, it appears in the header and in body of MEI. Obviously, those in the header are meant to be rendered (in catalogs, for instance). But, if we decide those in the body should not be rendered, it will create inconsistency. One or the other (annotations in the header vs those in the body) will have to get a new name.

I'm not sure about this. At this point, annot is a fall-back for almost anything that can't be done (easily) with more explicit / appropriate elements. I'm not even sure about the distinction between annots in the header and the body. In Freischütz Digital, I moved the very same annotations back and forth between both positions as I needed them (sometimes, there was no body in that file, sometimes I wanted them to be as close as possible to the "affected area"). All that happened (and still happens) simultaneously, depending on what I want to do with the encoding. At least I wasn't aware that there is an important distinction between annots in the header and annots in the body.

What I'm trying to say is that we shouldn't introduce a strict interpretation of the current annot element. I'm happy to discuss more specific annotations as separate elements, maybe along the lines of the annotStruct element we've been discussing on and off. But redefining the existing annot seems likely to cause at least confusion, if not incompatibility…

pe-ro commented 7 years ago

@craigsapp: Your explanation of how boxes above and below the staff expand to accommodate their contents is exactly what I have in mind. The remaining question is, What should be done if @tstamp2 is absent?