Every operation that rewrites or removes a slot's audio — replace, clear, trim,
downmix, normalize — moves the original to the app's archive first, on purpose,
as an undo. But there is still no way back from the UI: to recover a take you
have to open the folder in a file manager and push the file in by hand. The
safety net exists; it has no door.
With #72 recording what happened, the door is a History tab beside Audio and
Properties, showing the selected slot's timeline.
- A row says when, what, and what it did to this slot in words: the name, the
tempo, the length, "recorded on the pedal while away" — and whether its audio
is still kept.
- Audition plays the archived take out of the local store: the blob is extracted
to a temp file and played from there — measured at 0.06-0.55 s for the largest take
we have, 161 MB. Never from the pedal: no USB traffic, and it works with the pedal
unplugged. "Which take was the good one" is the whole reason to keep takes.
- Restore this take puts the chosen state back.
Restore is not push
push recomputes Tempo, RecTmp, MeasLen and Measure from the frame count. That is
right for an import and wrong for a restore — it would overwrite the tempo the
state carried. Restore needs its own core primitive that takes a slot state as
one unit: the whole slot body, spliced into the live document through
slotBody/replaceSlotBody, plus its audio. It must refuse when the body's WavLen
does not equal the frames of the file that will sit in the slot. A body restored
next to somebody else's audio is how a slot ends up unplayable, and it is the
natural outcome of "restore the settings" and "restore the take" being two
buttons. One button, one unit.
An old memory document is never written wholesale: the other 98 slots belong to
the present.
Two phases, because the worker cannot ask questions
- Read the current slot and fingerprint it. The copy into the archive hashes for
free, so the take that is about to be replaced is kept whether or not anyone
expected it to be there.
- If what is on the card is not what we left, the message thread says so — this
slot was recorded on the pedal since, and it is now in the history — and waits
for an answer.
- Write with the standard discipline: archive, write, verify, sweep.
The restore is itself recorded, so it is undoable in turn.
Swap rows
A swap is one operation over two slots, and it is atomic here too. Its button
reads "Undo swap — slots A and B" and runs the swap primitive again: renames on
FAT, no audio bytes move. It is offered only while both slots still hold what the
swap left; when one of them has moved on, the app says which, and points at the
other verb.
That other verb is "Restore this take here", for "I just want my old take back".
It copies rather than undoes, it may leave the same take in two slots, and it
says so before it does.
Every operation that rewrites or removes a slot's audio — replace, clear, trim,
downmix, normalize — moves the original to the app's archive first, on purpose,
as an undo. But there is still no way back from the UI: to recover a take you
have to open the folder in a file manager and push the file in by hand. The
safety net exists; it has no door.
With #72 recording what happened, the door is a History tab beside Audio and
Properties, showing the selected slot's timeline.
tempo, the length, "recorded on the pedal while away" — and whether its audio
is still kept.
to a temp file and played from there — measured at 0.06-0.55 s for the largest take
we have, 161 MB. Never from the pedal: no USB traffic, and it works with the pedal
unplugged. "Which take was the good one" is the whole reason to keep takes.
Restore is not push
push recomputes Tempo, RecTmp, MeasLen and Measure from the frame count. That is
right for an import and wrong for a restore — it would overwrite the tempo the
state carried. Restore needs its own core primitive that takes a slot state as
one unit: the whole slot body, spliced into the live document through
slotBody/replaceSlotBody, plus its audio. It must refuse when the body's WavLen
does not equal the frames of the file that will sit in the slot. A body restored
next to somebody else's audio is how a slot ends up unplayable, and it is the
natural outcome of "restore the settings" and "restore the take" being two
buttons. One button, one unit.
An old memory document is never written wholesale: the other 98 slots belong to
the present.
Two phases, because the worker cannot ask questions
free, so the take that is about to be replaced is kept whether or not anyone
expected it to be there.
slot was recorded on the pedal since, and it is now in the history — and waits
for an answer.
The restore is itself recorded, so it is undoable in turn.
Swap rows
A swap is one operation over two slots, and it is atomic here too. Its button
reads "Undo swap — slots A and B" and runs the swap primitive again: renames on
FAT, no audio bytes move. It is offered only while both slots still hold what the
swap left; when one of them has moved on, the app says which, and points at the
other verb.
That other verb is "Restore this take here", for "I just want my old take back".
It copies rather than undoes, it may leave the same take in two slots, and it
says so before it does.