rism-digital / verovio

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

the slur can become excessively long #3753

Closed dajun-TT closed 2 months ago

dajun-TT commented 2 months ago

Describe the problem Sometimes, the slur can become excessively long, (as picture show below)stretching across many measures and passing through notes, which severely affects the readability of the sheet music. image

Expected behavior image

craigsapp commented 2 months ago

Most likely this is an error in the converter from MusicXML into MEI which is the internal format of verovio.

It is also possible that the MusicXML export from Musescore (or Sibelius or Dorico, etc.) is not correct. If the input data is incorrect, then verovio cannot be expected to convert or display it properly.

If you are using Musescore, then you can also export directly to MEI, so you must give the starting data to make this more clear where and how the input data was created, and this will in turn give a clue for where the problem occurs, which is definitely not in the final conversion of MEI into SVG with verovio.

In other words, this is not a rendering problem in verovio, but rather a data error: either in the originating program's output to MusicXML or MEI, or the problem is in the verovio import of MusicXML.

First do this test: load your MusicXML file back into the program that created it. If the problem occurs in your notation program with the reloaded MusicXML data, then the problem is in your program's export of MusicXML, and not with verovio's import of MusicXML. In that case you need to report the MusicXML export problem to your music typesetting program's developers rather than to the verovio developers.

The problem is related to a non-optimal encoding of a tie between notes in two different layers/voices. The tie that is causing problems starts on a note in voice/layer 2 (eighth note D5) and ends on a note in voice/layer 1 (half note D5). Either the exporting program is not adding the tie-end to the exported MusicXML (which can be verified by loading the MusicXML export back into the original program), or the import of MusicXML into verovio is confused because the tie end in voice/layer 1 is actually given in the MusicXML data sequence before the tie start in voice/layer 2.

In the original program, it would be better to start and end the tie on notes in the second voice/layer rather than starting in voice/layer 2 and ending it in voice/layer 1. This would avoid the problem, although if the MusicXML-to-MEI converter inside of verovio is processing this wrong, it would be good to fix.

Here is an example MEI file and resulting notation showing that verovio can handle cross voice/layer ties:

Screenshot 2024-09-01 at 7 56 46 PM

The first measure has a tie that starts in layer 2 (blue notes) and ends in a layer 1 note (red notes). I colored the tie in purple that does this:

Screenshot 2024-09-01 at 7 58 36 PM

A simpler encoding would be to place that tie end on the note in layer 2:

Screenshot 2024-09-01 at 7 58 46 PM
Click here to view MEI data for the above example notation. ```xml </titleStmt> <pubStmt /> </fileDesc> <encodingDesc> <appInfo> <application isodate="2024-09-01T19:42:11" version="4.3.0-dev-6e49bf7-dirty"> <name>Verovio</name> <p>Transcoded from Humdrum</p> </application> </appInfo> </encodingDesc> </meiHead> <music decls="#work1_encoded"> <body> <mdiv xml:id="m7u9myv"> <score xml:id="s1whuv9s"> <scoreDef xml:id="syo1ia6" tempo.dist="3.0000vu"> <staffGrp xml:id="s1en7h5b"> <staffDef xml:id="staffdef-L1F1" n="1" lines="5"> <clef xml:id="cghvpia" shape="G" line="2" /> </staffDef> </staffGrp> </scoreDef> <section xml:id="section-L1F1"> <measure xml:id="measure-L1" n="1"> <staff xml:id="staff-L1F1" n="1"> <layer xml:id="layer-L1F1N1" n="1"> <note xml:id="note-L5F1" dur="8" oct="5" pname="d" color="red" accid.ges="n" /> <note xml:id="note-L6F1" dur="2" oct="5" pname="d" color="red" accid.ges="n" /> <note xml:id="note-L7F1" dur="2" oct="5" pname="d" color="red" accid.ges="n" /> </layer> <layer xml:id="layer-L1F2N2" n="2"> <chord xml:id="chord-L5F2" dur="8"> <note xml:id="note-L5F2S1" oct="4" pname="f" color="blue" accid.ges="n" /> <note xml:id="note-L5F2S2" oct="5" pname="c" color="blue" accid.ges="n" /> <note xml:id="note-L5F2S3" oct="5" pname="d" color="blue" accid.ges="n" /> </chord> <chord xml:id="chord-L6F2" dur="2"> <note xml:id="note-L6F2S1" oct="4" pname="f" color="blue" accid.ges="n" /> <note xml:id="note-L6F2S2" oct="5" pname="c" color="blue" accid.ges="n" /> <note xml:id="note-L6F2S3" oct="5" pname="d" color="blue" accid.ges="n" /> </chord> <note xml:id="note-L7F2" dur="2" oct="4" pname="f" color="blue" accid.ges="n" /> </layer> </staff> <tie xml:id="tie-L5F2S3-L7F1S1" color="purple" startid="#note-L5F2S3" endid="#note-L6F1" /> <tie xml:id="tie-L5F2S1-L6F2S1" color="blue" startid="#note-L5F2S1" endid="#note-L6F2S1" /> <tie xml:id="tie-L5F2S2-L6F2S2" color="blue" startid="#note-L5F2S2" endid="#note-L6F2S2" /> </measure> <measure xml:id="measure-L8" n="2"> <staff xml:id="staff-L8F1N1" n="1"> <layer xml:id="layer-L8F1N1" n="1"> <note xml:id="note-L9F1" dur="8" oct="5" pname="d" color="red" accid.ges="n" /> <note xml:id="note-L10F1" dur="2" oct="5" pname="d" color="red" accid.ges="n" /> <note xml:id="note-L11F1" dur="2" oct="5" pname="d" color="red" accid.ges="n" /> </layer> <layer xml:id="layer-L8F2N2" n="2"> <chord xml:id="chord-L9F2" dur="8"> <note xml:id="note-L9F2S1" oct="4" pname="f" color="blue" accid.ges="n" /> <note xml:id="note-L9F2S2" oct="5" pname="c" color="blue" accid.ges="n" /> <note xml:id="note-L9F2S3" oct="5" pname="d" color="blue" accid.ges="n" /> </chord> <chord xml:id="chord-L10F2" dur="2"> <note xml:id="note-L10F2S1" oct="4" pname="f" color="blue" accid.ges="n" /> <note xml:id="note-L10F2S2" oct="5" pname="c" color="blue" accid.ges="n" /> <note xml:id="note-L10F2S3" oct="5" pname="d" color="blue" accid.ges="n" /> </chord> <note xml:id="note-L11F2" dur="2" oct="4" pname="f" color="blue" accid.ges="n" /> </layer> </staff> <tie xml:id="tie-L9F2S1-L10F2S1" color="blue" startid="#note-L9F2S1" endid="#note-L10F2S1" /> <tie xml:id="tie-L9F2S2-L10F2S2" color="blue" startid="#note-L9F2S2" endid="#note-L10F2S2" /> <tie xml:id="tie-L9F2S3-L10F2S3" color="blue" startid="#note-L9F2S3" endid="#note-L10F2S3" /> </measure> </section> </score> </mdiv> </body> </music> </mei> ``` </details> <p>As with the previous issues you have submitted, you must provide a complete (short) example that demonstrates the problem, similar to the MEI example I provide above. If you do not provide this data, then the problem cannot be fix.</p> <hr /> <p>There is also a separate issue with ties like this in piano music (that is beyond the scope of this issue, but is related). In piano music there is only one note played on D5, so ideally in the MEI data there will be additional information that indicates that both D5's in layer 1 and 2 tie to the ending note in layer 1. </p> <p>There should be a tie from the layer 1 to layer 2 added as an invisible tie and probably some indication that the two ties are <code>@sameas</code> so that MIDI output will produce one note rather than produce two note attacks on the starting notes. Currently both measures in the above example produce incorrect MIDI output because of this problem: in the first measure there are three MIDI notes: two note attacks on the eighth notes, and an additional third note attack for the blue note for the half note at the ending tie. In the second measure there are two note attacks on the eighth note, but there is also a third note attack on the red note. There should be only one MIDI note instead of three in both cases.</p> <p>This is complicated to deal with in conversion from MusicXML, as the converter would have to automatically detect that this is keyboard music, where only one note at a time can sound. It would also be similarly complicated to do this analysis in the MEI-to-MIDI conversion, although it might be good to add such analysis capability to verovio to adjust the MEI data for keyboard music to add the invisible ties and/or <code>@sameas</code> information.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/craigsapp"><img src="https://avatars.githubusercontent.com/u/3487289?v=4" />craigsapp</a> commented <strong> 2 months ago</strong> </div> <div class="markdown-body"> <p>Possibly useful to fix if it is a MusicXML-to-MEI conversion limitation.</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>