Quintuplet starting with a rest note followed by another tuplet -> rendering error

[Suppan]

MEI (error):

                  <measure xml:id="measure-L1" right="end">
                     <staff xml:id="staff-L2F1" n="1">
                        <layer xml:id="layer-L1F1N1" n="1">
                           <tuplet xml:id="tuplet-L3F1-L7F1" num="5" numbase="4" num.format="count">
                              <rest xml:id="rest-L3F1" dur="16" />
                              <beam xml:id="beam-L4F1-L10F1">
                                 <note xml:id="note-L4F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L5F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L6F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L7F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <tuplet xml:id="tuplet-L8F1-L10F1" num="3" numbase="2" num.format="count">
                                    <note xml:id="note-L8F1" dur="8" oct="4" pname="d" accid.ges="n" />
                                    <note xml:id="note-L9F1" dur="8" oct="4" pname="d" accid.ges="n" />
                                    <note xml:id="note-L10F1" dur="8" oct="4" pname="d" accid.ges="n" />
                                 </tuplet>
                              </beam>
                           </tuplet>
                        </layer>
                     </staff>
                  </measure>

SVG (error):

Manually changing the position of </tuplet> and </beam> elements in MEI gives me the correct output:

MEI (correct)

                  <measure xml:id="measure-L1" right="end">
                     <staff xml:id="staff-L2F1" n="1">
                        <layer xml:id="layer-L1F1N1" n="1">
                           <tuplet xml:id="tuplet-L3F1-L7F1" num="5" numbase="4" num.format="count">
                              <rest xml:id="rest-L3F1" dur="16" />
                              <beam xml:id="beam-L4F1-L10F1">
                                 <note xml:id="note-L4F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L5F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L6F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 <note xml:id="note-L7F1" dur="16" oct="4" pname="d" accid.ges="n" />
                                 </beam>
                                 </tuplet>
                                 <beam xml:id="beam-L-L8F1-L10F1">
                                 <tuplet xml:id="tuplet-L8F1-L10F1" num="3" numbase="2" num.format="count">
                                    <note xml:id="note-L8F1" dur="8" oct="4" pname="d" accid.ges="n" />
                                    <note xml:id="note-L9F1" dur="8" oct="4" pname="d" accid.ges="n" />
                                    <note xml:id="note-L10F1" dur="8" oct="4" pname="d" accid.ges="n" />
                              </beam>
                           </tuplet>
                        </layer>
                     </staff>
                  </measure>

SVG (correct):

[craigsapp]

Autobeam is causing a complication by not using two beams instead of one:

[View in VHV]

This is generating MEI data which is incorrect because I do not handle such cases (that I cam remember) yet:

Here is the MEI conversion of the notes:

         <tuplet xml:id="tuplet-L3F1-L7F1" num="5" numbase="4" num.format="count">
          <rest xml:id="rest-L3F1" dur="16" />
          <beam xml:id="beam-L4F1-L10F1">
           <note xml:id="note-L4F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L5F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L6F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L7F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <tuplet xml:id="tuplet-L8F1-L10F1" num="3" numbase="2" num.format="count">
            <note xml:id="note-L8F1" dur="8" oct="4" pname="d" accid.ges="n" />
            <note xml:id="note-L9F1" dur="8" oct="4" pname="d" accid.ges="n" />
            <note xml:id="note-L10F1" dur="8" oct="4" pname="d" accid.ges="n" />
           </tuplet>
          </beam>
         </tuplet>

The problem is that the first <tuplet> should end just before the second one:

         <tuplet xml:id="tuplet-L3F1-L7F1" num="5" numbase="4" num.format="count">
          <rest xml:id="rest-L3F1" dur="16" />
          <beam xml:id="beam-L4F1-L10F1">
           <note xml:id="note-L4F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L5F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L6F1" dur="16" oct="4" pname="d" accid.ges="n" />
           <note xml:id="note-L7F1" dur="16" oct="4" pname="d" accid.ges="n" />
           </tuplet>
           <tuplet xml:id="tuplet-L8F1-L10F1" num="3" numbase="2" num.format="count">
            <note xml:id="note-L8F1" dur="8" oct="4" pname="d" accid.ges="n" />
            <note xml:id="note-L9F1" dur="8" oct="4" pname="d" accid.ges="n" />
            <note xml:id="note-L10F1" dur="8" oct="4" pname="d" accid.ges="n" />
           </tuplet>
          </beam>
         

But then the problem is that the <tuplet> is starting outside of the beam (due to the rest which is outside of the beam), and that quintuplet is ending inside of the beam. This is invalid XML data because overlapping elements are not possible. When I convert to MEI inside of Verovio, I am intending the second case, but verovio (pugiXML) refuses to do that and generates the top example which is correct XML structure, but the musical content is incorrect, so verovio is technically correct according to the data it is provided, which is incorrect: there is a quintuplet something on the entire contents, and a nested triplet inside the beam.

If you want the single beam, then that gets complicated due to the crossing hierarchies of the tuplet and beam. But your corrected version has to beams, which is an easier problem to fix. Manually adding the beam endings will fix the problem:

[View in VHV]

When the beam endings are given explicitly as in the above example, autobeam will not try to alter the existing beams. If you want to have some beams fixed manually and others automatically, that is the current solution (Add beams to cases which are problematic).

There are two solutions, the main one you need is to create two beams with autobeam instead of one. I will review why it is not doing that, which is clearly better than a single beam.

If you did want a single beam with two different tuplets and a rest outside of the beam, then that is possible in MEI verovio, but the beam or the quintuplet would have to be converted to a <beamSpan> or <tupletSpan> (which would be a lot harder to fix).

Fixing autobeam to split the example into two beams will be what I should do (fixing for the single-beam case is possible, but more difficult since I have to identify the crossing elements and convert one or the other into a *-span form.

[Suppan]

Thanks for the clarification! I like the humdrum syntax very much and using it for building an app for generating rhythmic lines in the field of computer-assisted composition. Therefore, I was using the autobeam filter.

[craigsapp]

Looking closer, I am noticing that autobeam behaves as expected when a time signature is given:

[View in VHV]

In general a time signature is needed to have autobeam group notes into beams. Here is an example:

[View in VHV]

The intention in autobeam is to use a quarter-note beat if there is no time signature, but this was not happening (a time signature of 0/0 indicating a non-existing time signature was being used). I now force 0/0 time signatures to be interpreted as 4/4, and this fixed the problem:

[View in VHV]

So this fixes your problem.

If you are running verovio on the command-line, you will have to use the develop-humdrum branch (which gets merged with develop branch every few months). If you have downloaded the verovio git repository, then run these commands to compile with the latest version with the fix:

cd verovio/tools
git checkout develop-humdrum
./.configure
make
sudo make install 

I see another problem: a barline is currently required to end a measure, which can cause problems with short examples like this; otherwise, the autobeam filter is ignoring the measure:

[View in VHV]

So I will work on fixing that (otherwise if you don't want to see a barine at the end of a short example like this, an invisible barline (=-) could be used).