diff --git a/TODO-1.0.md b/TODO-1.0.md index 0e5882b..55d0f3a 100644 --- a/TODO-1.0.md +++ b/TODO-1.0.md @@ -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.