Music Technology

Sonic Pi Tutorial: Getting Started Live Coding Music

Free, cross-platform, and designed so that your first sound happens about ninety seconds after you open it.

Most music software asks you to learn an interface. Sonic Pi asks you to type a line and press a button, and it makes a noise. It was built by Sam Aaron to teach programming in schools, which is why the on-ramp is gentler than anything else in live coding — and it’s used for actual performances, which is why you don’t outgrow it in a week.

It’s free, runs on macOS, Windows, Linux and Raspberry Pi, and everything you need is in the app.

Your first sound

Open it, type this into a buffer, press Run:

play 60

That’s a note. 60 is MIDI middle C. Now:

play 60
sleep 0.5
play 64
sleep 0.5
play 67

A C major arpeggio. sleep is in beats, not seconds, and it’s the only timing primitive you need at first.

Swap the numbers for note names, which is easier to read:

play :C4
sleep 0.5
play :E4
sleep 0.5
play :G4

live_loop is the actual point

Everything above is a program that runs and stops. Live coding means changing the music while it plays, and in Sonic Pi that’s live_loop:

live_loop :bass do
  use_synth :tb303
  play :E1, release: 0.8, cutoff: 70
  sleep 0.5
end

Press Run. It loops forever. Now — without stopping it — change cutoff: 70 to cutoff: 110 and press Run again. The sound changes on the next cycle. You just performed.

This is the mental shift that makes Sonic Pi click: Run doesn’t restart, it redefines. You are editing a running system.

Multiple loops run concurrently:

live_loop :drums do
  sample :bd_haus
  sleep 1
end

live_loop :hats do
  sample :drum_cymbal_closed, amp: 0.5
  sleep 0.25
end

Sam Aaron, who wrote Sonic Pi, introducing live coding with it.

Keeping things together with sync

Independent loops drift apart the moment their durations don’t divide evenly. sync fixes it — one loop becomes the clock, others wait for its cue:

live_loop :clock do
  sleep 1
end

live_loop :melody, sync: :clock do
  play choose([:C4, :E4, :G4, :B4])
  sleep 0.25
end

:melody now starts on :clock’s beat, every time, no matter when you hit Run. Use this from the beginning. Nearly every “why is my Sonic Pi patch a mess” question is an unsynced loop.

Samples, randomness and FX

# built-in samples — type sample :ambi_ and autocomplete shows you the set
sample :ambi_choir, rate: 0.5

# randomness with a fixed seed, so a good take is reproducible
use_random_seed 42
play choose([60, 62, 64, 67])
play rrand_i(60, 72)

# effects wrap a block
with_fx :reverb, room: 0.8 do
  live_loop :pad do
    use_synth :hollow
    play chord(:E3, :minor7), release: 4
    sleep 4
  end
end

use_random_seed is the underrated one. Sonic Pi’s randomness is deterministic per seed, so a happy accident can be reproduced exactly — which is what makes random material usable in a composition rather than just a jam.

Mistakes that make people think it’s broken

  • Forgetting sleep inside a live_loop. The loop runs infinitely fast, Sonic Pi stops it and complains. Every loop needs a sleep.
  • Expecting Run to restart. It doesn’t, and shouldn’t. Use Stop to actually stop.
  • Naming two live_loops the same thing. The second replaces the first. Usually the bug when a loop mysteriously vanishes.
  • Sleeps that don’t divide evenly, with no sync. Things drift and it sounds sloppy for reasons that aren’t obvious.
  • Reaching for an external DAW too early. Sonic Pi has samples, synths and FX. Learn those first.

Where to go next

The built-in tutorial (Help pane) is genuinely the best resource — it’s Aaron’s own, it’s long, and it’s right there. After that: use_bpm for tempo, ring and .tick for sequencing patterns cleanly, MIDI and OSC out to drive hardware or visuals, and live_audio for processing live input.

The natural pairing is with visual live coding — Hydra or TidalCycles people will be at the same algoraves — and Sonic Pi speaks OSC, so wiring it to a visual system is a genuinely short afternoon.