Skip to content

api: many direction-type subtypes are unmodeled stubs (percussion, metronome extras, harp-pedals, scordatura, ...) #324

Description

@webern

Split out of #278/#280 while investigating why the round-trip classifier reports drop:voice /
drop:staff / drop:direction / drop:direction-type on ~60 corpus files.

Finding

Nearly all of those drops trace to one cause: DirectionReader already dispatches every
direction-type choice, but a long list of subtypes are no-op stubs (parseHarpPedals,
parseDamp, parseDampAll, parseEyeglasses, parseStringMute, parseScordatura, parseImage,
parsePrincipalVoice, parseAccordionRegistration, parsePercussion, parseOtherDirection --
all MX_UNUSED(directionType);). When a <direction> contains only one of these, the resulting
DirectionData ends up empty and is correctly not written back -- MusicXML requires at least one
direction-type child, so there is no schema-valid way to keep the <direction> (and its
<voice>/<staff>) without modeling its actual content.

data/api.features.xml already correctly audits each of these specific subtypes as support="none"
(only the parent direction/direction-type container is full, correctly -- the container
mechanism itself works). So this is not an audit-correction; it's a real, if long, worklist of
unmodeled features.

Worklist (files unlocked once implemented; each also needs add:attributes/add:divisions

handled for the synthetic single-feature fixtures, so implementing one of these may not by itself
flip a file to PASS)

  • percussion (beater/effect/glass/membrane/metal/other-percussion/pitched/stick/stick-location/
    stick-material/stick-type/timpani/wood) -- 24 files
  • metronome-note/metronome-relation/metronome-type/metronome-arrows (metric modulation) -- 8 files each
  • accordion-registration -- 3 files
  • damp, damp-all, effect, eyeglasses, harp-pedals, image, other-direction,
    principal-voice, string-mute -- 2 files each
  • scordatura, staff-divide, symbol -- 1 file each

Also found while investigating: DirectionReader::parsePedal only handles PedalType::start/stop;
sostenuto/change/continue/discontinue/resume are silently dropped
(lysuite/ly33a_Spanners.xml). Modeling these needs a shape decision (a third "kind" on the shared
pedal spanner, or a dedicated change/continue vector) -- tracked here too rather than folded into a
quick fix.

Suggested approach

Pick off the highest-yield/lowest-effort items first (percussion family, metronome-* family).
The mx-api-add-feature skill covers the impl wiring for each MusicXML feature.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    aiIssues opened by, or through, a coding agent.apiAffects the mx::api layerfeaturenew feature requestimplAffects the mx::impl layernon-breakingfixes or implementation that do not require breaking changes

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions