Skip to content

model hammer-on and pull-off as paired spanners in mx::api #412

Description

@webern

What

<hammer-on> and <pull-off> are paired, note-attached spanners inside <technical>, carrying a
required type (start/stop), an optional number, and text content for the printed label:

<technical><hammer-on type="start" number="1">H</hammer-on></technical>

mx::api has no representation for either. MarkType has both members commented out
(src/include/mx/api/MarkData.h:142-143), as do the Converter::technicalMarkMap entries
(src/private/mx/impl/Converter.cpp:330-332). They are dropped on read and cannot be authored.
mx::core models them fully as core::HammerOnPullOff behind
core::TechnicalChoice::Kind::{hammerOn, pullOff}, so the data is available and thrown away in
mx::impl.

Requirements

  1. Read and write start/stop attached to the notes that carry them.
  2. Honor number via the existing SpannerNumber mechanism.
  3. Preserve the element text (the H / P label).
  4. Pin a corpus file in src/private/mxtest/api/roundtrip-baseline.txt, e.g.
    ksuite/k004a_Technical.xml. Both are support="none" in data/api.features.xml, and none of
    the five corpus files using them are defended today.

Follow whatever shape #389 settles on for the other note-attached paired spanners. tap (the third
member of audit section 1.2) is not in scope; it carries text only and is not a spanner.

Blocks u_span eligibility in #393. Related: #389, #185 (closed; deferred these).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    aiIssues opened by, or through, a coding agent.apiAffects the mx::api layerdesignNot a simple fix. Requires design decisions.featurenew feature requestimplAffects the mx::impl layer

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions