daniel/reasampler
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(todo-1.0): item 15 answer round; item 16 retires zone mapping

Browse Source 
Five blocking questions folded; capture-signal popup specced; items 2, 9,
11, 12 carry supersession notes. Sole remaining Daniel-blocker: multi-zone
migration.
This commit is contained in:
Daniel Harvey
2026-07-29 11:03:17 -04:00
parent b8e8bb4c75
commit d8651fb7a7
1 changed files with 294 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO-1.0.md
+294 -70
View File
@@ -4,7 +4,9 @@ Post-1.0 queue for ReaSampler — chiefly the 9000 instrument, plus two
extension-side bugs. Items 1–3 are the first batch, in Daniel's ordering
(2026-07-28); items 4–13 are a second batch (2026-07-28, later the same day);
item 14 is a third, single-item batch (2026-07-28, later again); item 15 is
a fourth, single-item batch (2026-07-29).
a fourth, single-item batch (2026-07-29); item 16 (2026-07-29) is not a new
ask batch — it records the system change mandated by answer 1 of item 15's
answer round (the zone mapping system is retired).
Deliberately specified at the level of product
intent, user-visible behavior, and acceptance criteria — **no implementation
design, no file/module references**. These were authored while Phase Q was
@@ -89,13 +91,27 @@ processing is captured back into the bank, the source capture is replaced (or
a distinct capture added when other references exist), the instance re-points
at the recapture, and the audio parameters reset to default — the
dial → bake → dial-again iteration loop, run without leaving the sampler.
**Item 15 reopens the Daniel-blocked state: five of its open questions await
a Daniel decision** — the multi-zone scope of "the sound," what the offline
pass plays (note, velocity, and the Gate-mode hold/tail policy), the
**Item 15 reopened the Daniel-blocked state: five of its open questions
awaited a Daniel decision** — the multi-zone scope of "the sound," what the
offline pass plays (note, velocity, and the Gate-mode hold/tail policy), the
parameter-reset scope, what counts as "other references," and the
undo/recovery expectation. Its remaining questions are
propose-at-implementation-review; items 1–14 stay fully unblocked.
A **fourth-batch answer round** (2026-07-29) answered all five. The answers
are folded into item 15's Behavior (marked *settled by answer round*).
Answer 1 is a **system change, not a scoping rule**: the zone mapping system
is retired — ReaSampler 9000 becomes **one capture = one parameter set** —
recorded in full as **item 16**, which supersedes the doc's per-zone-storage
and Sample/Zone-panel-parity language throughout (items 2, 9, 11, and 12
carry marked superseded-by/cross-reference notes; Daniel's verbatim asks
stand exactly as written). Answer 2 spawns a new sub-feature inside item 15:
a **capture-signal popup** (note length, start/end offsets in ms and in
beats, velocity, and a preview trigger). **Current Daniel-blocked state:
exactly one question awaits a Daniel decision — item 16's migration of saved
multi-zone instances.** Everything else open across items 1–16 is
verify-or-propose-at-implementation.
Ordering note: item 1's curve/overlay treatment explicitly anticipates item 2's
filter envelope ("filter to be added"), and item 3 layers on both. They can land
in sequence or together, but 1 and 2 are prerequisites for 3's full surface.
@@ -120,7 +136,14 @@ and 14 build — so its spec only becomes fully meaningful once those have
landed, and its Gate-mode render policy touches item 9's loop-sustain; that
is a statement of what the feature operates on, not a schedule decision. Its
bank-side half rides the already-settled capture and prune safety model, not
any queued item.
any queued item. Item 16 (zone retirement) is a **prerequisite of meaning**
for item 15 — it is what makes "the sound" singular and dissolves the
multi-zone question — and it touches the surfaces other queued items work
on: items 2, 9, and 11 now store their parameters into the one parameter
set rather than per-zone, and item 12's full-width piano strip is
re-grounded by what the strip means with zones retired. That too is
dependency-of-meaning, not a schedule: the affected items' work is
unchanged in substance; only its storage/parity framing simplifies.
---
@@ -293,7 +316,12 @@ AHDSR envelope, and make the knob-deck row read in signal-flow order.
- **Per-zone storage.** The filter's parameters are **stored per-zone**,
alongside the other playback parameters — Sample/Zone panel parity applies,
same as the existing per-zone controls (VOICE and MASTER remain the
per-instance exceptions). *(Settled by second follow-up.)*
per-instance exceptions). *(Settled by second follow-up.)* **Superseded by
item 16** (zone retirement): the filter's parameters join the instrument's
**one parameter set** — no per-zone storage, no Sample/Zone parity, no
per-instance exception structure to be an exception to. The follow-up's
substance carries over unchanged: the filter's parameters live with the
other playback parameters.
- **Off by default.** The filter **defaults to off** — pre-existing saved
instances and freshly loaded captures sound unchanged until the user engages
it. *(Settled by second follow-up.)*
@@ -332,9 +360,10 @@ AHDSR envelope, and make the knob-deck row read in signal-flow order.
- Two simultaneously sounding voices at different envelope phases are filtered
independently (per-voice processing is audible, not a shared instance-wide
filter).
- Filter parameters follow Sample/Zone panel parity: they appear and edit on
both surfaces, and each zone carries its own filter settings (two zones with
different filter settings audibly differ).
- Filter parameters live in the instrument's one parameter set: they edit in
one place and govern the instrument as a whole. (Original per-zone/parity
form — two surfaces in parity, per-zone divergence — superseded by item 16;
neither is expressible after the zone retirement.)
- Velocity and key-tracking modulation of the filter ship with this item and
are audible — velocity following the amp-velocity-transfer-curve pattern,
key-tracking following the pitch-key-tracking pattern.
@@ -757,9 +786,10 @@ playback cycling the loop until note-off, then release.
- The regression verification above (removed vs. unexposed).
- The crossfade parameter's units and range are unspecified — Daniel call, or
a proposed default surfaced at implementation review.
- Storage side: presumably per-zone alongside the other playback parameters
(Sample/Zone panel parity, with VOICE/MASTER the per-instance exceptions) —
confirm.
- Storage side: closed by **item 16** (zone retirement) — the loop
parameters belong to the instrument's one parameter set; there is no
per-zone side left to confirm. (Cross-reference: item 15's settled reset
scope classifies loop points as baked-in, so they reset on a resample.)
- Editing surface for loop start/end (waveform markers, knobs, or both) is
unspecified; the waveform display is the natural home for range markers, but
Daniel has not said.
@@ -853,7 +883,11 @@ playback cycling the loop until note-off, then release.
because the proposed MASTER placement implied per-instance storage; with
the buttons in their own VELOCITY group that doubt is gone, and the
project's settled convention — playback parameters are per-zone, VOICE and
MASTER the per-instance exceptions — decides it.)*
MASTER the per-instance exceptions — decides it.)* **Superseded by item
16** (zone retirement): the curves live in the instrument's **one
parameter set**. The bullet's point survives in simplified form — the
curves store with the other playback parameters; the per-zone framing and
the parity convention it leaned on are gone.
- **Bipolar pitch/filter transfer functions.** Pitch and filter velocity
transfer functions are **bipolar: y range [−1, 1], default y = 0** — flat at
zero, meaning velocity modulation of pitch and filter is **off until the
@@ -871,7 +905,8 @@ playback cycling the loop until note-off, then release.
introduced by this item — unverifiable here under the no-code-reads
constraint; if absent, this item introduces it. (The former second question
— amp-curve storage under the MASTER placement — dissolved with the
placement's supersession; storage is settled per-zone above.)
placement's supersession; storage is settled above — per-zone at the time
of that round, now the one parameter set per item 16.)
**Acceptance criteria.**
@@ -880,8 +915,9 @@ playback cycling the loop until note-off, then release.
- The three velocity-curve buttons sit together in a deck group labelled
**VELOCITY**, immediately to the left of the VOICE group; no velocity-curve
button appears in MASTER, PITCH, or Filter.
- The velocity curves follow Sample/Zone panel parity and persist per-zone
(two zones with different curves audibly differ).
- The velocity curves persist in the instrument's one parameter set and
round-trip save/reload. (Original per-zone/parity form superseded by
item 16; per-zone divergence is no longer expressible.)
- Opening the pitch or filter curve shows a bipolar editor ([−1, 1]) defaulted
flat at y = 0; played velocities produce no pitch/filter modulation until a
curve is drawn, then audibly follow it.
@@ -917,7 +953,13 @@ playback cycling the loop until note-off, then release.
- **Cross-references.** Item 11 also changes the preview button (glyph); the
two compose — the glyph button in its new toolbar position. Item 13's
anti-aliasing audit covers the key-pattern rendering if aliasing turns out
to be the cause.
to be the cause. **Item 16** (zone retirement) removes the zone count
label's referent entirely — this item's removal of the label is doubly
settled — and re-grounds what the full-width strip displays: with no zone
bars, its surviving jobs are the root affordance (item 15's answer round
makes root explicitly resample-stable) and these note-name tooltips;
whether any key-range display remains follows item 16's key-range
question.
**Acceptance criteria.**
@@ -1095,6 +1137,23 @@ follow-up round extends the same rule to item 2's filter envelope.
> parameters to default, effectively allow reiteration over sounds from
> within the sampler.
**Daniel's answer round (verbatim, 2026-07-29)** — answering, in order, the
five questions this item carried as awaiting a Daniel decision:
> 1. I don't actually care, or even really understand, our zones. Retire
> the zone mapping system, simplify. I don't expect to use it,
> reasampler 9000 becomes 1 capture = one parameter set
> 2. capture root (so that parameter is not reset by resampling), for the
> gate and velocity questions, we need a popup menu to program note
> length, start/end offsets in ms AND in beats, and velocity for the
> capture signal. The popup shoulud have a preview trigger button to
> allow previewing the note capture as currently programed.
> 3. only what is baked into the sample recapture (contours, filter, master
> gain, etc)
> 4. any usage of that capture that is tied by the provenance/recaptureing
> system
> 5. Undo/Recovery is a plus
**Intent.** Close the sound-design loop from inside the instrument: once the
filtering, pitching, and amp are set up nice, one click bakes that processing
into the audio itself — a new bank capture — and hands the instrument back at
@@ -1121,8 +1180,9 @@ through.
- **Replace, or add distinct.** When nothing else references the source
capture, the recapture **replaces** it as the bank entry; when other
references exist, the original entry stays and the recapture is **added as
a new distinct capture**. (What counts as an "other reference" is an open
question below.)
a new distinct capture**. (What counts as an "other reference" is settled
by the answer round — usage tied by the provenance/recapture system; see
the settled bullet below.)
- **Replacement never destroys audio bytes.** "Replace" means the bank entry
now denotes the recapture; the superseded file itself is not deleted by
this action. *(Derived, not a Daniel quote: the settled rule that the
@@ -1138,83 +1198,153 @@ through.
audio parameters return to default — destructive to the dialed settings
**by design**: the processing now lives in the recaptured audio, and the
neutral controls are the starting point for the next iteration. Which
parameters "audio parameters" covers is an open question below.
parameters "audio parameters" covers is settled by the answer round — see
the reset-scope bullet below.
- **No timeline item, ever.** Resampling is a capture act: it writes a file
to the bank and updates the index; nothing is placed in the arrange view.
*(Derived, not a Daniel quote: the tool's load-bearing capture/placement
separation forces this — any framing of the feature that auto-inserts the
recapture into the timeline is invalid.)*
- **Single capture, single parameter set — "the sound" is unambiguous.**
Answer 1 dissolves the multi-zone question by **system change, not scoping
rule**: the zone mapping system is retired outright — recorded in full as
**item 16**. With one capture = one parameter set, one click resamples the
instrument's one capture through its one parameter set; no multi-zone rule
is needed because no multi-zone state exists. *(Settled by answer round —
by reference to item 16.)*
- **The capture-signal popup.** A **popup menu programs the capture
signal**: **note length**, **start and end offsets — in ms AND in
beats**, and **velocity**. The popup carries a **preview trigger button**
that auditions the capture note exactly as currently programmed — the
user hears the bake before committing it — and the offline pass renders
that same programmed performance. *(Settled by answer round — a new
sub-feature, specced here with its own acceptance criteria below.)*
- **The note is the capture's root.** The rendered note is the capture's
root note — and, as Daniel states as a consequence, **the root-note
parameter is therefore not reset by resampling** (capturing at root is
what makes the root parameter survivable: it composes with the
reset-scope rule below, and resetting it would detune every subsequent
iteration). *(Settled by answer round.)*
- **Gate's hold and tail are answered by the programmed window.** The
programmed **note length is the Gate hold bound** — the gate holds for
the note length, then releases; item 9's loop-sustain cycles within the
held span and the render still terminates. The **end offset** is the
natural home of the tail policy: captured time past the note's end is
where the release rings. *(The hold reading is settled by the answer
round; the end-offset-as-tail reading is derived — the natural one, but
the offsets' exact anchor points are propose-at-review, below.)*
- **Velocity is explicit.** The programmed velocity is the render
velocity — material because the velocity transfer curves modulate amp
(and, with items 2 and 11, pitch and filter) at that velocity.
*(Settled by answer round.)*
- **Reset scope: only what the bake baked in.** *(Settled by answer round.)*
"Reinitialize the audio parameters to default" covers **only the
parameters whose effect is baked into the recaptured audio** — Daniel
names contours, filter, and master gain, with an explicit "etc". The
per-parameter classification follows *(derived, marked as derivation: the
rule is Daniel's; the reading-off is not)*:
- **Reset** (their effect is in the audio): the envelope contours — staged
and spline alike — the filter parameters, master gain, the pitch
envelope/engine settings, the velocity transfer curves (their effect at
the programmed velocity is in the audio), and the loop points (they
shaped the render, and old loop positions are meaningless against new
audio).
- **Survive** (mapping facts, not present in the audio): the **root
note** (explicit in answer 2), and — post-item-16 — whatever remains of
key mapping (key-tracking; any key-range concept item 16's open
question settles), plus the VOICE group (polyphony behavior leaves no
trace in a single rendered note).
- Edge classifications are verified at implementation review **against
the rule** — not new Daniel calls (open question below).
- **"Other references" = usage tied by the provenance/recapture system.**
*(Settled by answer round.)* Replace-vs-add is decided by whether **any
usage of the source capture is tied to it by the provenance/recapture
system**: tied usage exists → the original entry stays and the recapture
is added distinct; none → replace. Read plainly: the reference universe
is the resample system's own lineage records — **not** the
prune-protection universe. The answer does not appear to cover bank
multi-membership, items placed in the arrange, or a plain hold by another
instance outside any recapture lineage — those do not force add-distinct,
and need not for safety: the superseded file survives until prune, and
prune's protection universe is unchanged and broader than this one. How
the provenance/recapture system represents a "usage tie" is part of the
lineage question below — answer 4 makes that question load-bearing.
- **Undo/recovery: a plus, not a requirement.** *(Settled by answer round —
at exactly that strength.)* Undo of the bake chain is **desirable but not
required**: welcome if it falls out cheaply, and the feature ships
without it. The guaranteed recovery path remains the floor already stated
above — the superseded file survives on disk until a prune reclaims it.
This is a nice-to-have note, not a spec.
**Open questions.**
- **Multi-zone scope — awaits a Daniel decision.** The ask speaks of "the
sound" and "that sampler capture" in the singular. On an instrument with
multiple zones — or zones referencing different captures — what does one
click resample: is the feature restricted to single-capture setups, does
it bake one zone (which?), or is there a whole-keymap story? The
single-capture reading is the natural one, but the multi-zone rule — even
if the rule is an explicit restriction — must be chosen, not assumed.
- **What the offline pass plays — awaits a Daniel decision.** "A trigger or
gate" presumably follows the active playback mode, but the render
performance is otherwise unstated: which note (natural lean: the capture's
root), what velocity (material, because the velocity curves modulate amp —
and, with items 2 and 11, pitch and filter), and for Gate mode a hold
length and tail policy — how long the gate holds (item 9's loop-sustain
makes a held gate indefinite, so *some* bound is required) and how long
the release rings before the capture ends. Trigger mode has a natural
answer (play to completion); Gate does not.
- **Reset scope — awaits a Daniel decision.** Does "reinitialize the audio
parameters to default" mean every parameter, or only those whose effect
the recapture baked in? Concretely undecided either way: zone key ranges,
loop points, the VOICE group, MASTER gain, and the velocity transfer
curves — which reset, which survive.
- **What counts as "other references" — awaits a Daniel decision.** Other
sampler instances holding the capture? Items placed in the arrange from
it? Its membership in more than one bank? The answer decides when
iteration updates the bank entry in place versus forks a distinct
capture — i.e., whether a sound something else still depends on can
disappear from the bank (its file survives regardless; see Behavior). The
prune model already has a settled notion of what protects a file from
deletion; whether that same universe governs replace-vs-add here is the
decision.
- **Undo / recovery — awaits a Daniel decision.** The chain is destructive
to the dialed settings by design. Is any of it undoable — one undo
restoring the bank entry and the instrument's prior parameters — or is
the loop deliberately forward-only, with the superseded file's
survival-until-pruned the only recovery path? The bank side has a settled
one-operation-one-undo convention; the instrument-parameter side has no
precedent to lean on.
- The five awaiting-a-Daniel-decision questions the fourth batch opened
(multi-zone scope; what the offline pass plays; reset scope; "other
references"; undo/recovery) are **all settled by the answer round** and
folded into Behavior above. What remains:
- **Capture-window semantics — propose at implementation review.** The
popup's dual ms/beats denomination is settled; its reference points are
not: the natural reading (start offset anchored to note-on, end offset to
note-end, beats resolved against the host tempo) should be proposed
concretely at review, along with whether negative offsets are meaningful.
- **Reset-scope edge cases — verify at implementation review.** The rule is
settled (baked-in resets, mapping survives); the per-parameter
classification above is derived. Any parameter whose side of the line is
unclear at implementation time is classified against the rule and
surfaced at review — not a new Daniel call.
- **Extension presence — propose at implementation review.** The instrument
plays self-contained with the extension absent, but the bank is the
extension's surface, and resampling mutates the bank. The natural answer
is that resample requires the extension present and is cleanly
unavailable — not silently lossy — without it; propose the exact behavior
at review.
- **Provenance of the recapture — propose at implementation review.**
Captures carry a reproducibility fingerprint of their capture recipe; a
resample's recipe is the instrument's own settings, not a track's chain.
Whether the recapture records a resample-shaped fingerprint or — the
settled conservative default for ambiguous cases — records nothing is a
- **Provenance of the recapture — propose at implementation review; now
load-bearing.** Captures carry a reproducibility fingerprint of their
capture recipe; a resample's recipe is the instrument's own settings, not
a track's chain. The answer round raises the stakes: replace-vs-add is
decided by usage ties in the provenance/recapture system (answer 4), so
the settled record-nothing conservative default is no longer available
for the lineage half of this question — the recapture must carry whatever
record makes answer 4's decision computable. Whether the
recipe-fingerprint half records a resample-shaped fingerprint stays a
propose-at-review call.
- **Naming and lineage — propose at implementation review.** When
add-distinct fires, the new capture needs a display name (derived from
the original?), and the bank some way to read iteration lineage across
repeated bakes; propose at review.
repeated bakes; propose at review, as one proposal with the provenance
question above, on which answer 4 now leans.
- **Multi-zone migration — owned by item 16, awaits Daniel there.** Not
this item's question, but it gates resample on pre-existing multi-zone
instances: what such an instance becomes under item 16's migration rule
decides what its resample would bake.
**Acceptance criteria.**
- On a dialed-in single-capture instrument, one click yields all of: a
recapture in the bank, the instance holding that recapture, and the audio
parameters at their defaults (per whatever reset scope Daniel settles).
- On a dialed-in instrument (one capture, one parameter set — item 16), one
click yields all of: a recapture in the bank, the instance holding that
recapture, and the baked-in audio parameters at their defaults — with the
root note and the other surviving mapping parameters untouched (the
settled reset scope).
- The bake is audible and faithful: after the click, playing what the
offline pass played (same note, same velocity, same mode) through the
offline pass played (the programmed capture note: root, at the programmed
length, offsets, and velocity, in the active mode) through the
now-neutral controls sounds as the dialed instrument sounded just before
the click — the processing has moved from the controls into the audio.
- The capture-signal popup exposes note length, start offset, and end
offset — each readable and editable in both ms and beats — plus velocity;
its preview trigger auditions the capture note exactly as programmed, and
the bake renders that same programmed performance (preview and bake
cannot diverge).
- A Gate-mode bake terminates on its own: the gate holds for the programmed
note length, then releases — even with item 9's loop-sustain active, the
render ends (no indefinite capture).
- After the bake the root note is unchanged — iteration never detunes: the
next bake plays the same root.
- Sole-reference case: the bank afterwards shows the recapture where the
source capture's entry was; no other bank entry is disturbed.
Other-references case: the original entry is untouched, a distinct new
entry appears, and every other holder of the original sounds exactly as
before.
Other-references case (provenance-tied usage of the original exists): the
original entry is untouched, a distinct new entry appears, and every
other holder of the original sounds exactly as before.
- The click deletes no file: the superseded audio file still exists on disk
afterwards, and only a later prune — under the settled orphan rules, only
when nothing references it — can reclaim it.
@@ -1223,3 +1353,97 @@ through.
the first's result, repeatable indefinitely.
- Save/reload: an instance holding a recapture reloads and plays it exactly
like any other loaded capture.
---
## 16 — Enhancement (simplification): retire the zone mapping system — one capture = one parameter set
**Daniel's ask (verbatim, 2026-07-29 — answer 1 of item 15's answer round).**
> I don't actually care, or even really understand, our zones. Retire the
> zone mapping system, simplify. I don't expect to use it, reasampler 9000
> becomes 1 capture = one parameter set
**Intent.** Simplification by deletion, not a feature: the multi-zone
keymap — zones with note ranges, per-zone parameters, and the dedicated
zone-editing surface — comes out of ReaSampler 9000 entirely. Daniel's
motive is stated plainly: he does not use it, does not care to understand
it, and wants the instrument simpler. The instrument becomes what its
common case already is: **one loaded capture played through one set of
parameters.** This arrived as answer 1 of item 15's answer round — it is a
far larger change than the question it answers (item 15's multi-zone
scope), which it dissolves rather than resolves; hence its own item.
**Behavior.**
- **One capture = one parameter set.** (Daniel's words.) The instrument
holds one loaded capture and one set of playback parameters governing it.
No zones, no per-zone divergence, no keymap of captures.
- **The zone-mapping surface goes away.** Forced by the decision, not
separately decided: the dedicated zone-editing surface and its authoring
affordances — add/delete zone, the per-zone parameter panel, and the
Low/High/Root zone legend — exist only to author zones and retire with
them. (The root note itself survives as a first-class parameter of the
one set — item 15's answer round makes it explicitly resample-stable;
only its zone-legend housing goes.)
- **The per-zone/per-instance storage distinction collapses.** Forced:
today playback parameters store per-zone, with VOICE and MASTER the
per-instance exceptions, and panel parity keeps the two editing surfaces
in step. With one parameter set there is nothing to be an exception to
and no second surface to keep in parity — every parameter simply belongs
to the instrument. Items 2, 9, and 11 carry superseded-by notes where
they asserted the per-zone convention.
- **The single-capture experience is unchanged.** *(Derived, not a Daniel
quote: the retirement removes the multi-zone superstructure, not the way
a single capture plays — today's single-capture instrument already
behaves as one capture with one parameter set.)* A loaded capture still
plays across the keyboard repitched from its root, key-tracking still
applies, and every queued enhancement (items 1–15) lands on the one
parameter set unchanged in substance.
- **No effect on the bank or the extension.** The zone system is an
instrument-side mapping concept; captures, banks, the capture/placement
separation, and the prune safety model are untouched.
**Open questions.**
- **Migration of saved multi-zone instances — awaits a Daniel decision.** A
project saved with an instance carrying multiple zones — possibly with
different parameters per zone, possibly referencing different captures —
must become *something* under the one-capture model, and no natural
answer exists: adopt one zone's capture and parameters (which one?),
refuse to lift and stay silent until re-pointed, or something else. Every
option changes what such a saved project sounds like, so the doc's
standing sounds-identical migration bar cannot hold for genuinely
multi-zone instances — the bar itself needs Daniel's ruling here.
(Instances that were single-zone all along — the expected overwhelming
majority, per his "I don't expect to use it" — lift losslessly under any
answer.)
- **Does any key-range concept survive? — propose at implementation
review.** With zones gone, does the capture respond across the entire
keyboard (repitched from root), or does a user-settable low/high playable
range survive as a plain parameter of the one set? Lean, consistent with
the simplification motive: no range concept — full-keyboard response —
with a low/high pair re-addable later as ordinary parameters if missed.
Not Daniel-blocking because the lean is cheap to reverse.
- **What the piano strip means with no zones — propose at implementation
review, jointly with item 12.** Item 12 keeps the full-width note-range
piano strip and adds note-name tooltips; item 15 needs the root
affordance. With no zone bars to draw, the strip's surviving jobs are the
root display/affordance and the tooltips — plus a range display only if
the key-range question keeps one. Propose the strip's exact contents at
review alongside item 12's work.
**Acceptance criteria.**
- The editor exposes no zone-mapping surface anywhere: no zone view or
button, no add/delete-zone affordance, no per-zone parameter panel, no
Low/High zone legend. The root-note control survives as a first-class
parameter.
- Every playback parameter edits in exactly one place and governs the
instrument as a whole; no gesture can express per-zone divergence.
- A single-capture instance saved before this change reopens sounding
identical — same keyboard response, same parameters, same root.
- A multi-zone instance saved before this change lifts per whatever
migration rule Daniel settles (gated on the open question above).
- The one parameter set round-trips save/reload intact.
- Bank, capture, placement, and prune behavior are unchanged.