fix(core): GPIF imports keep tapping and hammer-on origin semantics

[PhysShell]

What

GPIF imports (GP6 .gpx, GP7/8 .gp) now keep tapping and read hammer-on/pull-off with GP3/4/5 semantics. Both were lost in the guitarpro 0.4.2 GPIF conversion:

	before	after
Tapped note property	never read (beat tap effect left a placeholder) → no GP6/7 tapping in griff	beat gets SlapEffect::Tapping (how GP3/4/5 store it) → notes marked NoteMark::Tap
HopoOrigin / HopoDestination	both set the one legacy hammer flag → the destination note carried its own HammerOn span	flag reset to HopoOrigin only — "legato to the next note on this string", as in GP3/4/5

How

As with the tuning fix (#198), the adapter reads the GPIF document itself and repairs the converted song at the import boundary. It walks the document exactly as the crate does and zips it with the converted song: each track's bar per master bar, voice slots skipping -1, then existing beats and notes in order. A voice whose converted beats or notes do not line up is left as converted and reported in the LossReport, never re-labelled out of step.

Measured on a 410-file Guitar Pro corpus (145 GPIF files)

GP6/GP7 files	main	this PR
files with tapped notes	0	28
tapped notes	0	2,013
HammerOn spans on single notes	18,284	10,906
next single note on the same string after a hammer span	76.8%	99.7%
voices left unrestored	0	0

GP3/4/5 imports are unchanged (identical tap and span counts; 99.1% same-string).

Tests

• Red first (b9c037b), then green (89f3bde).
• core/tests/gp_gpif_techniques.rs: authored GPIF text (no copyrighted tab) packed with the crate's public writer. It covers:
  • only the origin carries the hammer span;
  • a chain marks every origin but not the last destination;
  • two adjacent pairs stay two pairs;
  • a tapped note imports as a tap;
  • a tapped chord note taps its beat (the legacy per-beat model).
• cargo test --workspace green locally (1,697 tests; missing_file_golden skipped locally only — its golden holds the English OS error text), cargo clippy -p griff-core --all-targets -- -D warnings and cargo fmt --check clean.

Out of scope / notes

• Hammer-on vs pull-off direction is still not derived; every legato flag is still a HammerOn span, as before. Deriving it changes corpus technique tags for every format and is a separate decision.
• LeftHandTapped (45 note definitions in the corpus) is not mapped.
• Upstream: all three GPIF defects are still present in slundi/scorelib master. That covers these two and the staff-tuning fallback worked around in fix(core): GPIF imports use string 1 = highest and read staff tunings #198. A git dependency on a fork is ruled out by deny.toml; the fix will be offered upstream, and griff drops these workarounds once a release carries it.
• Found by the Constraint Lab fingering experiments. lab: technique-aware fingering, oracle stage — does hand attribution explain the tapping slice? #200's tapping slice was GP3–5-only because of this.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 6d4db0f7-6e88-4218-b46c-af11e7c22ce3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}