consolidateCompletedTuplets combines rests across different triplets that causes malformed MusicXML output

[dszeto]

music21 version

9.5.0

Operating System(s) checked
macOS, Linux

Problem summary

When consecutive triplets contain elements that can combine into a full quarter length element, such element will cross triplet boundary.

>>> s.show('text')
{0.0} <music21.note.Note C>
{0.3333} <music21.note.Note C>
{0.6667} <music21.note.Rest 1/3ql>
{1.0} <music21.note.Rest 1/3ql>
{1.3333} <music21.note.Rest 1/3ql>
{1.6667} <music21.note.Note C>
>>> s2 = s.makeNotation()
>>> s2.show('text')
{0.0} <music21.stream.Measure 1 offset=0.0>
    {0.0} <music21.clef.TrebleClef>
    {0.0} <music21.meter.TimeSignature 4/4>
    {0.0} <music21.note.Note C>
    {0.3333} <music21.note.Note C>
    {0.6667} <music21.note.Rest quarter>
    {1.6667} <music21.note.Note C>
    {2.0} <music21.bar.Barline type=final>

When we write s2 out as a MusicXML output, it grouped the triplets and the quarter rest in a way such that notation software fails to interpret it. Below is MuseScore4 as an example.

Looking at the MusicXML output, the tuplet stop tag is placed after the first two 1/3ql note, followed by a ql rest outside of any tuplet tag, and then another tuplet tag that only contain the last 1/3ql note.

    <measure implicit="no" number="1">
      <attributes>
        <divisions>10080</divisions>
        <time>
          <beats>4</beats>
          <beat-type>4</beat-type>
        </time>
        <clef>
          <sign>G</sign>
          <line>2</line>
        </clef>
      </attributes>
      <note>
        <pitch>
          <step>C</step>
          <octave>4</octave>
        </pitch>
        <duration>3360</duration>
        <type>eighth</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          <normal-type>eighth</normal-type>
        </time-modification>
        <stem>up</stem>
        <beam number="1">begin</beam>
        <notations>
          <tuplet bracket="yes" number="1" placement="above" type="start">
            <tuplet-actual>
              <tuplet-number>3</tuplet-number>
              <tuplet-type>eighth</tuplet-type>
            </tuplet-actual>
            <tuplet-normal>
              <tuplet-number>2</tuplet-number>
              <tuplet-type>eighth</tuplet-type>
            </tuplet-normal>
          </tuplet>
        </notations>
      </note>
      <note>
        <pitch>
          <step>C</step>
          <octave>4</octave>
        </pitch>
        <duration>3360</duration>
        <type>eighth</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          <normal-type>eighth</normal-type>
        </time-modification>
        <stem>up</stem>
        <beam number="1">end</beam>
        <notations>
          <tuplet number="1" type="stop" />
        </notations>
      </note>
      <note>
        <rest />
        <duration>3360</duration>
        <type>eighth</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          <normal-type>eighth</normal-type>
        </time-modification>
      </note>
      <note>
        <rest />
        <duration>6720</duration>
        <type>quarter</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          <normal-type>quarter</normal-type>
        </time-modification>
      </note>
      <note>
        <pitch>
          <step>C</step>
          <octave>4</octave>
        </pitch>
        <duration>3360</duration>
        <type>eighth</type>
        <time-modification>
          <actual-notes>3</actual-notes>
          <normal-notes>2</normal-notes>
          <normal-type>eighth</normal-type>
        </time-modification>
        <notations>
          <tuplet bracket="no" number="1" placement="above" type="start">
            <tuplet-actual>
              <tuplet-number>3</tuplet-number>
              <tuplet-type>eighth</tuplet-type>
            </tuplet-actual>
            <tuplet-normal>
              <tuplet-number>2</tuplet-number>
              <tuplet-type>eighth</tuplet-type>
            </tuplet-normal>
          </tuplet>
          <tuplet number="1" type="stop" />
        </notations>
      </note>
      <barline location="right">
        <bar-style>light-heavy</bar-style>
      </barline>
    </measure>

Interestingly, reading such MusicXML file back into music21 will re-create the correct structure:

{0.0} <music21.metadata.Metadata object at 0x105d04e10>
{0.0} <music21.stream.Part 0x105d05550>
    {0.0} <music21.instrument.Instrument 'P6042ee7e265acfe49a53036df8d61a0b: '>
    {0.0} <music21.stream.Measure 1 offset=0.0>
        {0.0} <music21.clef.TrebleClef>
        {0.0} <music21.meter.TimeSignature 4/4>
        {0.0} <music21.note.Note C>
        {0.3333} <music21.note.Note C>
        {0.6667} <music21.note.Rest 1/3ql>
        {1.0} <music21.note.Rest 2/3ql>
        {1.6667} <music21.note.Note C>
        {2.0} <music21.bar.Barline type=final>
{0.0} <music21.layout.ScoreLayout>

Steps to reproduce

s = music21.stream.Stream()
n = music21.note.Note(quarterLength=1/3)
r = music21.note.Rest(quarterLength=1/3)
s.repeatAppend(n,2)
s.repeatAppend(r,3)
s.repeatAppend(n,1)
s.show("text")
s.makeNotation().write("musicxml", "test.musicxml")
# open test.musicxml with any notation software
s2 = music21.converter.parse("test.musicxml")
s2.show("text")

Expected vs. actual behavior

tuplet tags should be placed correctly around tuplet groups so that it can be displayed properly in notation software.

More information

[mscuthbert]

I thought that there might be a bug because you're using (1) generic Stream and not Measure, (2) your measure lacks a time signature, and (3) you have not designated that your tuplets last 1 QL and not 2 QL via start and stops. So I rewrote your example as:

from music21 import *

m = stream.Measure()
m.append(meter.TimeSignature('2/4'))
n = note.Note(quarterLength=1/3)
r = note.Rest(quarterLength=1/3)
m.repeatAppend(n,2)
m.repeatAppend(r,3)
m.repeatAppend(n,1)
tups = ['start', None, 'stop', 'start', None, 'stop']
for n, tupType in zip(m.notesAndRests, tups):
    n.duration.tuplets[0].type = tupType
m.makeNotation().show('text')

And I was confused by the behavior, but then I also forgot about something added in the 2021 release in part for MIDI users:

By setting your durations via quarter lengths instead of as eighth notes/rests with tuplets added to them, it tells music21 that you do not care how the time span is expressed so long as it's fills that time in a way that seems logical. (Now in 2025 as a Finale exile, I'll call this "Dorico mode"). For instance if there are three notes with duration: 1/3, 1/2, 1/6 then the middle note should best be a dotted eighth triplet, not a non-triplet eighth note.

(This is similar behavior to pitch expressed in MIDI numbers. give MIDI 61 and music21 feels free to change it between C# and Db depending on the surrounding key context. Call it 'D-4' and music21 will never change it)

Music21 stores whether the duration can be changed on duration.expressionIsInferred so adding these lines will fix the "problem".

for n in m.notesAndRests:
    n.duration.expressionIsInferred = False

This is not a bug in the system, but rather allowing for different usages.

I do think though that in the case where a tuplet type has explicitly been set to stop, rests should not consolidate across them (unless the entire tuplet has been merged). So that could be considered as a feature enhancement, but not one I have time to work on right now.

Thanks!

[mscuthbert]

Good luck with bovo.ai btw!

[mscuthbert]

(But if we're writing out MusicXML that most standard readers can't read then that is something to address.)

[dszeto]

Actually MuseScore 4 will still render measures after a "bad" one while Dorico 6 will just make everything that comes after empty.

So it'd be nice this is addressed. I found this behavior just by reading a MusicXML and writing it out again without any modification.

[mscuthbert]

Can you point me to the MusicXML file that caused the problem? I'm curious because MusicXML should have expressionIsInferred = False set for anything read it, unless it has a <supports> tag with type = "no" which I've never seen in the wild.

I'm not currently able to spend too much time on music21 (since I'm no longer at MIT or anywhere paying me for music21 development) so I'm grateful for anything that you can do to point to possible fixes or error points. Thanks!

[dszeto]

Had to rename it to end with .txt for GitHub to allow it to be attached. It has <supports> tags but none of them has type = "no".

m21test.txt

[mscuthbert]

Thanks. Since it's long can you point me to the measure that will have the problem?

[dszeto]

Measure 8.

My bad 😅 I was going to note that but forgot to.