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

docs(todo-1.0): record second fourth-batch answer round

Browse Source 
Item 16 migration settled (adopt first zone); item 15 capture window specced, reset scope ratified; new item 17: provenance/usage consolidation. Nothing awaits Daniel.
This commit is contained in:
Daniel Harvey
2026-07-29 11:18:41 -04:00
parent d8651fb7a7
commit b5788c82f6
1 changed files with 283 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO-1.0.md
+283 -59
View File
@@ -6,7 +6,10 @@ extension-side bugs. Items 1–3 are the first batch, in Daniel's ordering
item 14 is a third, single-item batch (2026-07-28, later again); item 15 is
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).
answer round (the zone mapping system is retired); item 17 (2026-07-29) is
likewise not a new ask batch — it records the requirement mandated by
answer 1 of the second fourth-batch answer round (the provenance/usage
tracking consolidated and made 100% robust).
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
@@ -107,9 +110,28 @@ 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
beats, velocity, and a preview trigger). **Daniel-blocked state after that
round: exactly one question awaited a Daniel decision — item 16's migration
of saved multi-zone instances** (since settled; next paragraph).
A **second fourth-batch answer round** (2026-07-29) — one message — settled
that migration question and answered the doc's three under-specification
flags. The unnumbered opening line rules the migration: **adopt the first
zone's capture and parameters** — a lossy rule Daniel accepts because he has
**no projects with zones in use**; for a genuinely multi-zone instance the
doc's standing sounds-identical migration bar is **deliberately relaxed**
(recorded in item 16). Answer 1 converts the doc's provenance-consolidation
flag into a requirement — **the provenance/usage tracking is to be
consolidated and made 100% robust** — recorded in full as **item 17**, on
which item 15's replace-vs-add rule now explicitly depends. Answer 2
("that's good") ratifies item 15's derived reset-scope classification —
promoted from derived to confirmed by Daniel. Answer 3 settles the
capture-window semantics: the start/end offsets anchor to **note-on and
note-off** of the programmed note; note length is a **musical division**
(1/64th through 64/1, with dotted and triplet multipliers), not a free
duration; beats resolve against **the project tempo under the cursor**.
**Current Daniel-blocked state: no open question anywhere in items 1–17
awaits a Daniel decision.** Everything still open is
verify-or-propose-at-implementation.
Ordering note: item 1's curve/overlay treatment explicitly anticipates item 2's
@@ -144,6 +166,13 @@ 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.
Item 17 (provenance/usage consolidation) is likewise a **prerequisite of
meaning** for item 15's bank-side half — the replace-vs-add rule is
computable only once the consolidated lineage records exist — and is
independent of the editor chain (items 1–14); it reworks tracking machinery
today's prune protections ride, so those guarantees must hold undiminished
through the consolidation. Landing it with or before item 15's bank-side
half is the natural order.
---
@@ -1154,6 +1183,23 @@ five questions this item carried as awaiting a Daniel decision:
> system
> 5. Undo/Recovery is a plus
**Daniel's second answer round (verbatim, 2026-07-29)** — the fourth
batch's second answer round. The unnumbered opening line answers item 16's
migration question (carried there); the numbered answers map, in order,
onto the doc's three under-specification flags: the
provenance-consolidation flag (→ item 17), this item's derived reset-scope
classification, and this item's capture-window semantics:
> adopt the first zone's capture and parameters, I don't have any projects
> with zones used
>
> 1. the provenance/usage tracking will need to be consolidated and made
> 100% robust
> 2. that's good
> 3. yeah relative to note-on and note-off of the programed note length
> (1/8., 1/4t, 1/16, 4/1 etc (1/64th to 64/1 with dotted and triplet
> multipliers)). the project tempo under the item cursor.
**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
@@ -1225,14 +1271,29 @@ through.
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.)*
- **Note length is a musical division, not a free duration.** The
programmed note length is chosen from musical divisions spanning
**1/64th through 64/1, with dotted and triplet multipliers** (Daniel's
examples: `1/8.`, `1/4t`, `1/16`, `4/1`). *(Settled by second answer
round.)*
- **Offsets anchor to note-on and note-off.** The start offset is
relative to the programmed note's **note-on**; the end offset is
relative to its **note-off**. *(Settled by second answer round.)*
- **Beats resolve against the project tempo under the cursor.** A
beat-denominated value — the note-length division always, the offsets
when expressed in beats — resolves to time against **"the project
tempo under the item cursor"** (Daniel's phrase; read plainly: the
tempo in effect at the project's cursor position when the preview or
bake runs). *(Settled by second 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.)*
round; the anchors are settled by the second answer round — with the
end offset anchored to note-off, the tail reading is direct, no longer
a derivation.)*
- **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.
@@ -1241,8 +1302,10 @@ through.
"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)*:
per-parameter classification follows — it began as this doc's derivation
and is now **confirmed by Daniel** ("that's good," second answer round);
the record that it originated as a reading-off is preserved, but the
reset/survive lists below are ratified, not derived:
- **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
@@ -1268,7 +1331,11 @@ through.
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.
lineage question below — answer 4 makes that question load-bearing, and
the second answer round's answer 1 converts the dependency into a
requirement in its own right: **item 17** (the provenance/usage tracking
consolidated and made 100% robust), on which this rule now explicitly
depends.
- **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
@@ -1282,41 +1349,48 @@ through.
(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.
- **Capture-window residuals — propose at implementation review.** The
second answer round settles the anchors (note-on / note-off), the tempo
source (the project tempo under the cursor), and note length as a
musical division (1/64th–64/1, dotted/triplet). Two residuals remain:
whether negative offsets are meaningful (unchanged from before); and a
denomination seam — the first answer round expressed the offsets "in ms
AND in beats" while note length is now musical-division-only. The plain
reading is that the ms/beats duality applies to the offsets only; if an
ms display or entry for note length seems wanted at implementation,
propose it at review rather than assuming either way.
- **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.
settled and the per-parameter classification above is now ratified by
the second answer round ("that's good"). Only a genuinely new parameter —
one arriving with a queued item and absent from the ratified lists — 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; 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, 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.
- **Provenance of the recapture — homed in item 17.** 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
made this load-bearing (replace-vs-add is decided by usage ties, so the
settled record-nothing conservative default is no longer available for
the lineage half — the recapture must carry whatever record makes
answer 4's decision computable), and the second answer round's answer 1
converts it into **item 17**, where the consolidation requirement and
its open questions now live. This item's dependency stands: its
replace-vs-add half is meaningful only once item 17's consolidated
lineage exists.
- **Naming and lineage — propose at implementation review, jointly with
item 17.** 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 as one proposal with
item 17's lineage-record question, on which answer 4 leans.
- (The multi-zone migration question this list previously carried is
settled in item 16 by the second answer round — adopt the first zone's
capture and parameters; a pre-existing multi-zone instance's resample
therefore bakes its first zone's sound.)
**Acceptance criteria.**
@@ -1330,11 +1404,16 @@ through.
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).
- The capture-signal popup exposes: note length as a musical-division
picker spanning 1/64th to 64/1 with dotted and triplet multipliers;
start and end offsets, each readable and editable in both ms and beats,
anchored to note-on and note-off respectively; and velocity. Its preview
trigger auditions the capture note exactly as programmed, and the bake
renders that same programmed performance (preview and bake cannot
diverge).
- Beat-denominated values resolve against the project tempo under the
cursor: the same programmed division yields a correspondingly different
rendered duration when the tempo at the cursor differs.
- 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).
@@ -1342,9 +1421,10 @@ through.
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 (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.
Other-references case (provenance-tied usage of the original exists —
the tie computed by item 17's consolidated tracking): 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.
@@ -1364,6 +1444,12 @@ through.
> zone mapping system, simplify. I don't expect to use it, reasampler 9000
> becomes 1 capture = one parameter set
**Daniel's follow-up (verbatim, 2026-07-29 — the second answer round's
unnumbered opening line, answering this item's migration question).**
> adopt the first zone's capture and parameters, I don't have any projects
> with zones used
**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
@@ -1393,6 +1479,24 @@ scope), which it dissolves rather than resolves; hence its own item.
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.
- **Migration: adopt the first zone's capture and parameters.** *(Settled
by the second answer round.)* A saved multi-zone instance lifts to the
one-capture model by adopting its **first zone's** capture and that
zone's parameters; the remaining zones' captures and parameters drop
from the instance. Dropping a zone touches no file and no bank entry —
the instance simply no longer holds those captures; bank and prune
behavior are unchanged, per the bullet below. Daniel's stated rationale
is what makes a lossy rule acceptable here: **he has no projects with
zones in use**, so the migration path carries essentially no real-world
risk — no actual project sounds different under it. Consequently, for a
genuinely multi-zone instance the doc's standing sounds-identical
migration bar is **deliberately relaxed**: such an instance reopens
playing its first zone's sound only, and that is the accepted outcome —
accepted for that reason. Single-zone instances — the actual universe —
lift losslessly and reopen sounding identical, so the bar holds
everywhere it has real referents. (Which zone is "first" — the
instance's existing zone ordering — is a verify-at-implementation
detail with no real-world stakes, given the rationale.)
- **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
@@ -1406,18 +1510,12 @@ scope), which it dissolves rather than resolves; hence its own item.
**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.)
- The migration question this item carried as awaiting a Daniel decision
is **settled by the second answer round** — adopt the first zone's
capture and parameters — and folded into Behavior above, with his
rationale (no projects with zones in use) recorded there. **Nothing in
this item awaits a Daniel decision.** What remains is
propose-at-implementation-review:
- **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
@@ -1443,7 +1541,133 @@ scope), which it dissolves rather than resolves; hence its own item.
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).
- A multi-zone instance saved before this change reopens holding its first
zone's capture with that zone's parameters — no error, no file touched,
no bank entry disturbed. (The sounds-identical bar deliberately does not
apply to this case: the instance reopens playing the first zone's sound
only — the settled, accepted outcome.)
- The one parameter set round-trips save/reload intact.
- Bank, capture, placement, and prune behavior are unchanged.
---
## 17 — Enhancement (requirement): consolidate provenance/usage tracking — one system, 100% robust
**Daniel's ask (verbatim, 2026-07-29 — answer 1 of the second fourth-batch
answer round).**
> the provenance/usage tracking will need to be consolidated and made 100%
> robust
**Intent.** A requirement, not a feature: the tracking machinery in the
provenance/usage territory becomes one coherent, fully robust system. This
began as a doc flag — item 15's answer 4 made recapture lineage
load-bearing while the territory's mechanisms were separate and ad-hoc —
and Daniel's answer converts the flag into a standing requirement. Today
the territory holds two separately-grown mechanisms plus one new demand:
(1) the **capture-recipe fingerprint** — a thin reproducibility record of
how a capture was made, deliberately not a restorable chain, conservatively
recording nothing when the situation is ambiguous; (2) the **instance-usage
tracking** — each live instrument instance declares the captures it holds,
so the prune can never delete a capture a live instance is using, with a
fail-safe stance that unreadable usage state halts the prune entirely; and
(3) item 15's demand for **recapture lineage** — records tying usages of a
capture to it "by the provenance/recaptureing system," deciding
replace-vs-add at bake time. "Consolidated" plainly means these stop being
separate ad-hoc mechanisms: one tracking system in which recipe provenance,
live usage, and recapture lineage are facets of the same record-keeping.
"100% robust" is a strength statement Daniel chose deliberately: this
territory gates the system's only file-deletion authority (prune) and its
only capture-replacement act (item 15's resample) — the two places where a
tracking error loses a user's audio or sound.
**Behavior.**
- **One system, not three mechanisms.** Recipe provenance, live-instance
usage, and recapture lineage are kept by one consolidated tracking
system, and every consumer — the prune's protection decision, the
resample's replace-vs-add decision, and any future lineage reader — is
answered from it.
- **What "100% robust" observably means.** Daniel stated the strength, not
the mechanics; the territory's stakes force three observable
implications, recorded without inventing further specifics:
- **No silent gaps.** Every capture the system itself creates is tracked
from the moment of its creation; a recapture carries its lineage from
birth, never backfilled. There is no window in which a
system-created file exists untracked.
- **Fail-safe on unreadable or ambiguous state.** Tracking state that
cannot be read never yields the destructive answer: the prune deletes
nothing (today's settled stance — preserved and generalized, not
relaxed), and the resample never takes the replace branch on
unreadable lineage (whether the safe branch is add-distinct or a halt
with a clear message is propose-at-review).
- **Consumers cannot disagree.** The prune's protection answer and the
resample's tied-usage answer are different questions with different
universes — item 15 settles that the replace-vs-add universe is
narrower than the prune-protection universe — but both are computed
from the same consolidated records, so they cannot drift apart or
contradict.
- **Existing guarantees are the floor.** Consolidation must not weaken
anything now settled: the prune still deletes only the system's own
orphans and never a referenced or live-held capture; the fail-safe abort
on unreadable usage state survives; the recipe fingerprint's
record-nothing-when-ambiguous conservatism survives for the recipe half.
The lineage half is the one place that conservatism is foreclosed —
item 15's answer 4 makes the lineage record mandatory for a recapture,
since replace-vs-add must be computable.
- **Dependency of meaning for item 15.** Item 15's replace-vs-add rule is
computable only once this item's consolidated lineage exists; item 15's
provenance-of-the-recapture question is homed here, and its
naming-and-lineage question is proposed jointly with this item's
lineage-record question. This is dependency of meaning, not merely
sequencing: without this item, "usage tied by the provenance/recapture
system" denotes nothing.
**Open questions.**
- None awaiting a Daniel decision — the requirement and its strength are
his; the shape is review work:
- **The consolidated shape — propose at implementation review.** What "one
system" concretely is (one record family, one authority, how the three
facets relate) is design work proposed at review, not a Daniel call.
- **The lineage record — propose at implementation review, jointly with
item 15's naming-and-lineage question.** What constitutes a "usage tie,"
when it is written, whether it is ever severed, and whether iteration
lineage is user-readable from the bank.
- **The recipe-fingerprint half of a recapture — propose at implementation
review.** A resample's recipe is the instrument's own settings, not a
track chain; whether the fingerprint records a resample-shaped recipe —
and what its conservatism means there — is proposed at review. (The
lineage half has no record-nothing option; the recipe half may keep
one.)
- **Never-recorded vs. unreadable — propose at implementation review.**
Pre-existing captures predate lineage records, and the two absences
demand opposite treatment: never-recorded means no tied usage exists
(replace is legitimate, per item 15's settled rule); unreadable means
fail-safe. How the consolidated system distinguishes them — and how
pre-existing banks lift in without weakening any protection they enjoy
today — is proposed at review.
**Acceptance criteria.**
- One consolidated tracking system answers both safety-critical consumers:
the prune's protected set and the resample's replace-vs-add decision are
each computed from it, per their own settled rules; no separate ad-hoc
tracking mechanism remains in the territory.
- No silent gaps: a recapture created by item 15's bake is tracked from
the instant it exists — a bake followed immediately by a prune, or by a
second bake, behaves correctly with no window in which the recapture is
untracked or its lineage absent.
- Fail-safe throughout: with tracking state made unreadable, the prune
deletes nothing (and reports what blocked it, per today's behavior) and
the resample never takes the replace branch; no destructive act follows
from ambiguity, anywhere in the territory.
- Every protection settled today holds undiminished after consolidation: a
capture held by a live instance cannot be pruned; files the system did
not create are untouchable; unreadable usage state still halts the
prune.
- A pre-existing bank lifts into the consolidated system with no loss of
protection and no spurious lineage, and never-recorded remains
distinguishable from unreadable.
- Item 15's other-references case is decidable: for any capture, "does
provenance-tied usage exist" has a definite yes/no answer.