looper

Practice Rack Looper Workflow

Direct answer

Start input monitoring, enable the looper rack slot, place it where you want the capture point, then record the first pass and stop. A non-empty loop starts playing immediately. Use Overdub to mix another pass into the existing loop and Stop to return to playback. Clear removes the complete loop.

The current looper is intentionally simple. It does not implement separate overdub layers, undo, redo, loop-file save/reload, or automatic bar quantization. The previous Help page claimed all of those features and was incorrect.

Prepare monitoring

Loop capture requires active input monitoring and an enabled looper slot. Before recording:

select and start the correct input and output devices;
establish a safe listening level;
remove clipping at the interface and software input;
build and test the rack;
enable the looper;
set its signal position deliberately;
rehearse the phrase with a count-in outside the looper.

Use the audio setup quickstart if monitoring is not already stable.

Choose the capture point

Rack modules are processed in their displayed order, and the looper records the signal reaching its slot. Effects before the looper are printed into the loop. Effects after it can process loop playback together with the live path, depending on the active chain.

Placement	Captured loop	Practical use
After amp and cabinet	Amped backing tone	Change later modulation for the live part
After delay and reverb	Full wet sound	Preserve a specific ambient backing
Before delay and reverb	Drier source	Apply shared space after capture
Early in chain	Minimally processed source	Experiment with downstream tone carefully

Changing an effect before the looper after capture does not retroactively reprocess samples already stored in the loop. Reordering the rack during playback can change downstream processing, so save a preset before experimenting.

Record the base pass

Click the looper Record control. Recording starts a new loop and clears the previous loop buffer. Play the intended phrase once, then click Stop at the boundary. If audio was captured, playback begins from the start.

There is no documented count-in or automatic trimming. Timing is determined by when Record and Stop are activated. Global tempo can guide the performance and synchronize supported modulation or delay effects, but it does not repair loop length.

For a clean loop:

rehearse the entry and exit;
use an external metronome or the displayed tempo reference;
avoid changing latency settings during capture;
let sustained effects finish only if they belong inside the loop;
stop on the same musical boundary where recording began.

Read the status

The UI reports recording, playing, overdubbing, ready, or empty state, plus duration and a waveform preview. A waveform proves samples exist; it does not prove timing, level, phase, or musical correctness.

State	Meaning
Empty	No loop buffer
Recording	New base loop is being captured
Playing	Existing buffer repeats
Overdubbing	Live input is mixed into the repeating buffer
Ready/stopped	Buffer exists without an active capture state

Overdub carefully

Overdub requires an existing loop and active monitoring. It starts from the beginning of the buffer and mixes incoming audio into that buffer as it repeats. Stop the overdub after the intended pass.

Overdubs are not stored as independent tracks. There is no current undo or redo command. A bad overdub changes the loop and cannot be removed separately. If the base pass matters, use the top-level recorder to capture a safety WAV before overdubbing.

Keep overdub levels conservative. Adding signals directly can build peak level and mask timing errors. Listen to one full cycle before adding another part.

Stop and clear

Stop ends base recording or overdub and leaves a non-empty loop playing. Clear resets the buffer, duration, waveform, and playback/capture state.

Clear is destructive within the current session. Confirm the loop is disposable or recorded elsewhere before using it. A new Record action also starts a new base loop and clears the existing buffer.

Save the audible result

There is no separate Save loop command. To retain the loop:

stop any active overdub;
let the loop play;
open the top-level recorder;
choose a WAV output path and channel mode;
start recording before the desired loop boundary;
capture the required number of cycles and live part;
stop recording;
open the saved WAV and verify it.

The recorder captures final output, so downstream effects and live playing can be present. If the goal is an isolated backing loop, mute or bypass anything that should not be included.

Tempo and synchronization

Manual global tempo and tap tempo are available. Chorus, phaser, tremolo, and delay can use tempo-sync parameters. The looper itself does not currently quantize duration to a bar or expose a beat-grid correction.

Professional sync playback is a separate capability that aligns global tempo and position with the product’s synchronized playback workflow. It does not create undoable looper layers.

Practice patterns

For rhythm practice, record two or four clean bars and play a different rhythm over them. For lead practice, keep the backing dry enough to hear timing. For tone comparison, record a simple phrase before downstream effects and change one later module at a time.

Do not call a percussive guitar tap a bass or drum recording unless the instrument and pitch actually support that description. Label practice captures by what they contain.

Looper QA

Monitoring is stable and safe.
Looper slot is enabled.
Capture position in the rack is intentional.
Base phrase is rehearsed before Record.
Loop length is checked for a full cycle.
Peak level leaves room for overdubs.
Important base audio is captured with the recorder before destructive overdub.
No undo, redo, layer, save-loop, or quantization feature is assumed.
Final WAV is reopened and checked.
Clear is used only after retention is settled.

FAQ

Can I undo the last overdub?

No. The current implementation mixes overdub audio into one loop buffer and has no undo/redo command.

Does the looper snap to BPM?

No automatic bar quantization is currently documented. Use tempo as a performance reference and start/stop accurately.

How do I save a loop?

Record the final output to WAV while the loop plays. There is no dedicated loop-file save/reload workflow.

Direct answer and acceptance boundary

For “Practice Rack Looper Workflow”, the short answer is: Record, play, overdub, stop, clear, and externally capture a Practice Rack loop while understanding signal order and the current looper's non-layered limits. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Practice Rack.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Practice Rack Looper Workflow

Treat “Practice Rack Looper Workflow” as a separate acceptance gate for “Practice Rack Looper Workflow”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: Record, play, overdub, stop, clear, and externally capture a Practice Rack loop while unde

Verify “Record, play, overdub, stop, clear, and externally capture a Practice Rack loop while understanding signal order and the current looper's non-layered ” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Direct answer

For “Direct answer”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Prepare monitoring

Use “Prepare monitoring” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Choose the capture point

When “Choose the capture point” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Record the base pass

Close “Record the base pass” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Read the status

Treat “Read the status” as a separate acceptance gate for “Practice Rack Looper Workflow”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Overdub carefully

Verify “Overdub carefully” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Stop and clear

For “Stop and clear”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Save the audible result

Use “Save the audible result” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Practice Rack Looper Workflow	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Record, play, overdub, stop, clear, and externally capture a Practice Rack loop while understanding signal order and the	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Prepare monitoring	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Choose the capture point	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Record the base pass	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: