One of the most exciting aspects of Sonic Pi is that it enables you to write and modify code live to make music, just like you might perform live with a guitar. One advantage of this approach is to give you more feedback whilst composing (get a simple loop running and keep tweaking it till it sounds just perfect). However, the main advantage is that you can take Sonic Pi on stage and gig with it.

In this section we’ll cover the fundamentals of turning your static code compositions into dynamic performances.

Hold on to your seats…

Now we’ve learned enough to really start having some fun. In this section we’ll draw from all the previous sections and show you how you can start making your music compositions live and turning them into a performance. For that we’ll need 3 main ingredients:

• An ability to write code that makes sounds - CHECK!
• An ability to write functions - CHECK!
• An ability to use (named) threads - CHECK!

Alrighty, let’s get started. Let’s live code our first sounds. We first need a function containing the code we want to play. Let’s start simple. We also want to loop calls to that function in a thread:

If that looks a little too complicated to you, go back and re-read the sections on functions and threads. It’s not too complicated if you’ve already wrapped your head around these things.

What we have here is a function definition which just plays note 50 and sleeps for a beat. We then define a named thread called :looper which just loops around calling my_sound repeatedly.

If you run this code, you’ll hear note 50 repeating again and again…

Changing it up

Now, this is where the fun starts. Whilst the code is still running change 50 to another number, say 55, then press the Run button again. Woah! It changed! Live!

It didn’t add a new layer because we’re using named threads which only allow one thread for each name. Also, the sound changed because we redefined the function. We gave :my_sound a new definition. When the :looper thread looped around it simply called the new definition.

Try changing it again, change the note, change the sleep time. How about adding a use_synth statement? For example, change it to:

Now it sounds pretty interesting, but we can spice it up further. Instead of playing the same note again and again, try playing a chord:

How about playing random notes from the chord:

Or using a random cutoff value:

Finally, add some drums:

Now things are getting exciting!

However, before you jump up and start live coding with functions and threads, stop what you’re doing and read the next section on live_loop which will change the way you code in Sonic Pi forever…

Ok, so this section of the tutorial is the real gem. If you only read one section, it should be this one. If you read the previous section on Live Coding Fundamentals, live_loop is a simple way of doing exactly that but without having to write so much.

If you didn’t read the previous section, live_loop is the best way to jam with Sonic Pi.

Let’s play. Write the following in a new buffer:

Now press the Run button. You hear a basic beep every beat. Nothing fun there. However, don’t press Stop just yet. Change the 60 to 65 and press Run again.

Woah! It changed automatically without missing a beat. This is live coding.

Why not change it to be more bass like? Just update your code whilst it’s playing:

Then hit Run.

Let’s make the cutoff move around:

Hit Run again.

Add some drums:

Change the note from e1 to c1:

Now stop listening to me and play around yourself! Have fun!

Consider the following live loop:

You may have wondered why it needs the name :foo. This name is important because it signifies that this live loop is different from all other live loops.

There can never be two live loops running with the same name.

This means that if we want multiple concurrently running live loops, we just need to give them different names:

You can now update and change each live loop independently and it all just works.

Syncing Live Loops

One thing you might have already noticed is that live loops work automatically with the thread cue mechanism we explored previously. Every time the live loop loops, it generates a new cue event with the name of the live loop. We can therefore sync on these cues to ensure our loops are in sync without having to stop anything.

Consider this badly synced code:

Let’s see if we can fix the timing and sync without stopping it. First, let’s fix the :foo loop to make the sleep a factor of 1 - something like 0.5 will do:

We’re not quite finished yet though - you’ll notice that the beats don’t quite line up correctly. This is because the loops are out of phase. Let’s fix that by syncing one to the other:

Wow, everything is now perfectly in time - all without stopping.

Now, go forth and live code with live loops!

Something you’ll likely find yourself doing a lot when live coding is looping through rings. You’ll be putting notes into rings for melodies, sleeps for rhythms, chord progressions, timbral variations, etc. etc.

Ticking Rings

Sonic Pi provides a very handy tool for working with rings within live_loops. It’s called the tick system. In the section about the rings we were talking about the counter that is constantly increasing, like a current beat number. Tick just implements this idea. It provides you with the ability to tick through rings. Let’s look at an example:

This is equivalent to:

Here, we’re just grabbing the scale E3 minor pentatonic and ticking through each element. This is done by adding .tick to the end of the scale declaration. This tick is local to the live loop, so each live loop can have its own independent tick:

Tick

You can also call tick as a standard fn and use the value as an index:

However, it is much nicer to call .tick at the end. The tick fn is for when you want to do fancy things with the tick value and for when you want to use ticks for other things than indexing into rings.

Look

The magical thing about tick is that not only does it return a new index (or the value of the ring at that index) it also makes sure that next time you call tick, it’s the next value. Take a look at the examples in the docs for tick for many ways of working with this. However, for now, it’s important to point out that sometimes you’ll want to just look at the current tick value and not increase it. This is available via the look fn. You can call look as a standard fn or by adding .look to the end of a ring.

Naming Ticks

Finally, sometimes you’ll need more than one tick per live loop. This is achieved by giving your tick a name:

Here we’re using two ticks one for the note to play and another for the sleep time. As they’re both in the same live loop, to keep them separate we need to give them unique names. This is exactly the same kind of thing as naming live_loops - we just pass a symbol prefixed with a :. In the example above we called one tick :foo and the other :bar. If we want to look at these we also need to pass the name of the tick to look.

Don't make it too complicated

Most of the power in the tick system isn’t useful when you get started. Don’t try and learn everything in this section. Just focus on ticking through a single ring. That’ll give you most of the joy and simplicity of ticking through rings in your live_loops.

Take a look at the documentation for tick where there are many useful examples and happy ticking!