docs(todo-1.0): item 15 — one-click in-sampler resample (fourth batch, 2026-07-29); five questions await Daniel
This commit is contained in:
+170
-3
@@ -3,7 +3,8 @@
|
||||
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 14 is a third, single-item batch (2026-07-28, later again); item 15 is
|
||||
a fourth, single-item batch (2026-07-29).
|
||||
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
|
||||
@@ -73,14 +74,28 @@ filter question: **the filter envelope follows the same mode-driven shape** —
|
||||
Gate → AHDSR, Trigger → AHD. Item 8's scope rule now governs all three
|
||||
envelopes uniformly (the general statement lives in item 14; item 2 carries a
|
||||
cross-reference), and item 14's remaining stage-value question now covers the
|
||||
filter envelope too. **With that, no open question anywhere in the doc awaits
|
||||
a Daniel decision.** Everything still open across all 14 items is
|
||||
filter envelope too. **With that, no open question in items 1–14 awaits a
|
||||
Daniel decision.** Everything still open across all 14 items is
|
||||
verify-or-propose-at-implementation: item 9's loop-point regression
|
||||
verification and its spec details, item 11's
|
||||
does-a-pitch-velocity-curve-already-exist check, and item 14's
|
||||
shared-vs-per-mode stage-value question. Nothing in items 1–14 is blocked on
|
||||
Daniel.
|
||||
|
||||
A **fourth batch** (2026-07-29) appends item 15 — a single enhancement Daniel
|
||||
himself frames as "a pretty radical feature idea": one-click resampling from
|
||||
inside the ReaSampler 9000. An offline pass through the instrument's own
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
@@ -99,6 +114,13 @@ AHD definition and item 1's curve treatment — cheapest folded into or
|
||||
immediately after that combined work — and repaints amp-deck/overlay surface
|
||||
that items 10 and 13 later polish; its filter half (the filter envelope
|
||||
following the same mode-driven shape) necessarily lands with or after item 2.
|
||||
Item 15 (fourth batch) presupposes the processing surface it bakes —
|
||||
"filtering, pitching, amp all set up nice" is the instrument items 1, 2, 3,
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
@@ -1056,3 +1078,148 @@ follow-up round extends the same rule to item 2's filter envelope.
|
||||
semantics, curve treatment, and overlay mapping match. (This is the
|
||||
observable proxy for the consolidation motive: one staged-envelope design,
|
||||
two consumers.)
|
||||
|
||||
---
|
||||
|
||||
## 15 — Enhancement: one-click in-sampler resample — bake the dialed sound into the bank and iterate
|
||||
|
||||
**Daniel's ask (verbatim, 2026-07-29).**
|
||||
|
||||
> I would like the ability to somehow resample from directly inside the
|
||||
> ReaSampler 9000 VST. Once I have the filtering, pitching, amp all set up
|
||||
> nice, one click should:
|
||||
> send a trigger or gate through the sampler offline, capture the audio,
|
||||
> replace the bank source capture with the recapture (or add a new distinct
|
||||
> one if there are other references), replace that sampler capture with the
|
||||
> new/corrected bank capture, and reinitialize the reasampler 9000 audio
|
||||
> parameters to default, effectively allow reiteration over sounds from
|
||||
> within the sampler.
|
||||
|
||||
**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
|
||||
neutral, ready to be dialed again. Daniel frames it as a radical feature, and
|
||||
it is: it turns the sampler from a player of captures into an iterative
|
||||
resampling instrument, with the bank as the medium each iteration passes
|
||||
through.
|
||||
|
||||
**Behavior.**
|
||||
|
||||
- **One gesture, whole chain.** A single click performs the full sequence:
|
||||
offline pass → capture → bank update (replace or add-distinct) → instance
|
||||
re-point → parameter reset. The steps are one action from the user's side,
|
||||
not a wizard.
|
||||
- **Offline pass through the instrument's own processing.** The audio is
|
||||
produced by sending a trigger or gate through the sampler **offline** — the
|
||||
instrument's own voice path, with the filtering, pitching, and amp exactly
|
||||
as dialed, renders the result. The recapture is of that processed output,
|
||||
not of the raw source.
|
||||
- **The recapture is a bank capture like any other.** It lands in the bank —
|
||||
project-relative, indexed, browsable from any surface that browses the
|
||||
bank — and is governed by the same safety rules as every file the system
|
||||
itself creates.
|
||||
- **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.)
|
||||
- **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
|
||||
prune action is the system's only file-deletion authority admits no other
|
||||
reading — resample writes a new file and retires the old one to
|
||||
reclaimable-by-prune status; it never overwrites or deletes it.)* Until a
|
||||
prune reclaims it, the pre-bake audio therefore survives on disk — the
|
||||
iterate loop's built-in recovery floor, whatever the undo question below
|
||||
settles.
|
||||
- **The instance re-points.** The sampler's loaded capture is replaced with
|
||||
the new/corrected bank capture — the instrument now plays the baked sound.
|
||||
- **Parameters reinitialize to default.** After the swap, the instrument's
|
||||
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.
|
||||
- **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.)*
|
||||
|
||||
**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.
|
||||
- **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
|
||||
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.
|
||||
|
||||
**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).
|
||||
- The bake is audible and faithful: after the click, playing what the
|
||||
offline pass played (same note, same velocity, same 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.
|
||||
- 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.
|
||||
- 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.
|
||||
- The arrange timeline is untouched: no item appears anywhere, on any track.
|
||||
- Iteration composes: dial → click → dial → click bakes the second pass onto
|
||||
the first's result, repeatable indefinitely.
|
||||
- Save/reload: an instance holding a recapture reloads and plays it exactly
|
||||
like any other loaded capture.
|
||||
|
||||
Reference in New Issue
Block a user