Guide
When something is silent or blank
An ordered checklist for silent patterns and blank visuals.
When a pattern makes no sound or a visual stays blank, check the layers in order, from the evaluated form outward to the speakers. Each layer can fail independently, so work through the list before restarting the audio server.
- Did the form evaluate successfully and install the intended pattern?
- Does querying that pattern produce the intended events?
- Is the transport running, and is the channel unmuted?
- Is the backend’s receiver running? For the default backend, that is SuperDirt.
- Are the sample banks loaded, and are any optional native plug-ins or models the pattern uses ready?
- Are orbit outputs, mixer levels, DAW monitoring, and hardware output routed correctly?
- For measured visuals, is the intended input or private orbit tap carrying a signal?
For step 2, query the pattern directly without dispatching sound, as shown in First patterns. To check the sound path itself, evaluate a plain sample pattern such as the ones in Play and change a channel.
Token highlights and event visualizations follow the installed pattern, not the audio output. If they move but nothing sounds, keep working through the list.
A scope or spectral visual requires captured audio. Event-linked visuals and measured visuals are independent: either can work while the other does not. A measured view stays blank without a signal; Mora does not substitute an invented waveform.
Private-orbit taps are dry mono windows of that orbit, not the final stereo output. If the analysis integration is unavailable, patterns and visuals that do not use measured audio can still be used, but analysis is not live. See Machine listening.
For stem and sample-library patterns, missing metadata, an empty filtered pool, and a sound bank absent from SuperDirt are different conditions; check each one. A pattern also needs enough eligible variants for each requested type. See Stems and sample libraries.
Some stem behavior is deliberate and can look like a fault:
- The listing changed but the sound did not. After a
loopscall,partsdescribes the requested pool at once. Voices that are already playing keep their previous score until the replacement is prepared. A change that would leave a playing stem type with no eligible source is refused, and the playing selection stays. - A bare
(loops)changed nothing. It reports the current selection and does not reset it. Eachloopscall with selection arguments is a complete query: omitted options return to their defaults, so repeat:group :familyto stay grouped. stemslices do not follow the cycle. Astem’s:puses source timing by default: one cycle of slice notation lasts one source slice, the recording’s effective length divided by:slices. Write:timing :cyclefor ordinary cycle timing.partuses cycle timing by default, and:nand:vprogressions always use ordinary cycles.- Changing
:vplays the same recording.:vselects a recording within a family only after(loops :group :family), and only a family with at least two members has another recording to select. In a one-member family any:vis member 0, and flat mode accepts only:v 0. - A matched stem is refused. Matching needs the live-stretch engine installed and ready. Pitched matching (
:match tor:match :key) also needs an explicit global key and a source with a known tonic. A known conflicting mode is refused, and an explicitloops :modealso excludes pitched sources whose mode is unknown.:match :temponeeds no source key. See Tempo and key matching.
When pairing or a mix request returns nothing useful, check what it depends on:
- Embedding coverage. Ranking uses only prepared embeddings.
(stem-embedding-status)reports embedding coverage for the library and starts no work;embed-stemsprepares missing embeddings. - The measured mix. A mix request, from
suggest-stemsor Shift+Return at astemorpartselector, captures the analysis input. That input must already carry the intended mix: a silent input is not a query, and a request never starts devices, changes routing or starts music. - Stale rankings. Changing the playing mix (channel patterns or mute state), the source pool, tempo or key (or, for editor and Samples requests, the target form) makes a ranking stale. Request again rather than accepting it. In the editor, refusals appear as nonmodal notices beginning with
PHALAR:; the Samples pane reports them in its status line; from Lisp,suggested-stemsignals an error for a stale, pending, failed or cancelled request.
See PHALAR stem pairing.
Use one language interpreter and one audio server. Do not start a duplicate server to fix a missing sample or a stale package.
A refused edit or a failed replacement leaves the previous score playing and reports a nonmodal notice. Correct the form and evaluate it again; an ordinary error does not call for restarting the audio server or resetting audio resources.
Mora rebuilds the retained scores automatically only after a fresh native identity proves that the configured standalone scsynth process was replaced. That proof needs the MoraRuntime identity helper installed where scsynth loads plugins at startup. The helper is separate from the optional stretch engine and owns no audio. The rebuild does not evaluate source again, change the tempo, replay missed cycles or select another device, and new edits and hush take precedence over it.
A timeout, a changed language service or a changed endpoint alone is not proof that the audio server was replaced, so Mora does not rebuild in those cases. A restarted server is silent while it boots and reloads samples; recovery is not uninterrupted failover. Automatic rebuilding does not cover an embedded server, Supernova or non-realtime rendering.
Source references
Repository-relative paths in the Mora source where these mechanisms are implemented.
-
src/backends/superdirt/ -
src/backends/superdirt/audio-recovery.lisp -
native/mora-runtime/ -
src/analysis/ -
src/runtime/orbit-taps.lisp -
src/mini/loop-library.lisp -
src/mini/stem.lisp -
src/mini/stem-context.lisp