Usage¶
ShoopDaLoop buttons provide tooltips for their current action. Context menus on tracks and loops expose operations that apply to that object. The main menu contains session, connection, and application settings actions.
Loops¶
Transitions¶
Primitive loops can play, record, stop, and grab. Dry/wet loops additionally support playing recorded dry content through the processor and recording that processed result into wet content. Synchronized actions wait for the sync or target loop; immediate actions do not.
Selection applies a transition to multiple loops. Solo mode stops competing loops in affected tracks. Auto-play determines whether a completed recording or grab starts playback. The record-cycle control sets a fixed duration; zero is unbounded.
Playback controls¶
Each loop has playback gain and, for stereo content, balance. The status area shows current mode, pending transitions, selection, targeting, and loop progress. A double click on the status area targets a loop. Touch mode can be toggled in the Appearance settings. In the browser it defaults on when the device has no hover capability; native builds default it off. In touch mode, the play, record, and stop controls are always visible, hover-only action variants are unavailable, and a stationary long touch opens the loop’s context menu.
Grabbing¶
Grab copies recent input from bounded always-on recording buffers. In synchronized mode it ends at the most recently completed sync boundary. In immediate mode it includes the current interval and records its remainder. A targeted loop can provide alignment instead of the global sync loop.
Click-track generation¶
Right-click a primitive audio or MIDI loop and choose Generate click track…. The dialog supports primary/secondary audio sounds or MIDI notes, fractional tempo, click count, odd-click delay, and fitting to an existing loop length. Preview is non-mutating. Generated media is saved as ordinary loop content.
Files¶
The main menu saves and loads versioned .shoop sessions. Loop context menus
import or export exact .shoop-audio/.shoop-midi, float WAV, and standard
MIDI. Different sample rates require confirmation before deterministic timing
and media conversion.
Loop details¶
Select one primitive loop and open the bottom details pane to inspect its media. Audio channels appear as waveforms. MIDI channels appear as read-only piano-roll lanes with note pitch, timing, duration, loop region, and playback position. Mixed loops show both kinds of channel. Drag a lane horizontally to pan and use its zoom control to change the visible time range.
The basic MIDI lane displays note messages only. Controller, pitch-bend, pressure, program, and SysEx messages remain in the loop but are not drawn. Inspecting details never changes loop content.
On-screen MIDI piano¶
The bottom piano pane spans MIDI notes 0–127. Pointer presses send channel-1 notes to every monitored track with a MIDI input. Releases follow the tracks that received the press, including after monitoring changes; pane closure and focus loss release held notes.
Tracks¶
Adding a track¶
Use Add Track to create a Regular, Trigger, or Dry + Wet track. Trigger tracks have no audio or MIDI channels. The dialog configures the display name, audio-channel counts, optional MIDI, and, for processed tracks, the processor kind and default playback mode. The make default option stores the complete draft for the next track. Dry + Wet tracks may use regular wet playback or replay their dry recording through live effects as their default; other track types always use regular playback.
Native processor choices are External, Built-in FX, Built-in Synth, and feature-dependent Carla modes. Browser builds offer both built-ins. Built-in FX accepts matching mono, stereo, or higher dry/wet audio counts and requires one MIDI input. Built-in Synth has two dry inputs, two wet outputs, and one MIDI input.
Track controls¶
Input gain affects monitored and recorded input. Input mute disables monitoring without discarding recording input. The top-bar exclusive-input toggle makes enabling one track’s input monitoring mute all other track inputs, which is useful when switching recording tracks.
The separate top-bar Auto-arm track inputs toggle defaults on. While script composites run, it enables input monitoring for each track one sync cycle before a child loop records or replaces and keeps it enabled through that capture. Simultaneous recordings may monitor multiple tracks regardless of the exclusive-input setting. Afterward, auto-arm remutes only tracks that it enabled; tracks monitored beforehand remain monitored. This cycle-ahead application control is intentionally not sample-exact.
Output gain and mute affect monitored and played-back output. Stereo sides expose balance controls. Meters and MIDI activity indicators summarize applicable ports.
A track title can be edited after creation. Its stable port-name base does not change when the title changes. A Dry + Wet track’s options menu can change its default playback mode without affecting playback already in progress.
The default loop action resolves that preference whenever it would start a primitive loop’s playback. Explicit Play, Play Dry Through Wet, and script event modes remain explicit. Regular composites have only ordinary playback: each scheduled child uses its owning track’s current default when triggered. Script composites retain an explicit mode on every scheduled event.
Connections and processors¶
Open Connections… from a track menu for a track-scoped matrix, or use the main-menu Connections action for all tracks. The Tracks tab always shows System inputs and lets you toggle its destination between Buses and System outputs; the two destination sets are never shown together. The Bus outputs tab connects bus outputs to System outputs independently of track scope. Switching views never changes hidden links. External dry/wet tracks expose dry input/send and wet return/output ports. Hosted processors keep their internal endpoints private while exposing applicable dry inputs, wet outputs, and dry MIDI.
The all-tracks Connections dialog also exposes Global FX Control MIDI In. CC 0–119, channel pressure, and pitch bend on all MIDI channels fan out to every MIDI-capable FX processor without being recorded, replayed, or turned into automation. Notes, poly pressure, program changes, channel-mode CC 120–127, system messages, SysEx, malformed messages, and other event-like traffic are filtered. Sleeping processors keep only the latest value for each supported control and apply it when normal processing resumes; the controller does not wake their DSP. A dense restore is bounded and may finish over several active audio blocks.
Connecting one controller to both this port and a track MIDI input is additive: absolute controls can be applied twice, relative encoders may behave incorrectly, and only the regular track copy can be recorded. Some host MIDI APIs cannot open the same hardware endpoint twice; in that case the failed connection remains unconfirmed and is reported in the matrix.
Control interpretation remains processor-owned. Configure Carla parameter mappings in Carla. External chains respond only to controls they already support. Built-in Synth provides MIDI Learn for its reverb-send and chorus-send controls. Built-in FX provides the same learn/assign/remove workflow for every continuous rack control. It has no default mappings; toggles and type selectors are not MIDI targets. Notes and unsupported messages on its MIDI input are ignored.
Processed-track controls show only capabilities advertised by the selected processor. Both built-ins use embedded editors. Carla tracks expose lifecycle, UI, recovery, state, and bounded process-log controls when available.
Built-in FX is powered by FunDSP. Its fixed order is Compressor, Drive, three-band EQ, Chorus, Modulation, then Reverb. Drive offers Saturation, Overdrive, Distortion, and Fuzz; Modulation offers Tremolo, Flanger, and Phaser; Reverb offers Room, Hall, and Plate. Each stage has a toggle and a compact set of continuous controls in the embedded editor. Mono is processed as mono, exactly two channels use linked/decorrelated stereo behavior, and larger channel counts remain isolated. A disabled stage does not run effect DSP; disabling or changing a stateful stage discards its old tail. Rack values and learned CC assignments are saved with the session, while tails, LFO phase, and editor visibility are transient.
Built-in Synth is powered by OxiSynth and the embedded SoundFont. Its track shape is fixed at two dry audio inputs, two wet audio outputs, and one MIDI input; the synth ignores the dry audio samples. Choose one preset in its embedded editor. Preset-authored reverb and chorus sends remain active, while the two send controls add up to the standard CC 91/93 modulation range and can learn any exact source channel/CC pair. Only modulation (CC 1), expression (CC 11), sustain (CC 64), pitch bend, and supported non-CC note/pressure messages reach OxiSynth itself; other CC, bank, and program messages are filtered after MIDI Learn observes them. All accepted source channels feed one logical instrument. The selected preset, sends, and assignments are saved with the session.
Latency compensation¶
ShoopDaLoop keeps live monitoring immediate. Compensation changes which part of a completed recording is used for playback; it does not delay the live input path.
Open a track’s ⋮ menu and choose Latency compensation. The dialog’s Recording alignment section controls one signed effective recording offset:
Automatic uses an exact backend value when one is available.
Manual uses the entered signed frame value.
Automatic + trim adds the entered signed trim to an available automatic value.
JACK is the only automatic provider. ShoopDaLoop accepts a JACK value only when all relevant connected track inputs report the same exact capture latency. CPAL, dummy, Carla, built-in synth, and browser tracks use the manual path rather than an estimate. If an automatic value is unavailable, the menu asks for a manual value instead of assuming zero. Changing an unarmed JACK input route refreshes the automatic value, and loops added later inherit the current track values.
The value is latched when recording, replacement, or rendering starts. Changing the track setting later affects the next operation and never moves an existing take. Once a recording transition is armed, cancel it before changing the track offset or input routes. Replacement and retrospective grab are retained only at zero offset on every affected channel; record a new take when compensation is needed. Stop the loop before correcting a completed take’s signed alignment with its alignment control in the same dialog. The common control applies one delta to every channel so dry/wet differences remain intact. Processed takes also show a processor-alignment correction; it applies one atomic delta to Wet channels only and preserves differences within each channel group. Alignment, start-offset, and length edits must fit the raw media retained with every channel in the take; otherwise they are rejected without changing any channel. This also applies when an import updates a loop’s length while retaining other channels. Waveform and MIDI details show these aligned raw-media coordinates, while timeline edits are translated back to the stored media layout. Successful alignment edits reload these coordinates, and a browser-backend rejection reloads the authoritative timeline instead of leaving the attempted edit displayed.
Positive offsets retain and select post-record media. Negative offsets retain pre-record media. Recording starts only after the required bounded storage has been prepared and the required preroll has actually been captured. Content remains unsettled while required postroll is being captured; save, export, a new recording, playback that would outrun the retained media, and waveform/details reads wait or report that the content is still changing. If storage preparation, preroll capture, or finalization cannot complete, the operation fails without publishing a partially corrected take.
Normal playback, WAV/Shoop audio export, and standard/exact MIDI export use the logical compensated loop window. There is no latency-specific raw-margin export or bake/recovery operation.
Dry/wet operations¶
Processor latency is independent from Recording alignment and has its own Automatic, Manual, and Automatic + trim selector. Its effective value is non-negative. Unsupported detector paths, including Carla, use an automatic baseline of zero; ShoopDaLoop does not inspect Carla plugins or graphs. Enter the known processor delay with Manual, or add it as a positive trim to the zero baseline.
For an ordinary simultaneous dry/wet recording, Direct and Dry channels use the
signed recording offset R while Wet channels use R + P, where P is
the effective processor latency. Storage is prepared separately for those
channel windows, so a take may require dry preroll and wet postroll at the same
time. Live input remains immediate; recording compensation changes retained
media and per-channel annotations rather than delaying monitoring.
While playing dry through wet or recording dry into wet, dry media is dispatched
P frames early so delayed processor output reaches its intended frame.
Recording dry into wet writes canonical wet timing. Normal wet playback and
logical export use each Wet channel’s stored capture alignment and never apply
P a second time.
Pending and error text in the dialog is actionable. For an unavailable recording automatic value, select Manual. For an invalid processor result, enter a non-negative Manual value or reduce the trim. For a retention failure, reduce the offset, processor latency, or recording length and retry. Wait for postroll to finish before saving or exporting.
Carla process isolation¶
Native builds with FX support can run Carla Rack and Patchbay chains in the application process or in one worker process per chain. Select the global mode under Settings → Carla. It takes effect on the next launch and is not stored in sessions.
A subprocess authenticates its control connection and uses bounded shared memory for realtime audio and MIDI blocks. A late or failed worker produces a bounded failure for that wet block instead of delaying the audio callback. Other tracks continue. Recovery starts a new worker generation and restores the last confirmed state and desired active state.
Processed-track controls expose lifecycle and recovery state. Carla Process Logs… shows bounded stdout and stderr records per generation, including any dropped-byte count. Closing a plugin UI or unloading a session is normal shutdown, not a crash.
Release archives include a pinned Carla Native runtime, external UI, and plugin
discovery/bridge helpers. ShoopDaLoop loads this runtime directly rather than
hosting Carla through LV2. Source builds need no Carla SDK; when no runtime is
present the Carla processors are shown as unavailable without affecting External
or Built-in Synth tracks. Developers can use the absolute-path overrides
SHOOP_CARLA_NATIVE_LIBRARY and SHOOP_CARLA_RESOURCE_DIR to select an
exact runtime and --probe-carla-native to validate it. --probe-carla-native-ui additionally
opens, idles, hides, and reopens every external Carla UI before exiting.
MIDI controllers¶
ShoopDaLoop controller integration is script-based. Open Settings → Scripts to enable the bundled APC Mini script or manage other scripts. Scripts are grouped by kind in a table; its icon controls open separate help, log, and status windows showing callbacks, timers, logical MIDI rules, matched and connected endpoints, queue drops, and failures. The table also exports every script’s source and manages session ownership. Incompatible scripts remain visible with their error status so they can be exported and updated, but their start control is disabled.
Native builds discover MIDI through the selected JACK or midir service. Browser builds discover physical endpoints after the independent Enable Web MIDI + SysEx action. Denied or unavailable Web MIDI does not disable audio, keyboard control, or the rest of the application.
Autoconnection¶
A script-created logical MIDI port contains a direction and a full-name regular expression. It connects to every compatible matching endpoint and reconnects after hotplug. An empty expression matches nothing. Output rules can set a positive message rate; zero is unthrottled. Queues are bounded and expose drop counters rather than growing indefinitely.
Custom controllers¶
Controller behavior can use the shoop_control Lua API, callbacks, timers,
and MIDI helpers. Native builds may add user script files. Browser builds use
bundled and session-contained sources and intentionally omit machine file-path
actions. See Lua scripting.
Keyboard control¶
The computer keyboard can control many aspects of ShoopDaLoop. Keyboard behavior is implemented by the bundled Lua script keyboard.lua. Native builds can use a modified copy as a user script; browser builds fetch it from the packaged external built-ins tree or use session-contained sources.
The help text of the default keyboard.lua is shown here for reference. Open Settings and select Scripts to view this help, edit startup enablement, restart the script, and inspect errors or logs. Keyboard presses are ignored while the GUI is accepting text input; key repeats are suppressed, and held sampler keys are released when the window loses focus. Newly discovered scripts are disabled until enabled in the dynamic identity list and saved.
# Keyboard controls
Control ShoopDaLoop directly from the computer keyboard.
## Key bindings
| Key | Action |
| --- | --- |
| **Arrow keys** | Move the selection. With no selection, select the loop at the origin. Hold **Ctrl** to expand the selection instead of moving it. |
| **Escape** | Clear the selection. |
| **Space** | Perform the default action on selected loops, cycling between recording, playing, and stopped. |
| **R** | Record selected loops. With no selection, select all recording loops. |
| **P** | Play selected loops. With no selection, select all playing loops. |
| **S** | Stop selected loops. With no selection, stop all loops. |
| **L** | Play selected loops dry through wet. With no selection, select all loops already playing dry through wet. |
| **M** | Record selected loops dry into wet. With no selection, select all loops already recording dry into wet. |
| **I** | Toggle input mute for tracks containing selected loops. Unmuting respects the global auto-mute-other-inputs control. |
| **N** | **Record next:** queue recording into the first empty loop of the selected or recording track. |
| **G** | **Grab:** retroactively record data from the running buffer. |
| **O** | **Overdub:** queue recording into the first empty loop while currently recording loops play back. |
| **T** | Toggle one selected loop as the target. If several loops are selected, one is chosen. |
| **U** | Untarget all loops. |
| **W** | Record selected loops in sync with targeted loops. |
| **C** | Clear selected loops. |
| **.** | Sampling mode: selected loops record or play immediately until the key is released, without synchronization. |
| **0–9** | Set the number of sync-loop cycles for future actions. **0** makes actions open-ended. Hold digits together to enter larger values, for example **1**, then **2**, for **12**. |
## Synchronization
Loop-transition actions follow the global **synchronization active** state. Toggle it in the UI, or hold **Ctrl** to invert it momentarily.