Define ready
A standalone instrument needs a precise definition of ready. Power is connected, the intended audio interface is active, the correct patch is loaded, the controls have known meanings and the output starts at an appropriate level. If any of these depend on remembering what happened in yesterday’s browser session, the instrument is still partly a development system.
Write a startup card before changing the patch. List the physical connections, the initial sound, the first control you will move and the action that restores a familiar state. Give that initial sound a musical purpose. It might be a quiet drone that confirms the audio path, or a muted instrument waiting for a note. Avoid using an unexpectedly loud test tone as the only evidence that the machine has started.
Save the graph and its starting state
Cycling ’74’s Raspberry Pi web interface distinguishes the audio/MIDI graph from graph presets containing device parameters and buffer mappings. Its guide documents a startup graph selection and an initial preset that loads with a graph. These are useful building blocks for a repeatable instrument, but they need to be configured and checked together.
Create the smallest useful graph: controller to instrument, instrument to a restrained effect, effect to output. Name the devices by role so the route is readable later. Save the graph and its starting parameters. If samples are involved, verify their mappings as well as their filenames. A remembered parameter value cannot compensate for a missing or replaced audio asset.
Now stop using the editor as a performance crutch. Restart through the supported shutdown and startup process, reconnect the controller and verify the intended state. Keep the output level low for this check. Repeat with the browser closed. The browser can be a maintenance interface without being part of the actual playing ritual.
Design variations that keep their identity
Build three states from one instrument: clear, unstable and sparse. Keep at least one invariant across them, such as the main pitch range or the meaning of the first control. This makes a variation feel like a related place within the instrument rather than an unrelated preset. Write the common meanings on the enclosure or a temporary paper panel.
Choose whether a state change is a dramatic cut or a continuous transition. Do not assume preset recall creates a smooth morph. A change to delay time, buffer selection or oscillator structure may have a very different audible consequence from a slow level adjustment. Where continuity matters, design an explicit transition in the patch and test it with sound already playing.
Test a state change while holding a note, while an effect tail remains and immediately after a controller movement. Listen for discontinuities and check whether the next movement jumps to a stored value. Decide what should happen rather than treating every jump as a bug. A hard cut can be musically useful when it is intentional and has an obvious control.
The Pi interface reports approximate CPU load and xruns, which indicate missed audio deadlines. Use those observations during the most demanding musical passage, not only at idle. A quiet drone with one voice may hide the cost of a dense chord and long effect. Leave enough practical margin that your hardest planned gesture remains dependable.
Rehearse recovery as part of the set
A recoverable performance needs an audible fallback as well as saved files. Keep one simple state that you understand completely. If a complex variation behaves unexpectedly, the fallback should let you continue without opening a diagnostic page in front of an audience. It can be musically modest; familiarity is its value.
Document the export revision, runner version, audio settings and connected devices alongside the patch and its assets. A backup should include enough information to reconstruct the working system, not just the source patch. Preserve a known-good card image or installation backup using the platform’s documented method if that fits your setup. Label it clearly so an experiment does not silently become the only surviving copy.
Finally, pack the instrument away and set it up again from the card. That small rehearsal reveals missing cables, ambiguous labels and hidden assumptions more effectively than another hour of patch editing. The object is becoming an instrument when starting it feels like preparing to play, and when its recovery path is as comprehensible as its most adventurous sound.
Try this.
Create three related graph states and a documented initial state. Close the browser, perform a normal shutdown/startup cycle and play a short set from the written startup card. Note every step that still depends on memory.
Listen back
- What exactly tells you the instrument is ready?
- Which controls keep the same meaning across states?
- Can the simplest sound carry the performance during recovery?