Sonic Pi's live_loop runs each named loop as a concurrent thread you can edit while it plays

live_loop :name do ... end is the construct Sam Aaron invented to solve the sequential-loop problem, and it is what most Sonic Pi performance code is made of. Each live_loop is given a unique symbol name and runs its body continuously in its own concurrent thread, so multiple named loops play simultaneously the moment the code is evaluated — concurrency without explicit thread management. Unlike an ordinary infinite loop, which you cannot exit without killing the process, a live_loop is hot-swappable: edit its body and press Run and the system applies the change at the top of that loop’s next iteration, without stopping playback and without affecting the other running loops. Each live_loop must contain at least one sleep call, or Sonic Pi raises a safety error to prevent a CPU lockup. This modify-while-running behaviour is at once a programming abstraction and the core live-performance mechanism.

Examples

live_loop :drums do
  sample :bd_haus
  sleep 0.5
end

live_loop :bass do
  play :e2
  sleep 1
end

Both run concurrently. While running, change :bass to play :e3 (or halve the drum sleep to 0.25) and press Run — the edited loop switches at its next cycle while the other keeps playing.

Assessment

Explain why a live_loop requires a sleep call, and what happens to playback when you redefine one live_loop and press Run — contrasting it with modifying a standard while true loop in Python. Write a two-loop patch (kick + melody) and demonstrate editing one loop without stopping the other.