Levi Neuwirth
bdab6dee1f
One iteration of an interactive edit, wired end to end so a missing connection
between the crates surfaces here, not in a GUI: render a score to its RenderIR,
resolve a click on a notehead to its graph pitch through the hit-test map, apply a
real operation (sharpen -- a +1-chromatic Transpose) by reducing it onto the score
graph, re-render, and confirm the selection survives the relayout.
- run_edit_loop_with<S: ConstraintSolver>(base, solver) returns an EditLoopReport
(selected_pitch, selection, graph_changed, selection_preserved, render_changed);
run_edit_loop is the stub wrapper. render_with returns None for a
diagnostic-only (non-renderable) solver report, so the loop never hit-tests or
edits a layout the caller must not render.
- The click resolves like a GUI's: aim at each real notehead's centre (a notehead
glyph, not synthesized, pitch-backed) and select whatever the topmost hit there
is, taking the first aim whose topmost hit is a pitch-backed glyph -- faithful
to a click and robust to an occluding unison/chord notehead.
- Selection survival rests on the MUSCLOID layout id, a function of the pitch's
identity (PitchId), not its content: the sharpen changes the pitch's value but
not its id, so its layout object keeps the same stable id and the cursor does
not jump off the edited note. The prepass re-runs inside to_logical, so the
edited pitch is re-spelled and its accidental reflects the new value (why the
re-render reliably differs).
Tests drive the loop on valid_score_rich (one fixture and across 48 seeds, every
seed required), refuse a diagnostic-only solver layout, and -- in epiphany-engrave,
via its existing testkit dev-dep -- run it through the real Engraver across 16
seeds, proving the selection survives even as the Engraver re-spaces every glyph.
Full gate green: build, fmt, clippy, conformance scale 1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| DECISIONS.md | ||
| README.md | ||
README.md
epiphany-engrave
Agent I's engraving constraint solver (spec Chapter 9): turns a
ConstrainedLayoutIR into a ResolvedLayoutIR with real geometry. It is the
production-side replacement for epiphany-layout-ir's interface-only
StubSolver; the two live in separate crates so the spec's core/product boundary
stays sharp.
Status: honest scaffold (renderer-against-stub phase)
Per the QUICKSTART development pattern, Agent I builds the SVG renderer
(epiphany-render-svg) against the stub solver
first, then grows this crate into the real two-pass spring solver. This commit is
the first increment:
Engraverruns a deterministic horizontal spacing pass (the first axis of the planned two-pass spring layout): each spring slot is placed left-to-right by its preferred width instead of being echoed verbatim.- It honestly reports
SolverTier::Stub— it does not yet evaluate the IR's declared hard constraints or compute quality metrics, so it has not earnedMinimal. It is promoted toMinimalin the change that lands real constraint satisfaction.
The vertical spring pass, soft-constraint solve, hard-constraint evaluation, and
the quality-metric vector are the next-phase / Phase-3 work. See DECISIONS.md.
use epiphany_engrave::Engraver;
use epiphany_layout_ir::{ConstraintSolver, SolverConfig};
let report = Engraver.solve(&constrained_ir, &SolverConfig::default());
assert!(report.satisfied_hard_constraints); // for constraint-free stub-pipeline input
let resolved = report.layout; // hand to epiphany-render-svg