Replies: 21 comments 35 replies
-
It seems to me that this can be pretty easily fixed by allowing |
Beta Was this translation helpful? Give feedback.
-
|
I would like to convert this to a discussion, instead of an issue, since there is nothing actionable here at the moment. At such time that things filter out from this, we can create separate issues for each of them. |
Beta Was this translation helpful? Give feedback.
-
|
@ahankinson : I do agree to convert this issue to a discussion. I will than provide separate issues for each case. |
Beta Was this translation helpful? Give feedback.
-
|
Done! It’s probably best to wait on creating the issues until we determine the course of action to take. |
Beta Was this translation helpful? Give feedback.
-
|
Why not encode the first example in two parts? <trill staff="6" startid="#note_27480-A" xml:id="trill_27543-A" next="trill_27543-B"/>
<supplied resp="#NMA-editors" xml:id="extender_1">
<trill staff="6" startid="#note_27480-A" endid="#note_27481-A" xml:id="trill_27543-B" prev="trill_27543-A" lstartsym="none" enclose="brack"/>
</supplied> |
Beta Was this translation helpful? Give feedback.
-
|
What about: <trill xml:id="t1" />
<supplied>
<line form="wavy" func="extender" follows="#t1"/>
</supplied>(other possible attributes omitted). I believe this is mostly possible with MEI now. Whether you call it an extender or simply a line, it's clearly not the trill that was supplied, but the line. The only minor change is to Would that work? |
Beta Was this translation helpful? Give feedback.
-
|
Works for me. :-) No change is required for |
Beta Was this translation helpful? Give feedback.
-
|
Hm. I guess then that the documentation for |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the actual ODD for the att.line.log attribute class is better than relying on the human-edited and -managed description. I wonder if the |
Beta Was this translation helpful? Give feedback.
-
There are varying ideas on this. In "traditional" XML, that is correct. However, TEI and, by extension MEI, has contexts where there can be multiple competing hierarchies, and XML does not model this well. So the solution is to use "standoff" markup -- elements that are linked by ID and not by hierarchy. This is a very common pattern in use throughout MEI -- it allows us to have beams that cross measures, slurs that cross layers, and other necessary things. It also allows greater flexibility in encoding so that we can build new encoding patterns without necessarily remodelling the schema every time a specific instance comes along that doesn't fit. This is why we effectively have two validation systems: The traditional XML schema (RNG) that simply verifies parent / child and attribute values, and the more comprehensive Schematron that verifies links between non-hierarchical, but related, entities. You wouldn't say that notes that are linked by a So me proposing the
It would also need to be a child element of These are the things we need to think about when we add a new element -- is its behaviour well-defined, and is its use clearly able to be communicated. I think if we do add extender, it will also need to be available on any musical element that can have an extender. This is a very big change. That's why I'm reticent to add it at this point, particularly because we have an existing element, The same can be said for making different elements for
It's also been unavoidable in the past. 😁 A very common interaction we have is that a member of the community comes along and says "MEI MUST HAVE THESE NEW ELEMENTS TO BE VALID" but then we work through it and usually a solution is found. We do add new elements all the time, but the road to adding those is necessarily slow so that we can also keep the specification to a manageable size, and keep the documentation up-to-date, and deal with bugs, etc. |
Beta Was this translation helpful? Give feedback.
-
|
@cividini As a sort of meta-commentary: What might not be immediately obvious is that the addition of elements can be a significant maintenance overhead, and having a lot of elements contributes to the overall complexity of MEI. This makes it increasingly difficult for our community to know when to use a specific method for encoding, if we have two (or more) different ways of encoding the same thing. So while I don't think we should shy away from complexity when necessary, I think we should also: a) first try to find workable solutions that do not require simply adding new things to the specification, and These should be explored prior to simply introducing new elements on-demand. So, to take one of your proposals: The idea of adding In your proposal you are actually proposing a significant re-model of The answer is obviously "no" but by following your proposal this would be possible. Is this something we want? Or can we find different solutions? I think @rettinghaus' suggestion about using |
Beta Was this translation helpful? Give feedback.
-
|
@ahankinson : I agree with you that we should first try an "internal" solution in MEI and I am just exploring @rettinghaus' very tricky solution in detail and listing the specific problems it poses (independently from the problematic rendering in Verovio). That <note>
<supplied>
<abbr/>
<anchoredText/>
<arpeg/>
<clef/>
[etc.]
</supplied>
</note>But it is allowed in MEI as for any other element that can have Another criterium we have to take in account is if the "internal" solution becomes too redundant. I think that when the "internal" solution produces to much redundant code it is the time to consider whether allowing an attribute to be an element could be a more workable solution (and there are many such cases in the past where this was choosen at the end as the more workable solution). In the case of the solution suggested by @rettinghaus I fear we will have a little too redundant code, but let we try it! |
Beta Was this translation helpful? Give feedback.
-
|
Correct, I think my main concern was more that we were changing to content model of For me, too much code is not a problem, since it's primarily a computer who should consume it, and ideally a computer that should create it. The bigger issue isn't that it doesn't look "elegant", but that the person who is writing the software doesn't have a clear idea of what their software should write for the encoding. Once they understand what to write, then it almost doesn't matter how much code is generated. Once a bad method of encoding is written in software, then that has a tendency to propagate! (Just look at how awful Sibelius' support of MusicXML is, if you want to see an example of this!) |
Beta Was this translation helpful? Give feedback.
-
|
@ahankinson : Unfortunately we will also need all other Editorial Markups like <trill staff="6" startid="#note_27480-A" xml:id="trill_27543-A"/>
<choice xml:id="choice_extender">
<corr resp="#NMA-editors" xml:id="corr_extender">
<extender tstamp2="0m+4.49" xml:id="extender_editor"/>
</corr>
<orig xml:id="orig_extender">
<extender tstamp2="0m+2.49" xml:id="extender_autograph"/>
</orig>
</choice>
</trill>But let we start with the easier cases! |
Beta Was this translation helpful? Give feedback.
-
|
For the case of the differing extenders on a trill, may I suggest the following -- This encoding captures the essential difference between the two witnesses; that is, a trill that ends at different times in the two editions. The Guidelines could be made much clearer on this topic, but the presumption is that a renderer will display an extending line when As a general rule, changes in the attributes of an entity require encoding the entire entity again. As one adds more witnesses/editions to the mix, of course the file size will increase as well. However, the complexity of the encoding won't increase, which is a more important thing to control. |
Beta Was this translation helpful? Give feedback.
-
|
I think a variation on the same idea that worked for the trill works for the figured bass example -- This encoding captures the basic difference between the two editions -- only one has an extender. My feeling -- totally without evidence -- is that extenders are the exception in figured bass, so there's no expectation that a renderer should display an extender when one isn't indicated in the markup. In any case, this encoding makes the presence/absence of the extenders explicit. One could go further and omit As an aside -- |
Beta Was this translation helpful? Give feedback.
-
|
The tuplet number example can be resolved with -- The difference between the two editions is the absence/presence of the '3'. This is captured by the I understand that this encoding may not be pleasing to the eye, or to an editor's sensibility regarding unnecessary repetition, but it is absolutely explicit. In XML clear markup trumps succinct markup. Verbosity is part of XML, but given efficient compression and cheap storage, it's not an important problem. If there's a conflict between clarity and repetition, clarity should always win. N,B, The availability of |
Beta Was this translation helpful? Give feedback.
-
|
The trill accidental example can probably be resolved using the same methodology as the others -- I don't know, I didn't try. In this case, I'm open to the possibility of allowing |
Beta Was this translation helpful? Give feedback.
-
|
The editorial repeat signs do not occur in the event data; that is, they're not part of the content of the measure. Instead, they are meta-information about the events in the measure. As such, they can be encoded using what MIDI calls "control events"; i.e., and in the first and last measures of the repeated section, respectively. Each of these can be wrapped by the These symbols will have no effect when it comes to performance, but that's a different animal. If automated playback is the goal, then one can use |
Beta Was this translation helpful? Give feedback.
-
|
@pe-ro : Thank you for your very practical suggestions. The <choice xml:id="choice_10515">
<corr resp="#NMA-editors" xml:id="corr_10515">
<trill accidupper="f" extender="true" lform="wavy" place="above" staff="3" startid="#note_10407" tstamp2="2.70" xml:id="trill_10515a"/>
</corr>
<orig xml:id="orig_10515">
<trill extender="false" place="above" staff="3" startid="#note_10407" xml:id="trill_10515b"/>
</orig>
</choice>As I wrote earlier, this workaround is problematic for us for a number of reasons.
<trill staff="1" startid="#note_1" xml:id="trill_1">
<supplied resp="#NMA-editors" xml:id="supplied extender_1">
<extender extender="true" tstamp2="0m+4.49" xml:id="extender_1"/>
</supplied>
</trill>This is a real problem in a critical edition like the Mozart Digital Edition, where the editor has to make many additions. But we can live with it. What it is more difficult to live with, is the duplication of the main element <app xml:id="app_10515">
<rdg n="1" resp="#MOZART_1780" xml:id="rdg1_10515">
<trill staff="6" startid="#note_27480-A" xml:id="trill_27543-A"/>
</rdg>
<rdg n="2" resp="#MOZART_1785" xml:id="rdg2_10515">
<trill extender="true" staff="6" startid="#note_27480-A" tstamp2="0m+4.49" xml:id="trill_27543-B"/>
</rdg>
</app>but to encode just the one trill in the autograph with the added extender: <trill extender="true" staff="6" startid="#note_27480-A" xml:id="trill_27543-B">
<supplied resp="MOZART_1785" xml:id="supplied_extender_1">
<extender extender="true" tstamp2="0m+4.49" xml:id="extender_1"/>
</supplied>
</trill>
|
Beta Was this translation helpful? Give feedback.
-
|
@pe-ro : Let me give another example of "redundancy" in the encoding of <choice xml:id="choice_num_visible">
<corr resp="#NMA-editors" xml:id="corr_tuplet_num_visible_true">
<tuplet bracket.visible="false" num="6" num.visible="true" numbase="4" xml:id="tuplet_17397a">
<note dur="16" oct="4" pname="f" stem.dir="up" tstamp="3" xml:id="note_17403a">
<accid accid.ges="n" xml:id="accid_17403a"/>
</note>
<note dur="16" oct="4" pname="a" stem.dir="up" tstamp="3.16667" xml:id="note_17409a"/>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.33334" xml:id="note_17415a">
<supplied resp="#NMA-editors" xml:id="supplied_17415a">
<accid accid="n" xml:id="accid_17415a"/>
</supplied>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.50001" xml:id="note_17430a">
<artic artic="stacc" xml:id="artic_17430a"/>
<accid accid.ges="n" xml:id="accid_17430a"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.66668" xml:id="note_17436a">
<artic artic="stacc" xml:id="artic_17436a"/>
<accid accid.ges="n" xml:id="accid_17436a"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.83335" xml:id="note_17442a">
<artic artic="stacc" xml:id="artic_17442a"/>
<accid accid.ges="n" xml:id="accid_17442a"/>
</note>
</tuplet>
</corr>
<orig xml:id="orig_num_visible_false">
<tuplet bracket.visible="false" num="6" num.visible="false" numbase="4" xml:id="tuplet_17397b">
<note dur="16" oct="4" pname="f" stem.dir="up" tstamp="3" xml:id="note_17403b">
<accid accid.ges="n" xml:id="accid_17403b"/>
</note>
<note dur="16" oct="4" pname="a" stem.dir="up" tstamp="3.16667" xml:id="note_17409b"/>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.33334" xml:id="note_17415b">
<supplied resp="#NMA-editors" xml:id="supplied_17415b">
<accid accid="n" xml:id="accid_17415c"/>
</supplied>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.50001" xml:id="note_17430b">
<artic artic="stacc" xml:id="artic_17430b"/>
<accid accid.ges="n" xml:id="accid_17430b"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.66668" xml:id="note_17436b">
<artic artic="stacc" xml:id="artic_17436b"/>
<accid accid.ges="n" xml:id="accid_17436b"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.83335" xml:id="note_17442b">
<artic artic="stacc" xml:id="artic_17442b"/>
<accid accid.ges="n" xml:id="accid_17442b"/>
</note>
</tuplet>
</orig>
</choice>In order to mark up the addition of the number in tuplet with The solution with <tuplet bracket.visible="false" num="6" num.visible="true" numbase="4" xml:id="tuplet_17397a">
<supplied resp="#NMA-editors" xml:id="supplied_num_visible">
<num num="6" num.visible="true" xml:id="num_visible"/>
</supplied>
<note dur="16" oct="4" pname="f" stem.dir="up" tstamp="3" xml:id="note_17403a">
<accid accid.ges="n" xml:id="accid_17403a"/>
</note>
<note dur="16" oct="4" pname="a" stem.dir="up" tstamp="3.16667" xml:id="note_17409a"/>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.33334" xml:id="note_17415a">
<supplied resp="#NMA-editors" xml:id="supplied_17415a">
<accid accid="n" xml:id="accid_17415a"/>
</supplied>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.50001" xml:id="note_17430a">
<artic artic="stacc" xml:id="artic_17430a"/>
<accid accid.ges="n" xml:id="accid_17430a"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.66668" xml:id="note_17436a">
<artic artic="stacc" xml:id="artic_17436a"/>
<accid accid.ges="n" xml:id="accid_17436a"/>
</note>
<note dur="16" oct="5" pname="c" stem.dir="up" tstamp="3.83335" xml:id="note_17442a">
<artic artic="stacc" xml:id="artic_17442a"/>
<accid accid.ges="n" xml:id="accid_17442a"/>
</note>
</tuplet>But, as I wrote, we could live with that redundancy. (However, at the moment we prefer to add a simple |
Beta Was this translation helpful? Give feedback.
-
|
@pe-ro : In example 6 (repeat sign added by the editor) we can see the consequences from the impossibility of encoding the
Click here to see the MEI code.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://music-encoding.org/schema/dev/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei meiversion="5.0" xmlns="http://www.music-encoding.org/ns/mei">
<meiHead>
<fileDesc>
<titleStmt>
<title label="NMA digital" type="unit">supplied trill@extender</title>
</titleStmt>
<pubStmt/>
</fileDesc>
</meiHead>
<music>
<body>
<mdiv>
<score>
<scoreDef key.mode="major" key.pname="d" keysig="2s" meter.count="4" meter.sym="common" meter.unit="4" xml:id="scoreDef_01">
<staffGrp bar.thru="true" symbol="bracket" xml:id="staffGrp_01">
<staffDef clef.line="2" clef.shape="G" label="Violino I" lines="5" n="1" xml:id="staffDef_P1"/>
<staffDef clef.line="2" clef.shape="G" label="Violino II" lines="5" n="2" xml:id="staffDef_P2"/>
<staffDef clef.line="3" clef.shape="C" label="Viola" lines="5" n="3" xml:id="staffDef_P3"/>
<staffDef clef.line="4" clef.shape="F" label="Violoncello e Basso" lines="5" n="4" xml:id="staffDef_P4"/>
</staffGrp>
</scoreDef>
<section>
<choice xml:id="choice_supplied_rptstart">
<corr resp="#NMA-editors" xml:id="corr_supplied_rptstart">
<measure n="50" right="rptstart" xml:id="m50_k138_003aa">
<staff n="1" xml:id="staff_6327aa">
<layer n="1" xml:id="layer_6330aa">
<chord dur="4" tstamp="1" xml:id="chord_6333aa">
<note dur="4" oct="5" pname="f" xml:id="note_6336aa"/>
<note dur="4" oct="4" pname="a" xml:id="note_6339aa"/>
</chord>
<beam xml:id="beam_6342aa">
<note dots="1" dur="8" oct="5" pname="f" tstamp="2" xml:id="note_6345aa"/>
<note dur="32" oct="5" pname="e" tstamp="2.75" xml:id="note_6348aa"/>
<note dur="32" oct="5" pname="f" tstamp="2.875" xml:id="note_6351aa"/>
</beam>
</layer>
</staff>
<staff n="2" xml:id="staff_6354aa">
<layer n="1" xml:id="layer_6357aa">
<rest dur="8" tstamp="1" xml:id="rest_6360aa"/>
<beam xml:id="beam_6363aa">
<note dur="8" oct="4" pname="f" tstamp="1.5" xml:id="note_6366aa"/>
<note dur="8" oct="4" pname="a" tstamp="2" xml:id="note_6369aa"/>
<note dur="8" oct="5" pname="c" tstamp="2.5" xml:id="note_6372aa"/>
</beam>
</layer>
</staff>
<staff n="3" xml:id="staff_6375aa">
<layer n="1" xml:id="layer_6378aa">
<rest dur="4" tstamp="1" xml:id="rest_6381aa"/>
<rest dur="8" tstamp="2" xml:id="rest_6384aa"/>
<note dur="8" oct="3" pname="a" tstamp="2.5" xml:id="note_6387aa"/>
</layer>
</staff>
<staff n="4" xml:id="staff_6390aa">
<layer n="1" xml:id="layer_6393aa">
<note dur="4" oct="3" pname="f" tstamp="1" xml:id="note_6396aa"/>
<note dur="4" oct="2" pname="f" tstamp="2" xml:id="note_6399aa"/>
</layer>
</staff>
<choice xml:id="choice_supplied_extender-a">
<corr resp="#NMA-editors" xml:id="corr_supplied_extender-a">
<trill extender="true" staff="1" startid="#note_6345" xml:id="trill_6402aaa"/>
</corr>
<orig xml:id="orig_supplied_extender-a">
<trill staff="1" startid="#note_6345" xml:id="trill_6402aba"/>
</orig>
</choice>
</measure>
</corr>
<orig xml:id="orig_supplied_rptstart">
<measure n="50" xml:id="m50_k138_003ab">
<staff n="1" xml:id="staff_6327ab">
<layer n="1" xml:id="layer_6330ab">
<chord dur="4" tstamp="1" xml:id="chord_6333ab">
<note dur="4" oct="5" pname="f" xml:id="note_6336ab"/>
<note dur="4" oct="4" pname="a" xml:id="note_6339ab"/>
</chord>
<beam xml:id="beam_6342ab">
<note dots="1" dur="8" oct="5" pname="f" tstamp="2" xml:id="note_6345ab"/>
<note dur="32" oct="5" pname="e" tstamp="2.75" xml:id="note_6348ab"/>
<note dur="32" oct="5" pname="f" tstamp="2.875" xml:id="note_6351ab"/>
</beam>
</layer>
</staff>
<staff n="2" xml:id="staff_6354ab">
<layer n="1" xml:id="layer_6357ab">
<rest dur="8" tstamp="1" xml:id="rest_6360ab"/>
<beam xml:id="beam_6363ab">
<note dur="8" oct="4" pname="f" tstamp="1.5" xml:id="note_6366ab"/>
<note dur="8" oct="4" pname="a" tstamp="2" xml:id="note_6369ab"/>
<note dur="8" oct="5" pname="c" tstamp="2.5" xml:id="note_6372ab"/>
</beam>
</layer>
</staff>
<staff n="3" xml:id="staff_6375ab">
<layer n="1" xml:id="layer_6378ab">
<rest dur="4" tstamp="1" xml:id="rest_6381ab"/>
<rest dur="8" tstamp="2" xml:id="rest_6384ab"/>
<note dur="8" oct="3" pname="a" tstamp="2.5" xml:id="note_6387ab"/>
</layer>
</staff>
<staff n="4" xml:id="staff_6390ab">
<layer n="1" xml:id="layer_6393ab">
<note dur="4" oct="3" pname="f" tstamp="1" xml:id="note_6396ab"/>
<note dur="4" oct="2" pname="f" tstamp="2" xml:id="note_6399ab"/>
</layer>
</staff>
<choice xml:id="choice_supplied_extender-b">
<corr resp="#NMA-editors" xml:id="corr_supplied_extender-b">
<trill extender="true" staff="1" startid="#note_6345" xml:id="trill_6402aab"/>
</corr>
<orig xml:id="orig_supplied_extender-b">
<trill staff="1" startid="#note_6345" xml:id="trill_6402abb"/>
</orig>
</choice>
</measure>
</orig>
</choice>
</section>
</score>
</mdiv>
</body>
</music>
</mei> |
Beta Was this translation helpful? Give feedback.
-
|
I think wrapping the By the phrase "a different animal" I meant that the score and the sound one is expected to produce from the score are different things. Furthermore, they cannot always be encoded in a single pass; that is, mixed together in the same branch of a tree representation. I understand the desire for this mixing, but it's very, very difficult to do because it leads to an explosion in the complexity of the markup. So, in MEI, marks on the page go in |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the provision of repeat marks not in the original, I think the solution shown earlier (adding editorial repeat signs above the score) is sufficient. This approach
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure it is a good idea to add more thoughts here, so please feel free to ignore my comment. I'm not adding it to any of the above threads, as it is a more general take that fits into many of those discussions. The initial example given by @cividini is, in my understanding of both MEI and music philology in general, not a supplement, even though something has been supplied without doubt. This is pretty much splitting hairs, but let me explain:
Having considered all that, let's turn to my favorite solution ;-)
Eventually, our data is what will survive, and considering the scale of projects like the DME, is significantly more expensive to improve than our tools. Of course, this is just an opinion, and as stated earlier, it is perfectly fine to not follow these arguments. However, I think the real discussion should be whether |
Beta Was this translation helpful? Give feedback.
-
|
Nope, We're saying the entire trill has been regularized, not supplied, so one possibility is |
Beta Was this translation helpful? Give feedback.
-
|
But how would a theoretical renderer know to draw the brackets around only the line, if the whole trill gets marked up with orig/reg? That's the original intention, as I understand it -- to indicate that the line is a supplied component of an original trill. You would have to do a diff against the two and see what bits changed between them, and that's pretty much impossible to do in the general case. |
Beta Was this translation helpful? Give feedback.
-
|
A renderer won't know. But the encoder can use the But this works at the level of the trill, not the line. |
Beta Was this translation helpful? Give feedback.
-
|
It's a little far-fetched, but I can also imagine that a renderer could compare the 2 trill elements above, and finding that the ending timestamps are different (and therefore the length of the extenders are different), render the line differently for the 2nd trill. How differently would depend on parameters passed to the renderer. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that could work with a lot of hand-coding in this specific instance. I would not want to have to write the logic for this in the general case, where any two elements between orig and reg can be compared.
That would produce |
Beta Was this translation helpful? Give feedback.
-
|
@kepper, thanks for joining the discussion. I agree that Did you see my comment above about using |
Beta Was this translation helpful? Give feedback.
-
|
Done! #1382 |
Beta Was this translation helpful? Give feedback.
-
|
@kepper : Thank you for joining the discussion! @ahankinson @pe-ro @kepper : The If we want to address the attribute directly in order to mark it up more precisely, we have two make it an element. At the same time we cannot separate it from the element it belongs to. As @lpugin (#1381 (reply in thread) and #1381 (reply in thread)) and also @kepper mentioned ("So, I don't think we should treat this as two things (i.e. a trill and a supplied line), and we should also not treat it as a trill containing either a different trill or a dedicated element with some child features."), the very tricky solutions proposed so far separate things that belong together: The wavy line is not a separate entity, but it is an integral part of the trill, as is the So the general question here is: How can we adress the attributes that belong to an element with editorial markups ("meta markups") like <trill xml:id="trill_1">
<supplied>
<extender type="belongs_to_trill_1"/>
</supplied>
<supplied>
<line form="wavy" func="extender" type="belongs_to_trill_1"/>
</supplied>
<supplied>
<trill lstartsym="none" type="belongs_to_trill_1"/>
</supplied>
</trill>This is the (I think inevitable) solution chosen for <note>
<supplied>
<accid/>
<artic/>
<dur/>
</supplied>
</note>If we agree with this solution already established for I know it sounds pretentious, but I fear that this solution (allowing the attribute to be a child element of the element it belongs to) will be unavoidable in the future. What I can say from my experience as an editor, is that there will not be as many attributes as the six listed in this discussion that will need to be marked up in a critical edition and therefore to be allowed to be an element. To avoid some of the serious consequences which this increase of granularity in MEI can have, we could restrict the use of this attribute as an element to the function of a CHILD element of a particular element, e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Admittedly, my language may not have been precise enough. For me (and I'm perfectly willing to accept other perspectives on the world), the two versions of the trill are actually two separate logical entities: They share some of their features, but they also contradict on others. You can't perform them both at the same time, you have to take a decision between them (I believe we can safely ignore the musician's freedom in interpreting either version – that's another dimension, one we don't need to deal with here). So, the first step is to capture that we have two entities and their specific relation (one being a redacted version of the other). I believe that I think @cividini has made it very clear that DME is not interested in capturing the graphical appearance of the bracketed line (which would be a different, perfectly valid requirement that would probably require some other changes to MEI). So, if visual encoding isn't the intention, my understanding is that DME wants to take a more "analytical" approach that focusses on the similarities and differences between the two things. The proposal for that is to have a shared base element as parent, which then gets "supplied" child features. In our Beethoven case, this would be a note with an "add"ed flag. However, what would be the duration in this case? We would have to turn the duration into a child element as well, which would have to be independent of the flag child. However, for some perspectives on the music, the duration of a note is indispensible for its identity – in the logical domain, quarters and 8th notes are different things. I'm inclined to say the same about our trill in question. So, I don't think the line is an ephemeral feature of an otherwise identical entity, and the specific child approach seems wrong to me in this case. However, there is still the wish to capture the differences between both versions. From my perspective, this is already taken care of by putting both versions side by side. I absolutely understand that it's not easy to deal with that in a generic way in a renderer. In the data model, it is fairly simple to compute those differences in a generic way – knowing what to do with that information is the much harder part. However, this is a restriction of our tools, and we shouldn't treat it as a restriction in our models. It all comes down to the perspective one takes on the data. Perspectives resolve into domains here, and I think the DME needs to be specific about how they see the world. Only then, we will be able to find a proper solution, instead of repeating our different takes over and over… ;-) |
Beta Was this translation helpful? Give feedback.
-
|
@pe-ro : Your argumentation for the repeat sign as |
Beta Was this translation helpful? Give feedback.
-
|
I think @ahankinson is on to something with the idea of separating the trill and the line but linking them together. I wouldn't recommend This kind of markup will allow for breaking the trill into its component parts. For instance, one could also use But, it doesn't preclude the use of The best part of the "separate parts" approach is that I think it can be applied in situations other than just trills as long as there's an element that corresponds to an attribute (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Forgot to add that the markup I provided above doesn't directly address the issue of how to render the supplied line. There are several possibilities --
|
Beta Was this translation helpful? Give feedback.
-
|
I think we can regroup the cases brought to this discussion in three categories.
We can clearly see here the limits of parallel segmentation, especially with cases of type 3. It works well around single elements, but not so much of changes in containers. Adding more spanning elements, or finding case-by-case workaround will not be a great solution. Maybe we can think quite differently, namely more in the direction of encoding stand-off changes, or some kind of change annotation. Not necessarily external annotations, but more something still in the MEI data and that would have the very specific purpose of specifying that one (and maybe eventually more?) attribute is different in one element, without creating a parallel segmentation. Where these annotations should leave is to be decided, but here I agree with @ahankinson that they can very well stand off and point to the element they are annotating, and do not have to be a child of it. I am making things up here, but I am imagining a way where can define or redefine the value of one attribute. We would have something like: <measure xml:id="m1" n="1" right="end">
<!-- ... -->
</measure>And then somewhere else: <editorialAttrAnnot target="#m1" source="#source1" attr="right" value="rptend"/>Or: <editorialAttrAnnot target="#m1" func="reg" attr="right" value="rptend"/>Of course, we would loose validation of the attribute values on Alternatively, we could imagine something like: <editorialAttrAnnot target="#m1" source="#source1">
<measure end="rptend"/>
</editorialAttrAnnot>Here validation would be applied as is for measure. One problem will be required attributes, though. Also, context validation (Schematron) would need to be de-activated in I am aware that this is completely different, quite disruptive, and certainly not thoroughly named and designed. I am more throwing an idea, here. And of course, this is not meant to replace parallel segmentation, which would still recommended to be used whenever appropriate. |
Beta Was this translation helpful? Give feedback.
-
|
I like this approach of thinking out of the box, because I also see no elegant way to deal with case 3 using existing concepts. Not perfectly sure about the very proposal (putting aside the element name, which I consider a straw man only). At least I need a little more thinking about this, though I like the direction… |
Beta Was this translation helpful? Give feedback.
-
Whilst encoding of the editorial markup for the Digital Mozart Edition, we have come across an issue regarding the markup of a significant amount of editorial additions. The issue arises from the MEI markup mechanism: editorial additions must be enclosed within a
<supplied>element, implying that the added material has also to be an element. While we acknowledge and endorse the MEI philosophy of utilizing elements and attributes, in this case it poses some noteworthy limitations. Additionally, there appear to be some inconsistenccies within the MEI framework, as, for example, @accid is allowed to be an element, whereas@accidupperor@accidlowerare not. Here is a short list of cases:1.
trill@extenderA common editor's addition is the wavy line after the trill (
@extender), which is shown in square brackets in most critical editions (here for example in the Neue Mozart-Ausgabe, K. 165/1, T. 118, Soprano):Click here to see the MEI code.
With the possibility to use
@extenderas an element, the extender added by the editor could be encoded in a simple and semantically correct way (actually not allowed in MEI):2.
harm@extenderThe impossibility of using
@extenderas an element leads to a contradiction in<harm>:While a short extender of the harmony (hypen: -) in
<f>can be marked up with<supplied>:the long extender (
@extender: _____ ) cannot:Click here to see the MEI code.
3.
tuplet@numAnother common case is the addition of tuplet numbers (
@num) by the editor in a critical edition:Click to see the code.
In this case, the
@numattribute seems to be allowed as a<num>child element of<tuplet>in the MEI 5 schema:However, I can't find any confirmation of this in the MEI 5 guidelines. In any case, it is not yet rendered by Verovio (the first tuplet, in red, is squeezed into a chord above the second tuplet):
4.
tuplet@bracketWhile
@numseems to be allowed as a child element of<tuplet>,@bracketis not, although it’s also a notation character that’s often “supplied” in critical editions:5.
trill@accidupper/@accidlowerAnother very common case of an editor-supplied attribute in critical editions is
@accidupper/@accidlowerover a trill or a mordent (here an example from the Neue Mozart-Ausgabe, K. 525/1, Violino I, T. 36, accidupper in square brackets):Click to see the code.
In this case, the MEI guidelines seem to be rather inconsistent at the moment, as they allow
@accidas an element, but not@accidupper/@accidlower:Even the use of
<accid place="above/below"/>is not allowed in<trill>or<turn>(but only for<note>), so it is currently impossible to mark an accidupper or accidlower added by the editor in a critical edition as in the example from the NMA above (accidupper in square brackets):6.
measure@right="rptend"A special case is when the repetition marks are provided by the editor, as here in the Neue Mozart-Ausgabe, K. 138/3, second system, m. 50-57:
Here, the repetitions are supplied by the editor (based on historical performance practice) in the second system as a small repetition symbol above the system. To encode this typical editor's addition in the critical edition, you would need
@rptend/rptstartas an element, here for example in m. 50:Conclusion
It is important to stress that the addition of these attributes constitutes the bulk of the editorial interventions in a critical edition, since it is precisely these 'secondary' notation marks that composers overlook and involuntarily omit in their manuscripts (while concentrating on the main musical substance of their composition). As far as I know, this does not only apply to Mozart, but also to many other composers such as Chopin or Dvořák. In my opinion, MEI should be able to mark up exactly these additions made by the editor, if it also wants to be a scholarly markup language for music. Increasing the granularity of MEI by allowing these few more attributes to be also an element therefore means increasing its scientific and philological power.
If there are no objections to the general issue, I would prepare a separate issue for each of these cases to be discussed in detail.
Beta Was this translation helpful? Give feedback.
All reactions