implement <annot> display #389
Comments
|
I'd love to see Verovio rendering |
|
+1 :-) |
|
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:
The guidelines also say:
So they can happen more or less everywhere, so rendering them as |
|
Reading this confirms that we need to wait until it is clarified in MEI |
|
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 |
|
One more note: |
|
Taking a "wait-and-see" or "phased-implementation" approach to One question, though: Do all It seems to me that annotations with textual content can be treated in the same way as |
Remains empty. 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. |
|
As I understand it, |
|
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 |
|
I see your point. The reason for not encoding them as directives in the first place is that A quick comparison of the attributes of |
|
@lpugin, It's true that |
|
See this one #248 |
|
I would argue that when Craig and Don need annotations to behave like <dir>, why don't you convert your <annot> to <dir> 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 <div> 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 ***@***.***>:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I always thought they were done by the implementation fairy :-)
That would be possible.
And another thing I will have to study is how multiple dirs behave at the same timepoint (and can they be positioned with |
|
@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 |
|
I think support for for @craigsapp system breaks is also a general issue to consider not only for Font: you can change it with <dir><rend fontstyle="normal">Your directive</rend></dir> |
|
@donbyrd rendering I would rather do something like: <supplied reason="documentation"><dir>mensural black</dir></supplied> |
|
Thanks, I'd forgotten about that. (#248, that is.) The main reason they're in |
That's going to be a hard-sell for lots of folks. If it helps, think of as syntactic sugar for |
|
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> |
|
@kepper, there's nothing necessarily problematic about treating a 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 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 |
|
@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. |
|
What to you mean by data for rendering it? A <note>
<verse>
<syl xml:id="s"><annot startid="#s">What is this?</annot>The</syl>
</verse>
</note> |
In my mind, anything affecting volume is a dynamic.
And anything affecting speed/time is appropriate for
These defy categorization and so, like the Guidelines say, should go into a more generic "bin"; that is, |
|
@craigsapp: Even if "a tempo" and "Lento" are both marked using |
|
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. |
|
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.
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…
|
|
@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 |
|
@kepper: I think you're right, I was just raising the question. |
|
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 ***@***.***>:
@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.
|
|
Yes, I think so. |
If there is no 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:
|
|
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). |
|
And here is a "manuscript" version of annotations: http://www.willemmengelberg.nl/?q=discografie
|
|
@craigsapp: I like what you're suggesting because --
I agree with your assessment of extensive text --
|
|
@craigsapp: Yep, those are annotations all right! |
|
Let me qualify that last statement -- some of those things are MEI annotations since |
I agree. Mensural music should use exclusively |
|
I don't know about you guys, but I feel like we've made a break through. From here on, it's just details. |
|
Yes, this is good. If we do not want to make any distinction between annotations I think adding an attribute |
|
@lpugin: Adding |
|
Circling back to address where Here's a test file that allows @lpugin: Is this what you had in mind? Note that this change is not backwards compatible, so should we allow |
|
More details If Also, 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 With the original purpose of Sound like a plan? |
|
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. |
|
Am 21.12.2016 um 22:25 schrieb pe-ro ***@***.***>:
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!
|
|
I agree with @kepper; we should discuss on MEI-L. Otherwise, it sounds like a plan! |
|
@kepper: Ok, will you summarize the discussion here on MEI-L and solicit additional input? Thanks, honey. |
|
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. |
|
@pe-ro said:
That was a single-staff system, so it behaves as you are thinking. |
|
@craigsapp, Great! |
|
Say, there's been a fair amount of discussion of |
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
@nwere implemented for<annot>(and perhaps<harm>) which would stack annotations in a similar manner to<verse>; i.e.,@nwould handle vertical collision avoidance between separate streams of annotations.Test data:
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.
The text was updated successfully, but these errors were encountered: