(AI) Humdrum parser drops notes from sub-spines created by *^ after a *v-merge

[weselyj]

music21 version

9.9.1

Operating System(s) checked

Windows 11 (Python 3.13.13)
Linux (Python 3.14.4)

Same parser output on both — the bug is not OS-specific.

Problem summary

When a Humdrum **kern spine is split with *^, merged with *v, then re-split with another *^ (a "voice rejoin" pattern common in piano music), the parser drops notes from the newly-created sub-spines after the second split. The notes are present in the source file and the spine syntax is valid Humdrum, but they never appear in the resulting Stream.

This is related to but distinct from #884 (closed) — that issue was about the merge itself; here the merge succeeds but the subsequent re-split loses notes.

Steps to reproduce

The bug is in the humdrum subconverter, so a tinynotation reproducer isn't possible. Save the following as repro.krn:

**kern	**kern
*clefF4	*clefG2
*k[]	*k[]
*M4/4	*M4/4
=1	=1
*	*^
4C	4c	4d
4E	4e	4f
*	*v	*v
=2	=2
*	*^
*	*	*^
4F	4g	4a	4b
4G	4g	4a	4b
*	*v	*v
*	*v	*v
=3	=3
4A	4cc
*-	*-

(Tab-separated columns. 1 bass spine + 1 treble spine; the treble splits into 2 voices in m1, merges, splits into 3 voices in m2, then merges back to 1 voice for m3.)

import music21

s = music21.converter.parse('repro.krn', format='humdrum')
notes = list(s.recurse().notes)
print(f'parsed: {len(notes)} notes')
for n in notes:
    parent = n.getContextByClass(music21.stream.Part)
    pidx = list(s.parts).index(parent) if parent else -1
    offset = float(n.getOffsetInHierarchy(s))
    print(f'  part={pidx} offset={offset:>4.1f} pitch={n.pitch.nameWithOctave}')

Expected vs. actual behavior

The kern source contains 16 notes:

measure	bass	treble
1	C E (2)	c d e f (4)
2	F G (2)	g a b g a b (6)
3	A (1)	cc (1)

Actual output is 12 notes:

part=0 offset= 0.0 pitch=C4
part=0 offset= 1.0 pitch=E4
part=0 offset= 0.0 pitch=D4
part=0 offset= 1.0 pitch=F4
part=0 offset= 2.0 pitch=G4
part=0 offset= 3.0 pitch=G4
part=0 offset= 2.0 pitch=C5    ← cc note appears here, expected at offset 4.0
part=1 offset= 0.0 pitch=C3
part=1 offset= 1.0 pitch=E3
part=1 offset= 2.0 pitch=F3
part=1 offset= 3.0 pitch=G3
part=1 offset= 4.0 pitch=A3

Missing: the a b a b content from the second *^ split in m2 (4 notes). The cc note from m3 also appears at offset 2.0 instead of offset 4.0, suggesting a cascade from the missing content.

No exception is raised; the notes are silently absent.

More information

I encountered this while building a music-OMR pipeline that compares music21's humdrum parse against a custom kern-to-token converter as a validation oracle. Across ~54k Beethoven sonata files from KernScores, ~560 (~1.0%) exhibit this pattern: the converter's output is a strict superset of music21's, with the extra notes always corresponding to post-*^-after-merge sub-spine content.

Likely fix locus: music21/humdrum/spineParser.py::createMusic21Streams or thereabouts (no exception raised, so no stack trace). Sub-spine tracking after a *v-merge appears to lose track of new sub-spines created by a subsequent *^.

For now, in my pipeline I treat "music21 produces fewer notes than the kern source" as a known-incorrect-reference signal rather than a converter error.

[mscuthbert]

Thanks for the detailed example which will help with understanding. Closing this as a duplicate of #62 -- but will post what you wrote there. It appears to be a failure when merging and immediately respliting a voice -- not something a human would write in krn, but which has already been seen in the Beethoven corpus.

[mscuthbert]

wait -- there are only 2 quarter notes per measure and you are asserting 4/4 time signature. The kern is incorrect.

[weselyj]

You're right — apologies, the original reproducer had 4/4 with 2-quarter measures, which is malformed.

Here is a corrected reproducer in 2/4 (where 2-quarter measures are valid). The bug still reproduces — the parser finds 12 notes when 16 are present in the source.

**kern	**kern
*clefF4	*clefG2
*k[]	*k[]
*M2/4	*M2/4
=1	=1
*	*^
4C	4c	4d
4E	4e	4f
*	*v	*v
=2	=2
*	*^
*	*	*^
4F	4g	4a	4b
4G	4g	4a	4b
*	*v	*v
*	*v	*v
=3	=3
4A	4cc
*-	*-

import music21
s = music21.converter.parse('repro.krn', format='humdrum')
notes = list(s.recurse().notes)
print(f'parsed {len(notes)} notes')  # actual: 12

Expected 16 notes (3-col m1 × 2 events = 6, plus 4-col m2 × 2 events = 8, plus 2-col m3 × 1 event = 2). Actual 12 — the four a a b b notes from the post-second-*^ content in m2 are missing, and the m3 cc lands at offset 2.0 instead of offset 4.0 (cascading from the missing m2 content).

Also confirmed in 4/4 with proper-length measures (4 quarters each): 28 notes parsed of 36 expected — same *v-then-*^ rejoin pattern dropping the post-second-*^ content.

Both files tested on music21 9.9.1 / Python 3.14 (Linux) and Python 3.13 (Windows) — same output.

[mscuthbert]

Can you try against the latest master/HEAD branch. I put in a lot of humdrum improvements today.

[weselyj]

Tested against music21 10.0.1b3 (latest master, just installed via pip install git+https://github.com/cuthbertLab/music21.git).

Same output as 9.9.1:

• 2/4 repro: 12 notes parsed, 16 expected
• 4/4 repro (4 quarters per measure, fully filled): 28 notes parsed, 36 expected

The four a a b b notes from the post-second-*^ content in m2 are still dropped, and the m3 cc still cascades to the wrong offset.

Happy to test specific commits if there's one you'd like me to verify.