rettinghaus
commented
6 years ago Encoding problems should be reported (or better just fixed) over here: https://github.com/music-encoding/sample-encodings
Closed craigsapp closed 6 years ago
rettinghaus
commented
6 years ago Encoding problems should be reported (or better just fixed) over here: https://github.com/music-encoding/sample-encodings
craigsapp
commented
6 years ago Is this an encoding error?
rettinghaus
commented
6 years ago Yes, the fermatas are double encoded, so Verovio renders it correct.
craigsapp
commented
6 years ago Well it is not clear to me that it is an encoding error, since the floating element clearly indicates that it is attached to the same note that has@fermata:
<note xml:id="d1e37539" pname="b" oct="2" dur="2" dots="1" fermata="above" stem.dir="up"/>And the floating fermata element:
<fermata staff="14" startid="#d1e37539" form="norm" place="above"/>If a staccato were encoded like this:
<note dur="4" oct="4" pname="c" artic="stacc" accid.ges="n">
<artic artic="stacc" />
</note>How should this be handled? Place two staccatos on the note, or realize that the staccato being describe is the same staccato?
This also applies to note@tie/<tie> and note@slur/<slur> double encodings. Would encoding the slur/tie in both ways imply a double slur/tie?
pe-ro
commented
6 years ago The argument has been made that using both attribute (say, @fermata) and element (<fermata>) is a "double encoding". However, I believe, especially in light of the attributes being moved to the analytical module/domain, that the attribute and element are capturing different aspects of the same thing. That is, the attribute records the presence of a fermata attached to this note, which is useful for analytical purposes. The element, on the other hand, approaches the issue from the "opposite direction" -- it captures a fermata which is attached to a note -- which is useful for rendition. So, I would argue that these are two perspectives on the same fermata -- it's not a double encoding.
rettinghaus
commented
6 years ago So the analytical attributes should not be rendered? Then Verovio can drop the support.
craigsapp
commented
6 years ago So the analytical attributes should not be rendered? Then Verovio can drop the support.
If the fermata has this expression:
<note pname="b" oct="2" dur="2" fermata="above"/>without a paired floating <fermata> element, I would still expect a typesetting program to render a fermata above the note regardless of if @fermata is classified as an analytic attribute or not. If it were actually a purely analytic attribute, then I would expect the attribute to be something like @fermata="true".
The element-only form of the fermata should be rendered the same (with extra rendering possibilities in the fermata element attributes):
<measure>
<staff n="1">
<layer>
<note xml:id="d1e37539" pname="b" oct="2" dur="2" />
</layer
</staff>
<fermata staff="1" startid="#d1e37539" form="norm" place="above"/>
</measure>If both are present, then the renderer should identify that they describe the same fermata, so only one fermata should be rendered:
<measure>
<staff n="1">
<layer>
<note xml:id="d1e37539" pname="b" oct="2" dur="2" fermata="above"/>
</layer
</staff>
<fermata staff="1" startid="#d1e37539" form="norm" place="above"/>
</measure>However here is a corner case, where the attribute and element form of the fermata have a conflicting rendering:
<measure>
<staff n="1">
<layer>
<note xml:id="d1e37539" pname="b" oct="2" dur="2" fermata="below"/>
</layer
</staff>
<fermata staff="1" startid="#d1e37539" form="norm" place="above"/>
</measure>What should happen in this case?: (1) there is one fermata and it is placed above the note (2) there is one fermata and it is placed below the note (3) there are two fermatas, one above and one below the note
I would probably prefer case no. 1, with the floating-element fermata rendering parameters overriding those of the attribute version.
Another related case is: what to do if the floating-element fermata is attached to the staff via @tstamp rather than @startid:
<measure>
<staff n="1">
<layer>
<note xml:id="d1e37539" pname="b" oct="2" dur="2" fermata="above"/>
</layer
</staff>
<fermata staff="1" tstamp="1" form="norm" place="above"/>
</measure>In this case there is no direct link between the floating-element fermata and the note, so I would expect two fermatas in this case.
pe-ro
commented
6 years ago I agree with Craig, but without going so far as to change the possible values for @fermata. The position of the fermata with respect to the staff may have analytical implications, just as the value of @tie (i|m|t) might. This approach isn't without precedent as it mimics the features of **kern.
craigsapp
commented
6 years ago Semi-related is issue #690, since fermatas rendered via attributes are centered on the timestamp rather than the notehead (this is due to the repositioning of the timestamp to the left edge of notes):
The attribute fermatas should be centered on noteheads rather than on the timestamp position (left edge of notes).
The first measure fermata is a floating element, the second one is an attribute, the third has both (with the two centered on the left and center of the notehead):
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.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="4.0.0">
<meiHead>
<fileDesc>
<titleStmt>
<title />
</titleStmt>
<pubStmt />
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2017-10-30T00:18:58" version="2.0.0-dev-acee426">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workDesc>
<work>
<titleStmt>
<title />
</titleStmt>
</work>
</workDesc>
</meiHead>
<music>
<body>
<mdiv>
<score>
<scoreDef xml:id="scoredef-0000001894265594" midi.bpm="400">
<staffGrp xml:id="staffgrp-0000000309684360">
<staffDef xml:id="staffdef-0000001025071254" clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5" />
</staffGrp>
</scoreDef>
<section xml:id="section-0000000838508524">
<measure xml:id="measure-L3" n="1">
<staff xml:id="staff-L3F1N1" n="1">
<layer xml:id="layer-L3F1N1" n="1">
<note xml:id="note-L4F1" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<fermata xml:id="fermata-L4F1" staff="1" startid="#note-L4F1" place="above" />
</measure>
<measure xml:id="measure-L5" n="2">
<staff xml:id="staff-L5F1N1" n="1">
<layer xml:id="layer-L5F1N1" n="1">
<note xml:id="note-L6F1" dur="1" oct="4" pname="d" accid.ges="n" fermata="above" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L7" right="end" n="3">
<staff xml:id="staff-L7F1N1" n="1">
<layer xml:id="layer-L7F1N1" n="1">
<note xml:id="note-L8F1" dur="1" oct="4" pname="e" accid.ges="n" fermata="above" />
</layer>
</staff>
<fermata xml:id="fermata-L8F1" staff="1" startid="#note-L8F1" place="above" />
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>Here is a rendering after a round trip from MEI to Humdrum to MEI:
Humdrum:
!!!COM: Johann Nepomuk Hummel
!!!OTL: Trumpet Concerto in E major
**kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam **kern **dynam
*staff14 * *staff13 * *staff12 * *staff11 * *staff10 * *staff9 * *staff8 * *staff7 * *staff6 * *staff5 * *staff4 * *staff3 * *staff2 * *staff1 *
*ITrd7c12 * * * * * * * * * * * * * *ITrd4c7 * *ITrd4c7 * *ITrd1c2 * *ITrd1c2 * * * * * * *
*clefF4 * *clefF4 * *clefC3 * *clefG2 * *clefG2 * *clefF4 * *clefG2 * *clefG2 * *clefG2 * *clefG2 * *clefG2 * *clefG2 * *clefG2 * *clefG2 *
*k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] * *k[f#c#g#d#] *
*M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 * *M4/4 *
*MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 * *MM132 *
=42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42 =42
2.BBB; . 2.BB; . 2.B; . 2.B; . 2.B; . 2.BB; . 1r . 1r . 1r . 2.b; . 2.dd#; . 2.ff#; . 2.aa; . 2.aa; .
. . . . . . (8qf# . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . (8qf# . . . . . . . . . . . . . . . . . . .
4r pp (8.G#L pp (8.BL pp 8.eL pp 8.eL pp 4r pp . pp . pp . pp 4r pp 4r pp 4r pp 4r pp 4r pp
. . 16AJ) . 16cJ) . 16d#J) . 16d#J) . . . . . . . . . . . . . . . . . . .
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
*- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *-
!!!system-decoration: [(s1,s2,s3,s4,s5)][(s6,s7)](s8)(s9)[(s10,s11,s12,s13,s14)]Return into MEI, where I have converted the fermata into floating elements:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.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="4.0.0">
<meiHead>
<fileDesc>
<titleStmt>
<title>Trumpet Concerto in E major</title>
</titleStmt>
<pubStmt />
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2017-10-30T00:28:28" version="2.0.0-dev-d24dc0b">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workDesc>
<work>
<titleStmt>
<title xml:id="title-L3" analog="humdrum:OTL" type="main">Trumpet Concerto in E major</title>
<respStmt>
<persName xml:id="persname-L2" analog="humdrum:COM" role="composer">Johann Nepomuk Hummel</persName>
</respStmt>
</titleStmt>
</work>
</workDesc>
</meiHead>
<music>
<body>
<mdiv>
<score>
<scoreDef xml:id="scoredef-0000000121312534" midi.bpm="132">
<staffGrp xml:id="staffgrp-0000001370286638" barthru="false">
<staffGrp xml:id="staffgrp-0000000620202554" symbol="bracket" barthru="true">
<staffDef xml:id="staffdef-0000001295529650" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="1" lines="5" />
<staffDef xml:id="staffdef-0000000595738124" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="2" lines="5" />
<staffDef xml:id="staffdef-0000000496773641" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="3" lines="5" />
<staffDef xml:id="staffdef-0000001205193596" clef.shape="G" clef.line="2" key.sig="6s" meter.count="4" meter.unit="4" n="4" lines="5" trans.diat="-1.000000" trans.semi="-2.000000" />
<staffDef xml:id="staffdef-0000001416742685" clef.shape="G" clef.line="2" key.sig="6s" meter.count="4" meter.unit="4" n="5" lines="5" trans.diat="-1.000000" trans.semi="-2.000000" />
</staffGrp>
<staffGrp xml:id="staffgrp-0000001603254752" symbol="bracket" barthru="true">
<staffDef xml:id="staffdef-0000001118704425" clef.shape="G" clef.line="2" key.sig="5s" meter.count="4" meter.unit="4" n="6" lines="5" trans.diat="-4.000000" trans.semi="-7.000000" />
<staffDef xml:id="staffdef-0000000419401474" clef.shape="G" clef.line="2" key.sig="5s" meter.count="4" meter.unit="4" n="7" lines="5" trans.diat="-4.000000" trans.semi="-7.000000" />
</staffGrp>
<staffDef xml:id="staffdef-0000001148960982" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="8" lines="5" />
<staffDef xml:id="staffdef-0000000557694981" clef.shape="F" clef.line="4" key.sig="4s" meter.count="4" meter.unit="4" n="9" lines="5" />
<staffGrp xml:id="staffgrp-0000000564197506" symbol="bracket" barthru="true">
<staffDef xml:id="staffdef-0000001519484888" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="10" lines="5" />
<staffDef xml:id="staffdef-0000001175707885" clef.shape="G" clef.line="2" key.sig="4s" meter.count="4" meter.unit="4" n="11" lines="5" />
<staffDef xml:id="staffdef-0000001783642461" clef.shape="C" clef.line="3" key.sig="4s" meter.count="4" meter.unit="4" n="12" lines="5" />
<staffDef xml:id="staffdef-0000000194025132" clef.shape="F" clef.line="4" key.sig="4s" meter.count="4" meter.unit="4" n="13" lines="5" />
<staffDef xml:id="staffdef-0000000539881664" clef.shape="F" clef.line="4" key.sig="4s" meter.count="4" meter.unit="4" n="14" lines="5" trans.diat="-7.000000" trans.semi="-12.000000" />
</staffGrp>
</staffGrp>
</scoreDef>
<section xml:id="section-0000000929566118">
<measure xml:id="measure-L11" n="42">
<staff xml:id="staff-L11F27N1" n="1">
<layer xml:id="layer-L11F27N1" n="1">
<note xml:id="note-L12F27" dots="1" dur="2" oct="5" pname="a" accid.ges="n" />
<rest xml:id="rest-L15F27" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F25N1" n="2">
<layer xml:id="layer-L11F25N1" n="1">
<note xml:id="note-L12F25" dots="1" dur="2" oct="5" pname="a" accid.ges="n" />
<rest xml:id="rest-L15F25" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F23N1" n="3">
<layer xml:id="layer-L11F23N1" n="1">
<note xml:id="note-L12F23" dots="1" dur="2" oct="5" pname="f" accid.ges="s" />
<rest xml:id="rest-L15F23" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F21N1" n="4">
<layer xml:id="layer-L11F21N1" n="1">
<note xml:id="note-L12F21" dots="1" dur="2" oct="5" pname="e" accid.ges="s" />
<rest xml:id="rest-L15F21" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F19N1" n="5">
<layer xml:id="layer-L11F19N1" n="1">
<note xml:id="note-L12F19" dots="1" dur="2" oct="5" pname="c" accid.ges="s" />
<rest xml:id="rest-L15F19" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F17N1" n="6">
<layer xml:id="layer-L11F17N1" n="1">
<mRest xml:id="mrest-0000001144535076" />
</layer>
</staff>
<staff xml:id="staff-L11F15N1" n="7">
<layer xml:id="layer-L11F15N1" n="1">
<mRest xml:id="mrest-0000001996658111" />
</layer>
</staff>
<staff xml:id="staff-L11F13N1" n="8">
<layer xml:id="layer-L11F13N1" n="1">
<mRest xml:id="mrest-0000000222504655" />
</layer>
</staff>
<staff xml:id="staff-L11F11N1" n="9">
<layer xml:id="layer-L11F11N1" n="1">
<note xml:id="note-L12F11" dots="1" dur="2" oct="2" pname="b" accid.ges="n" />
<rest xml:id="rest-L15F11" dur="4" />
</layer>
</staff>
<staff xml:id="staff-L11F9N1" n="10">
<layer xml:id="layer-L11F9N1" n="1">
<note xml:id="note-L12F9" dots="1" dur="2" oct="3" pname="b" accid.ges="n" />
<note xml:id="note-L14F9" dur="8" oct="4" pname="f" grace="unacc" accid.ges="s" />
<beam xml:id="beam-L15F9-L16F9">
<note xml:id="note-L15F9" dots="1" dur="8" oct="4" pname="e" accid.ges="n" />
<note xml:id="note-L16F9" dur="16" oct="4" pname="d" accid.ges="s" />
</beam>
</layer>
</staff>
<staff xml:id="staff-L11F7N1" n="11">
<layer xml:id="layer-L11F7N1" n="1">
<note xml:id="note-L12F7" dots="1" dur="2" oct="3" pname="b" accid.ges="n" />
<note xml:id="note-L13F7" dur="8" oct="4" pname="f" grace="unacc" accid.ges="s" />
<beam xml:id="beam-L15F7-L16F7">
<note xml:id="note-L15F7" dots="1" dur="8" oct="4" pname="e" accid.ges="n" />
<note xml:id="note-L16F7" dur="16" oct="4" pname="d" accid.ges="s" />
</beam>
</layer>
</staff>
<staff xml:id="staff-L11F5N1" n="12">
<layer xml:id="layer-L11F5N1" n="1">
<note xml:id="note-L12F5" dots="1" dur="2" oct="3" pname="b" accid.ges="n" />
<beam xml:id="beam-L15F5-L16F5">
<note xml:id="note-L15F5" dots="1" dur="8" oct="3" pname="b" accid.ges="n" />
<note xml:id="note-L16F5" dur="16" oct="4" pname="c" accid="n" />
</beam>
</layer>
</staff>
<staff xml:id="staff-L11F3N1" n="13">
<layer xml:id="layer-L11F3N1" n="1">
<note xml:id="note-L12F3" dots="1" dur="2" oct="2" pname="b" accid.ges="n" />
<beam xml:id="beam-L15F3-L16F3">
<note xml:id="note-L15F3" dots="1" dur="8" oct="3" pname="g" accid.ges="s" />
<note xml:id="note-L16F3" dur="16" oct="3" pname="a" accid.ges="n" />
</beam>
</layer>
</staff>
<staff xml:id="staff-L11F1N1" n="14">
<layer xml:id="layer-L11F1N1" n="1">
<note xml:id="note-L12F1" dots="1" dur="2" oct="2" pname="b" accid.ges="n" />
<rest xml:id="rest-L15F1" dur="4" />
</layer>
</staff>
<fermata xml:id="fermata-L12F27" staff="1" startid="#note-L12F27" place="above" />
<dynam xml:id="dynam-L15F28" staff="1" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F25" staff="2" startid="#note-L12F25" place="above" />
<dynam xml:id="dynam-L15F26" staff="2" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F23" staff="3" startid="#note-L12F23" place="above" />
<dynam xml:id="dynam-L15F24" staff="3" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F21" staff="4" startid="#note-L12F21" place="above" />
<dynam xml:id="dynam-L15F22" staff="4" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F19" staff="5" startid="#note-L12F19" place="above" />
<dynam xml:id="dynam-L15F20" staff="5" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F11" staff="9" startid="#note-L12F11" place="above" />
<dynam xml:id="dynam-L15F12" staff="9" tstamp="4.000000">pp</dynam>
<fermata xml:id="fermata-L12F9" staff="10" startid="#note-L12F9" place="above" />
<dynam xml:id="dynam-L15F10" staff="10" tstamp="4.000000">pp</dynam>
<slur xml:id="slur-L14F9-L16F9N1" staff="10" startid="#note-L14F9" endid="#note-L16F9" />
<fermata xml:id="fermata-L12F7" staff="11" startid="#note-L12F7" place="above" />
<dynam xml:id="dynam-L15F8" staff="11" tstamp="4.000000">pp</dynam>
<slur xml:id="slur-L13F7-L16F7N1" staff="11" startid="#note-L13F7" endid="#note-L16F7" />
<fermata xml:id="fermata-L12F5" staff="12" startid="#note-L12F5" place="above" />
<dynam xml:id="dynam-L15F6" staff="12" tstamp="4.000000">pp</dynam>
<slur xml:id="slur-L15F5-L16F5N1" staff="12" startid="#note-L15F5" endid="#note-L16F5" />
<fermata xml:id="fermata-L12F3" staff="13" startid="#note-L12F3" place="above" />
<dynam xml:id="dynam-L15F4" staff="13" tstamp="4.000000">pp</dynam>
<slur xml:id="slur-L15F3-L16F3N1" staff="13" startid="#note-L15F3" endid="#note-L16F3" />
<fermata xml:id="fermata-L12F1" staff="14" startid="#note-L12F1" place="above" />
<dynam xml:id="dynam-L15F2" staff="14" tstamp="4.000000">pp</dynam>
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>(still needs fermatas added to whole-measure rests).
lpugin
commented
6 years ago I think we need some clarification in the guidelines about it. To me it still appears to be double encoding but we can very well clarify this. However, this clarification will also need to be explicit in the data. Trying to analyse the content and guess what to do is not a viable option for generic tools. This is similar to what we had with accid.ges, with the conclusion that we need information to be given in the encoding description. Otherwise we will keep chasing new cases, and keep doing what Craig has just done with more if / else if / else if / else if / ... , with the risk to have knowledge about it buried in Verovio's code and GitHub issues. For example, somebody can come up with additional case with a piece containing one single analytical fermata that should not be rendered. How can this be detected?
I am not particularly happy with the current double rendering of Verovio, I would like to have this fixed too. So I also feel that the best thing to do for now is to disable the rendering of @fermata and @tie (any other?) until we come up with a clearer plan what to do with analytical encoding. That is, mainly: should analytical encoding be ignored for rendering? and if not, how can we encode the information the tools need to know what to do about it?
It this OK for now?
Along the same lines, the idea to systematically convert @tie to <tie> (https://github.com/rism-ch/verovio/issues/709#issuecomment-335767395) should be put on hold, I think.
lpugin
commented
6 years ago PS Obviously @accid and @artic should be included as well.
craigsapp
commented
6 years ago That sounds reasonable for now. Ideally pairings of attribute/elements should be identified automatically, and if there are both for the same feature, then use the element version for rendering and ignore the attribute version. Particularly hand-encodings of MEI (done by crazy people 😉 ), will utilize attributes since this makes the encoding more compact and faster to type in.
As a reminder, in the MEI-to-humdrum converter, I had to build a reverse index for startids and endids in order to deal with floating elements:
This code builds databases of elements which refer to a given ID (there is a separate database for startids and endids, and I currently don't deal with plists yet). I use this for attaching floating elements to notes, and it was easy to deal with @fermata/<fermata> encodings with this database as well: if a @fermata is found on a note, and a <fermata> is attached to the note, then ignore the @fermata; otherwise, use the single @fermata or <fermata> related to the note. I currently don't convert @tie or @slur information, but it would be done in a similar way.
Here is an example of analytic fermatas that should not be rendered:
Notes in the alto/tenor parts do not have visible fermatas since it is graphically obvious when they are needed, and a visible fermata on the alto/tenor notes would clutter the notation. But for analysis purposes, attaching an analytic fermata to all notes is important for doing phrase analysis.
The floating fermata could contain a @plist saying that it applies to both notes. In this case there would be one fermata linked to two separate note attributes.
Here is the same music where all fermatas are rendered:
lpugin
commented
6 years ago OK. To sumarize
| 1.1.6 | 2.0.0 | |
|---|---|---|
@accid |
rendered via conversion to <accid> |
ignored |
@artic |
rendered via conversion to <artic> |
ignored |
@fermata |
rendered | ignored |
@tie |
rendered (not MIDI) | ignored |
If eventually we decide that analytical information can be rendered by providing encoded information about it, then we can add a method that internally converts analytical encoding to corresponding visual element (e.g, <fermata>). But this should not be the default behaviour, I guess but be enabled only with corresponding markup (otherwise with the case we have we would end-up with triple fermatas... ;-) . Something like?
<domainsDesc rendAnalytic="true"/>With this we keep a high encoding flexibility: having visual information, having both visual and analytical information, having only analytical information and there the option to specify if it should be used for rendering. And this with the only requirement to encode that later case assuming analytical information is not double encoding of the visual rendering (unless specify otherwise).
rettinghaus
commented
6 years ago I would prefer to drop support for analytical attributes completely once and for all. With an XSLT attributes could be transformed into elements easily. So for rendering one could use Verovio together with this XSLT. This is a simple and clean solution. Otherwise there could arise problems with re-exporting MEI: e.g. keep the attributes, too?
lpugin
commented
6 years ago What is important to me is to have roles clarified. As I said, having the option to have Verovio rendering analytical information should be only an opt-in option which will be nice to have as a second step. Once roles are clarified, this will be easy to handle, and so will the re-export. I will expect a visual element added from analytical markup for rendering not be exported. (In the same way @accid currently remains @accid in re-exported MEI. And this definitely discards the idea of converting alternate encoding, mentioned before, because it is now a different approach.)
pe-ro
commented
6 years ago By agreeing with @craigsapp, I didn't mean that analytical attributes should always be rendered. I was just pointing out that they are "about" the same thing as the elements. In spite of my confusing comments, I think you guys have come up with a reasonable plan of attack.
lpugin
commented
6 years ago Yes, I think we agree they should not always be rendered. And I think we also agree that disabling their rendering (ignoring them) is a good first step.
craigsapp
commented
6 years ago | 1.1.6 | 2.0.0 | |
|---|---|---|
@accid |
rendered via conversion to <accid> |
ignored |
@artic |
rendered via conversion to <artic> |
ignored |
@fermata |
rendered | ignored |
@tie |
rendered (not MIDI) | ignored |
So you are saying that note@accid is analytic? In what sense has it ever been analytic? Ignoring it would be equivalent to saying that 1 == 0, since it is explicitly a visual (rendering) attribute, and nearly every single MEI file currently in existence would not be rendered correctly in verovio.
Also <artic> is stored as a child element of <note> so it is trivial to find when processing a note. A <fermata> is not allowed as a child element of a note, so linking them together is not a trivial process since there is no direct backlink to a startid reference (which is why I have to generate them before converting MEI into Humdrum data). Most analytic processes will be note-centric, making analytic processing of <fermata> in a different class from @accid or @artic.
For this graphical representation of music:
Here is the Humdrum representation:
!!!COM: Bach, Johann Sebastian
!!!OTL@@DE: Aus meines Herzens Grunde
!!!OTL@EN: From the Depths of My Heart
!!!SCT: BWV 269
**kern **kern
*clefF4 *clefG2
*k[f#] *k[f#]
*M3/4 *M3/4
*^ *^
*Itenor *Ibass *Isoprn *Ialto
4B 4GG 4g 4d
=1 =1 =1 =1
4B 4G 2g 4d
8cL 4E . 4e
8BJ . . .
4A 4F# 4dd 4d
=2 =2 =2 =2
4G 4G 4.b 2d
4F# 4D . .
. . 8a .
4G 4E 4g 4B
=3 =3 =3 =3
8cL 4C 4.g 8eL
8BJ . . 8d
4c 8BBL . 8e
. 8AAJ 8a 8f#J
4d 4GG 4b 4g
=4 =4 =4 =4
2d;y 2D; 2a; 2f#;y
*v *v * *
* *v *v
*- *-The y character makes the fermata "invisible" from the renderers point of view, but strictly speaking it means an "invisible symbol; unprinted note-, rest-, or barline-attribute, but logically implied". In other words, there is a logical/analytic fermata on this note, but it is not rendered. There can be difference between a "logical" feature and a "visual" attribute, but am not aware of any "analytic" attribute which is not a "logical" feature, unless I misunderstand what the purpose categorizing attributes as "analytic" means.
If you want to ignore note@fermata for rendering purpose, then its attribute values should allow for an "implied" concept similar to Humdurm **kern data does with the y operator. Using an attribute value fermata="above|below" makes it look like a rendering attribute and not an analytic attribute.
I currently do not translate analytic fermatas into MEI:
<measure xml:id="measure-L29" right="invis" n="4">
<staff xml:id="staff-L29F3N1" n="1">
<layer xml:id="layer-L29F3N1" n="1">
<note xml:id="note-L30F3" dur="2" oct="4" pname="a" accid.ges="n" />
</layer>
<layer xml:id="layer-L29F4N2" n="2">
<note xml:id="note-L30F4" dur="2" oct="4" pname="f" accid.ges="s" />
</layer>
</staff>
<staff xml:id="staff-L29F1N1" n="2">
<layer xml:id="layer-L29F1N1" n="1">
<note xml:id="note-L30F1" dur="2" oct="4" pname="d" accid.ges="n" />
</layer>
<layer xml:id="layer-L29F2N2" n="2">
<note xml:id="note-L30F2" dur="2" oct="3" pname="d" accid.ges="n" />
</layer>
</staff>
<fermata xml:id="fermata-L30F3" staff="1" startid="#note-L30F3" place="above" />
<fermata xml:id="fermata-L30F2" staff="2" startid="#note-L30F2" place="below" />
</measure>Firstly of course since note@fermata will be rendered in verovio, and secondly since there is no note@fermata="implied|invis|true" value for the fermata attribute. Eventually I might be adding fermata@plist for the visible fermata to link it explicitly to both notes.
Ideally pairings of attribute/elements should be identified automatically, and if there are both for the same feature, then use the element version for rendering and ignore the attribute version.
You seem mainly interested in the programming aspect: cut out the dual expressions of data to cut development costs. There would not be a tolerance for using an XSLT pre-filter unless it is provided with the verovio toolkit and was able to run in the browser, but even then that would slow down the rendering process and/or require more server-side processing.
lpugin
commented
6 years ago What I am not willing to do it MEI data analysis in order to guess what needs to be rendered and what does not. This will remain highly inefficient and highly issue prone. I am not precluding note@fermata to be rendered, but under the condition that the instruction for rendering it is given explicitly, either in the data or alternatively through a parameter.
craigsapp
commented
6 years ago I am not precluding note@fermata to be rendered, but under the condition that the instruction for rendering it is given explicitly, either in the data or alternatively through a parameter.
That is what the "above" value means for note@fermata. Or do you mean add an attribute note@fermata.rend="true"?
What I am not willing to do it MEI data analysis in order to guess what needs to be rendered and what does not. This will remain highly inefficient and highly issue prone.
I will allow you to do whatever you want, as I can easily adjust the humdrum-to-MEI converter to be verovio-compliant (that is why the converter is built into verovio :-). I can already not create note@artic inside verovio since you have already disabled it. I currently use <fermata> for notes, but am still using rest@fermata for some reason, although that can be fixed quickly since it should be the same as for notes. The mei-to-humdrum converter is built outside of verovio, since I want to be able to convert non-verovio-compliant MEI files into humdrum and from there back to a verovio-compliant MEI file (which seems will soon cover all currently existing MEI files :-).
If note@slur and note@tie are guaranteed to not be rendering information, then I can add them to the humdrum-to-mei translation, since this is the form of ties/slurs that I start with in Humdrum, but I convert them to floating elements in MEI since this form of slurs/ties are the only ones that will be rendered.
But for non-floating elements (@accid and @artic), these were never analytic attributes, so it seems that you are rather wanting to clean up MEI for programmatic implentations, and secondarily to make the mapping between SVG and the source MEI data more direct. In other words, independent graphical objects in SVG map to elements in MEI.
The original intention was to use the attribute forms if they required/had no rendering information, and to use the child element if more rendering parameters are required, such as:
<note artic="acc"/>versus
<note>
<artic artc="acc" place="below"/>
</note>The first one says that there is an accidental, and it is up to the typesetter to determine how to render it. The second says that the renderer should place the accent below the note (and prevent it from being placed above the note).
Similarly for note@accid/note/accid:
<note accid="f"/>versus
<note>
<accid accid="f" func="edit"/>
</note>The first encoding says that there is a visual accidental for the note, while the second one says that there is a visual accidental which functions as an editorial addition to the score.
This will remain highly inefficient and highly issue prone.
So how can the above examples become error prone? If there is a accid/artic child element, then use that and ignore the attribute version. If there is no element, use the attribute equivalent if it is present. Also such data treatment could hardly be called inefficient.
For slurs, ties, fermatas and other floating elements you have a better point of argument. It is computationally much more inefficient to make the link between note@fermata and fermata. Also the fermata may analytically affect multiple notes occurring at the same time in different layers on the same staff or system.
What I am not willing to do it MEI data analysis in order to guess what needs to be rendered and what does not.
In this case there is no "guessing". The @artic/artic behavior would work similar for the @fermata/fermata case: if there is a <fermata> then it has priority, and use @fermata otherwise. However this is computationally complex (but not too much, and I also give the code necessary to do that above :-)
@slur and @tie are in yet another category and these are truly much more complicated to deal with than artic/accid or fermata categories.
lpugin
commented
6 years ago Since there is no urgent issue to be solved with the current handling of @accid and @artic we can leave them as is for now and only change @fermata and @tie. For the possible values of @fermata the discussion should happen in the MEI repo / list.
For the record :
if there is a
then it has priority, and use @fermata otherwise.
I don't agree with this solution. If you have a case where there is an analytical fermata @fermata but nothing should be rendered (for whatever reason), Verovio will end up showing a fermata where you do not want one.
pe-ro
commented
6 years ago I don't intend to muddy the water here, but I wonder if we're not taking more steps toward "independent graphical objects in SVG map[ping] to elements in MEI" (paraphrasing @craigsapp). It seems to me this has been the inexorable direction we've been moving in for quite some time. We've had this discussion at various times, centered on different aspects, over the last year or two, at least. So, I'm just floating this idea to get your general opinion -- should we think about moving some (but not all) attributes on <note> to elements?
The following encoding --
<note>
<accid/>
<artic/>
<dot/>
<fermata/>
<head/>
<stem/>
<verse>
<syl>
</verse>
</note>represents independently render-able entities as elements. Doing this will result in greater conceptual simplicity and easier rendition. In the case of @dots / <dot> it will also increase the level of detail of the encoding. For example, the <dot> element can carry attributes like @ho, @vo, @color, etc. that provide more fine-grained control over the data.
Render-able slurs and ties will still be encoded in stand-off elements. And data that stands in a one-to-one relationship with the note, for example pitch, duration, "cue-ness", can remain in attributes for the time-being. On the other hand, we may want to think about creating <pitch> and <duration> elements as well. Doing so would provide a way of dealing with this info when it differs between domains, for example --
<note>
<pitch func="written" pname="a/">
<pitch func="performed" pname="b"/>
</note> The current attributes for render-able stuff (@accid, @artic, @colored, @fermata, @tie, and so on) may become analytical (for some definition of that word) or may disappear in "official/canonical" MEI; that is, starting in the so-called "Basic" customization. Their disappearance, however, doesn't mean that they can't be revived in a "hand-encoding customization", the use of which implies a transformation to canonical MEI for rendering. There may also be a corresponding transformation from the element-centric (canonical) to the attribute-centric (hand-coding) model. Clearly separating these two encoding approaches will eventually result in greater clarity.
craigsapp
commented
6 years ago I don't agree with this solution. If you have a case where there is an analytical fermata @fermata but nothing should be rendered (for whatever reason), Verovio will end up showing a fermata where you do not want one.
That is because there is no real analytic fermata in MEI yet. To match @accid behavior (or @dur), it should be called @fermata.ges, as @fermata is clearly a visual attribute in the same way that @accid is.
pe-ro
commented
6 years ago I suppose you could call this a "war on attributes", which is what it was called when a similar approach was undertaken in TEI.
It does move MEI more in the direction of MusicXML, but that's not a bad thing in and of itself. We'll just plan on doing it better than MusicXML did.
craigsapp
commented
6 years ago It does move MEI more in the direction of MusicXML, but that's not a bad thing in and of itself. We'll just plan on doing it better than MusicXML did.
I wonder how it will affect file size and processing memory...
lpugin
commented
6 years ago @pe-ro : we can have this discussion, but probably for version 5.0 with an in-person meeting to start it?
pe-ro
commented
6 years ago @craigsapp, any increase in the number of nodes (elements or attributes) requires more memory.
pe-ro
commented
6 years ago @lpugin, certainly.
kepper
commented
6 years ago are we trying to throw out the baby with the bath water again? If we want to discuss this, a ticket in the Verovio repo is definitely the wrong place. Let's stop it here, right now. If someone has the urgent need for this discussion, please start it again on MEI-L, with some good arguments for having that discussion…
just my 2c
Am 30.10.2017 um 21:18 schrieb pe-ro notifications@github.com:
I suppose you could call this a "war on attributes", which is what it was called when a similar approach was undertaken in TEI.
It does move MEI more in the direction of MusicXML, but that's not a bad thing in and of itself. We'll just plan on doing it better than MusicXML did.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
pe-ro
commented
6 years ago Of course, the proper place for a full discussion of this proposal is in the MEI repo, but I was just floating an idea. Since it is related to the issue at hand, here is just as good a place as any to introduce it.
I disagree that this is throwing out the baby with the bath water. I see it as a reasonable solution to the confusion surrounding rendition of the current attribute vs. element encoding options. In any case, I'll be quiet now and wait for the issue to arise again, as (vampire-like) it surely will.
craigsapp
commented
6 years ago are we trying to throw out the baby with the bath water again?
I wonder where this encoding file comes from?:
http://www.verovio.org/examples/downloads/Hummel_Concerto_for_trumpet.mei
I looked into Ein feste Burg from the same data set which had numerous problems and also questionable encodings, such as the same fermata encoded in both the attribute and element form. So anything which cannot be handled by verovio I will be questioning as to whether it is correct, incorrect or deprecated. If it is incorrect or deprecated, then I am wondering why it is still in the sample-encoding examples.
This is only the second piece I have gotten to in the sample-encodings data set. Not too much problem other than this fermata, but there is a weird encoding of tuplets by using a floating element tupletSpan as well as duplicate information in note@tuplet attributes. Obviously these were converted from MusicXML a while ago, but it seems like you(s) might like to provide more canonical up-to-date samples for people to reference. And having it compatible with verovio rendering for the complete-work encodings would be useful (either by fixing the encoding or fixing verovio).
Once I finish my mei-to-humdrum converter I can do a round-trip to Humdrum an back to fix most of these older-style encodings, including the weird problem of floating elements being placed in the wrong measure in Ein feste Burg, which I handle gracefully but verovio chokes on. I can imagine you not liking that, but if not, then write a XSLT program to fix problems or deprecated encoding styles...
<p>Transcoded from a MusicXML version 2.0 file on 2011-10-13 using the <ref target="#xsl_mxl2mei_2.2.3">musicxml2mei</ref> stylesheet. </p>
<date isodate="2011-10-13"/>
<p> Cleaned up MEI file automatically using <ref target="#xsl_ppq">ppq.xsl</ref>. </p>
<date isodate="2011-10-22"/>
<p> Cleaned up MEI file automatically using <ref target="#xsl_header">Header.xsl</ref>. </p>
<date isodate="2011-12-01"/>
<p>Converted to MEI 2013 using mei2012To2013.xsl, version 1.0 beta</p>
<date isodate="2014-05-30"/>
<p>Converted to version 3.0.0 using mei2013To2015.xsl, version 1.0 beta</p>
<date isodate="2015-10-15"/>OK, thinking more about it seems that a reasonable first step for Verovio is to remove code duplication for analytical markup (currently @fermata and @tie). This will fix half of the issue because then we will always have the same rendering. This means not to disable straight away the rendering of this analytical markup, of course. Eventually, for projects that use both, we can think of an encoding description that Verovio can take into account not to render them. (An option passed to Verovio would also do the job equally well.) In the meantime, this means that Verovio will still render them twice, and I will fix the examples used in the Verovio repository accordingly.
We can discuss what to do for the MEI repository examples in the MEI repository (and not here).
lpugin
commented
6 years ago Fermata and tie attributes are now internally treated as elements and rendered (116fe318fb54b33f9abfc561699f9cee37343905). I am closing the issue and we can add an option later if somebody needs to have them not rendered.
In measure 42 of this file:
http://www.verovio.org/examples/downloads/Hummel_Concerto_for_trumpet.mei
verovio displays two fermatas where there should only be one:
MEI test data:
Also, the dynamic markings in this measure are encoded a bit unusually. Ideally they would have a
@tstamp="4"with a horizontal offset to the left. And I doubt that the parts with rests would show dynamics on the rests in an urtext edition (probably a system-level dynamic originally in Finale which then became multiple staff-level dynamics in the exported MusicXML).