02:41 - Sam Aaron Introduction and Background

10:53 - Sonic Pi Defined

13:10 - Live Performance Aspect

23:58 - The Learning Curve

28:06 - Teaching Kids to Program Through Music

34:07 - Sonic Pi in the Classroom

36:22 - Threading

41:18 - Choosing Ruby Over Clojure for Sonic Pi

44:13 - Sonic Pi Roadmap: What’s Next?

49:22 - Contribute to the sonic-pi Repo!

50:43 - Heritage?

53:53 - Experimenting with Music, The Evolution of Dance Music

56:19 - Types of Sounds

Picks

Cate Huston: 5 Strategies For Making Progress on Side Projects (Coraline)
TIS-100 (Coraline)
Building Microservices by Sam Newman (David)
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (David)
[YouTube] Ben Eggett: Writing Music with Ruby: A Subtle Introduction to Music Theory @ MountainWest RubyConf 2015 (Chuck)
Elixir (Chuck)
Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas (Chuck)
Wabi-Sabi for Artists, Designers, Poets & Philosophers by Leonard Koren (Sam)
The Joy of Clojure by Michael Fogus (Sam)
Raspberry Pi (Sam)

Special Guest: Sam Aaron.

Mandy, please don't use any of that. [Laughter]

I'm shaking my head so much right now.

Yeah.

Hey everybody and welcome to episode 215 of the Ruby Rogues Podcast. This week on our panel, we have Coraline Ada Ehmke.

Hello.

Saron Yitbarek.

Hey, everybody.

David Brady.

Hello and welcome to Ruby Rogues. [Speaking in Spanish]

I'm Charles Max Wood from DevChat.TV. And this week we have a special guest. That's Sam Aaron.

Hi there.

Do you want to introduce yourself real quick?

Sure. Hi, I'm Sam Aaron. Is that it? Do you want more?

Sure.

I love it. [Laughter]

You said real quick, right? So no, I'm a programmer. I'm a researcher. And my main interest is live coding. So, how do we write code that we can change whilst it's still running? And what can we do with that? So, I'm particularly interested in using it to make music. So, can I go on stage, live code a piece of music for an entire set, and get people dancing as what I try and do, without it breaking and stopping or knackering up? And all the time focusing on coding as performance and finding ways to express myself through code live.

If only this interview format allowed for you to somehow express that directly.

[Laughs] Yeah, it'd be nice.

Seriously, we need a live coding session during this podcast. I'm calling it.

I second it.

I'm already dancing. [Laughter]

We're halfway there.

Yeah, yeah. Can you read Ruby codes? I think.

Uuh…

Because yeah, so all you need to do is understand, be able to read the syntax of Ruby and then have a deep understanding of the semantics in my system in terms of how it works through time. And then I could actually just read the words out and you could have the music in your heads. That would be beautiful.

That would work fine for me. But for our listeners, I think…

At some point, we should have you unplug your headphones and just rock out.

Get the feedback going.

Yeah.

[Chuckles] I'm not sure. We can give it a try. I'm not sure. We'll see.

Oh, and it would totally be techno dubstep because one of us could say, “Now could you try,” and it would loop, right? “Now could you try? Now could you try?”

Yeah, yeah.

“Now could you try.”

But it depends on where the audio would just knacker up in terms of feedback.

Yeah, yeah.

We can give it a try.

The system is down.

That's totally what I was thinking.

So Sam, what got you started on this path?

That's a good question. I was doing a PhD in Computer Science and I was really finding it very boring.

You used to have?

When I was doing one.

Did they take it back?

[Chuckles] I've still got it.

Look at it. It's in my back pocket right now.

Okay.

When I was doing it, I was really bored. And then I discovered Ruby. And because it had this REPL thing that allowed IRB interaction, prompt, it allowed me to really ask questions on the system live. And that really changed my mind about what programming could be. Of course, this REPL in Ruby is nothing new. We've had it in Lisp for many decades. But for me, it was brand new. And so, that then opened my mind up to the ability to have a conversation with the computer and what we could do with that. And that, combined with an exploration of DSLs, how do we take a language and manipulate it and morph it into another language that can express some properties really nicely, and express those in worse ways.

But for an advantage in say business, I want to express my products in my catalog. Isn't it nice to be able to express in a language that the client can read to verify? And so, those two things are pursued. But really, the whole time… like in my past I used to play clarinet in the jazz band. And if anyone's every played in a band in school or out of school, it's one of those experiences that's really hard to replicate in any other way. It's something about the synchronization of playing with somebody else and feeling together. Like looking into someone's eyes as you're playing music and you're feeling this unification that's really hard to get in other ways. And so, I was really trying to capture that as well.

So, rather than trying to figure out how to… well, basically I couldn't be bothered to learn to play a musical instrument properly because it took a lot of practice. And I didn't really like the sound of the clarinet or the violin or the piano. They're okay. I really like listening to crazy electronic music. So, I was thinking, “How do I get the same kind of level of virtuosity, the same level of synchronicity with people, with electronic music as my instrument using code?” And so, I started this path of building systems, multiple different systems, and working with other people building systems to get where I am now.

That's an amazing thing that you put that way, because I've not done any band work or played instruments. But as a video game enthusiast…

Yeah, yes.

There was a game that came out for the Nintendo years ago called Donkey Konga. And you just got conga drums. And you could have up to four people playing drums. And the feedback on the game is when you look at it in the store, you're going to think this is the stupidest thing you have ever seen.

When you get four people playing together, something happens that is beyond the game and it will blow your freaking mind.

Absolutely. It's cool people just sharing things together, you know?

Yeah.

The collaboration is beautiful.

So, do I need to be installing Sonic Pi so that we can jam with two seconds of lag between us?

So, network support is in progress. I haven't completed that yet. But you certainly can the moment, if you know what you're doing and you poke around the system a bit, you can use one computer as a main hub, main server, and have other people connect into it with clients. It's all network protocol. So, all the different parts of the system are talking to each other via network protocols. So, you could easily replace one with another one and have it in another part of the country or the world.

And so, one of my bands I will play in, we do exactly that. We have two people, two laptops, but one laptop's connected to the main speakers and the other person's laptop is just sending messages over the network of what to do musically. And that way, it's really easy to synchronize across the two individuals. Because the system I've written is deeply threaded. And you want to be able to synchronize information across threads to be able to say which rhythm we're in, which key we're in, what [inaudible] am I using?

Wow.

Whatever you really want to be able to share. And so, sharing those things in a shared memory system is much, much easier than trying to do some distributed CDT style or CODT style thing where you're into distributed systems at that point.

I did a demo for a lightning talk at work, oh gosh, 10 years ago using Ruby MIDI. But the lightning talk wasn't about using MIDI from Ruby. The lightning talk was about using a queue to distribute work. And so, I had everybody sign in as workers and load up the Ruby MIDI library. And I doled out a song one note at a time. And the notes came from different places all around the table.

Nice.

And now I kind of want to do that…

How did you manage time?

I had the master server just hold back the next job, until…

Oh so basically, you synchronize the time. They set the jobs. But did you know that note E was going to be at time, whatever T, and node F was going to be at time T delta?

Yeah. Yeah, exactly. Yeah, the master thing had its entire thing. And to demonstrate the distributed nature of multiple workers, single provider, we then played the same song without any notion of time. And it was just this [makes gong sound]

Exactly, yeah.

All the notes being played at once. Now I want to do a talk at a conference where I draw a map of the audience and have everybody sign in and click where they are so that you could do… And you know what? We should interview you instead of me riffing on things I want to do with Sonic Pi. [Laughter]

Super interesting. Yeah, yeah. When you start talking about creativity and music and code, everyone's interested. And everyone has something to say, and that's beautiful. And one of the things I try and do all the time, and I do a lot, and this morning I was speaking to 200 kids in a big massive airport hangar with old school military planes. It was nuts. And they're interested as soon as I say music. If I say programming, they're not interested, really. There's a few. The people like us who would typically be interested in programming anyway, their ears prick up. But if I say music, and specifically if I make some music, it gets everyone interested. And so, I think that creative coding is a way to get everyone to pay attention and everyone to get involved and excited. And so, it's no surprise you're wanting to talk about cool things you do at conferences.

Yeah.

I'm curious. Have we talked about what Sonic Pi actually is?

No. [Laughter]

No, do you want to know?

Yeah, let's go there.

Tell us about Sonic Pi, Sam.

So, in a nutshell, Sonic Pi is, the elevator pitch is it's a way to give everybody, not just kids or adults, a creative experience with code and lower the barrier to entry. And specifically with Sonic Pi, the domain of that creativity is music. So, you can write a very, very simple… so basically, it's a Ruby DSL for multi-threaded, very strongly-timed, massively polyphonic, really interesting synthesized, sampled effected sounds.

So, you can really do amazingly expressive things with a very simple DSL in Ruby that 10-year-old kids can also do. I've been to schools where they've got orchestras where these kids are writing multi-threaded code to make music. And they're 10-years-old. And part of this idea about lowering the barrier to entry for a creative experience is about making the system simple. So, the Ruby DSL is part of that. Another part is making it affordable. And so, the software is totally open source and free. So, that's pretty affordable. And then the other part is making the hardware you need to run this kind of system also affordable. And so, I've specifically engineered Sonic Pi to run on a Raspberry Pi computer, which is just $30.

So, if you don't have access to a computer at home, you can get one of these guys, plug it into your television, get a keyboard, a mouse, USB, and then you're away. You can make some music. Of course, if you already have a computer, just use that. It runs on Windows and Macs and on Raspberry Pi computers. And so, it also comes with an editor so you don't have to install TextMate or whatever it is people are using these days. I'm an Emacs guy. So, you don't need to have Emacs connected to a server and all sorts of nonsense. You just download the app. It opens you up in a text window. You write some code. You press the run button and it makes a sound. And then you can go from doing very simple little melodies into complete live-coded DJ sets.

So, like on Friday last week, I was in Glasgow headlining an algorave with Sonic Pi, which is a full night club, getting everyone to dance.

That is amazing.

That's awesome.

So, this whole time I've been trying to think of where I heard of Sonic Pi and it finally hit me. It was demoed as a lightning talk at Bath Ruby a couple of months ago.

Yeah, Xav, Xav Riley. [Inaudible]

Yeah. It was really, really cool. And I want to talk a little bit about the live performance aspect, which when you talk about it sounds really awesome but in reality I think is one of the most terrifying ideas I've ever heard.

[Laughs] It is, yeah.

Because you're live coding, right? Which is already anxiety-driven. And as an audience member, I'm very nervous for you. And then on top of that, not only does the code need to work but the music needs to be good and entertaining.

Yeah, yeah, yeah.

And to some degree, I'm imagining there is some feedback that you have to do with the audience and trying to see if, are they dancing? Are they responding? Do they hate this style of music that I chose? There's that.

Yeah, absolutely.

And there seems to be just a lot of responsibility on the performer's side. How do you do that? How do you deal with all of those things that you have to get right to make it work?

Yeah, that's a bunch of hard questions you just asked. I guess the main thing, the most important thing for me is the motivation for all of that, because you basically described a bunch of hard work. And sometimes I ask this question like, why am I doing this to myself? Before a gig…

[Chuckles] I ask myself that all the time.

I'm super nervous, anxious, and I want to run away. And it's the worst thing I could remember since doing exams at school. And so, why the hell am I doing this? But when I'm on stage and it's going well and I feel like I'm expressing myself, the speakers in the night club are me talking, singing, dancing. And that feeling is just irreplaceable. And so, that's the motivation. And then to get there, to get to that position where I feel that this is me making these people dance, this is my sound, it's not just I'm playing a track of a cool DJ that I like and I'm mixing it together, another cool track. These sounds are coming from me. I designed the synths for example. I chose the sample. And I've mixed them together and have added effects in certain ways to make it my sound. But to get there, there's only really one answer. And that's practice.

And so, what I tend to do is I tend… obviously I built the system so I really understand it inside out. But what I tend to do is I write some code in Sonic Pi. And before I press the play button, I look at it. And I imagine what it's going to sound like. And usually, I'm completely off, especially when I'm early, when I'm [inaudible]. A year ago, I'll be way off. And then I'll press the play button, hear the sound, and go, “Crikey, that's completely different from expected,” and stop it. And then I'll sit and just think about why it was different. Really painful and laborious and awful process. But doing this enough would allow me to actually… because what would tend to happen is that the differences between what's expected and what I heard were two kinds of differences, both kinds of bugs.

One would be a bug in Sonic Pi. This timing's off, or I've introduced this thing and so the thread's not doing this, or all this kinds of bugs. And so, I'm always looking for those and trying to fix those. And the other one is a bug in my understanding of the musical semantics of the language. And those are the bugs I really want to fix, because it means then, the deal then is once I've got a state where I can fairly reliably imagine what it's going to sound like, then I can reverse the process. I can be hearing music and then I can then imagine where I'd like music to go, and then know what code to write to get there. And then that's the form of expression.

And then I guess the thing which drives all that, so there's the motivation, there's the process, but the thing which hooks you really is that you don't write code, press play, stop, write more code, press play, stop. Because that's composition. That's an iterative standard programming practice. That's like writing some code, running the unit tests, you know? Then changing the code, running unit tests again, changing the tests written in the code. That's a normal development practice.

But with Sonic Pi you enter this new kind of practice, this live coding where you can set up a bunch of live loops I call them, get them going. They're threaded. They're running independently. And then sort of stopping it. You can imagine. You can change the code whilst it's still running and then imagine what it's going to change to and then press play. And then it just hot swaps it live whilst it's still going. So, you've got this. You're in the music. It's going. It's much more extended than you'd normally want it to be. So, looping more than you expect, because you're imagining what it's going to sound like. You're spending time to consider. But you're in this place where you really can just let yourself go wild and just keep changing and keep modifying and hearing it.

And I tend to start a practice session with a very process-driven approach. But then within five minutes I've ignored that and I'm making music and jamming and having fun. [Laughs] So yeah, the live loop, the liveness, this process of trying to understand what's going on so I can really feel like I understand what a certain piece of code is going to sound like, plus this motivation of wanting to be in a night club or a big venue and have the speakers be the same as my vocal chords. [Does that make sense?]

Yeah, that makes a lot of sense.

Yeah. What's the worst experience you ever had while live coding on stage?

Ooh, good one.

Yeah. So, I guess I was… I'm here at University of Cambridge and I was here for a year. And after my first year and they invited me to give a talk. So, quite fancy slot. It was Wednesday afternoon slot. And basically to tell the rest of the labs and all these esteemed researchers and fellows and people what I was doing, basically. At that point I wasn't working on Sonic Pi. I was working on some other system called Overtone, which is the big grandfather of Sonic Pi. And so, I was going to do some live coding on this Overtone system and had it all set up. But of course as my usual self, I'm always developing the system all the time. And so, when I arrived at this lecture theater and people start milling in. And I've got seven minutes to actually start talking and do this live demo, I boot up Overtone and connect Emacs to it, do [inaudible] are going to do. And then I realize it's not working because I've introduced a bug.

And so then, and I think… I was right. Because also I think I've built something I wanted to demo as well. So, I couldn't just do a Git reset or something. And so, I actually live fixed the program whilst people were coming in. And I don't think they had an understanding of what I was doing. It was like, Sam's just writing some crazy text. But I was sitting there thinking, “If I can't pull this off [laughs] this is going to be a complete shit show. I need to really [laughs] I need to make sure this works.” And at about one minute to spare, like James Bond style, I managed to pull it off. And so, it's about keeping your cool I guess, to solve these kinds of things, and to really focus.

But yeah, being aware that things are really just going to blow up and break is important. But when we're performing live in front of people, I think audiences actually, they want risk. They want it to potentially go wrong. They don't want it to all sound completely perfect. They want to feel like there's some humanity that's performing, not just some robot which is playing something back precisely. I think it's important to first start to, when we hear electronic music especially live-coded electronic music, that we expect it to go wrong as an audience. And I think that if we do that, I think the exciting thing then is that we get an exception or it blows up or it makes a horrible sound, that it shouldn't be a problem. But what should happen is the audience goes “Haha! What's the live coder going to do about that?” How are they going to react to that mistake? So, expecting mistakes.

Yeah.

But judging the live coder on what they do about it, how they manipulate it, how they incorporate it into their set, how they react to it. That's the exciting tension, brilliant thing that can happen when you've got risk in a real live situation.

I don't know how DJs deal with it. Because the expectations of an actual DJ might be higher. But if you're at a programming conference and you make the thing make any noise at all, people just lose their minds. [Laughter]

Yeah, yeah, yeah, yeah.

Very true.

Well, you have no idea what I can do with the system [next]. [Laughs] It's amazing the things you can do with Sonic Pi today. And it's evolving every day.

I totally want to jam with you at some point. I downloaded Sonic Pi at the top of this call when we were chitchatting, before we actually started. And I’m running the sample. I'm going to unplug my headphones.

Is that coming through?

Yeah.

I can hear. Yeah, nice.

Yeah. So, I’m just going to do the whole show with this bass line going.

I love you guys, but my ADD demands that I rock out while we do this show.

So, the thing is you can actually change that whilst it's playing. That's the nice thing.

Yes.

So, so whilst it's playing… are you doing a loop or are you doing a live loop?

I'm doing the live loop [inaudible]…

Yeah, yeah.

[Inaudible] one, yep.

Yeah, exactly. So, you can change it. You can add a comma, cutoff, colon 70 to add a cutoff filter. You could change the rate of the bass drum by comma, rate, colon, 0.5, and you'll stretch out the bass drum. You could add an effect around that. You can say with effects reverb do and then you put the bass drum line end. Obviously with Ruby every do you need an end. It's what the kids learn these days. And you've got a reverb around that bass drum.

Yeah.

So, the effects of Sonic Pi are wicked because they surround the lexical codebase of what you'd like the effect to have. So, where you say reverb and you say do, every code in that block, that anonymous function, is going to be executed with that reverb. And even if that code in that block spawns threads, those threads also, the code that they produce will also be passed through the same reverb as well. And the reverb will also wait. And so, there's GC on the effects as well. So, the GC waits for the lexical block to complete. But it also waits for all the threads and the threads they can create and the threads they create to complete as well before it kills a reverb. So, there's really some cool computer science in Sonic Pi to make all this stuff happen whilst still being super simple to write .

You know what's going to happen now, right? David's not going to say anything the rest of the show. And then when he comes back for his picks… [Laughter]

Well, he's going to have this full rave going.

Well Dave, can you go to the examples and cut and paste the Tilburg example. In 2.5, that's the best example of [inaudible]. And just give us a go of that.

I don't have a 2.5. I only go to 2.4.

Whoa.

And then it goes to section 3.

No, no, no, no. You want version 2.5 Sonic Pi. Sorry.

Oh.

Sorry. Yeah, yeah. And if you were in the… when you open Sonic Pi, you've got these tabs at the top right. And you've got a doc tab, a help tab sorry, and you click that, this doc pane appears. Part of the doc is a tutorial. Part of the doc is examples. And there are little tabs in the bottom left.

I think there's… Oh, oh, oh, oh, I see. Okay, which example?

Tilburg. It's right at the bottom. This is a cool thing, right? So, I’m giving you some words and you're going to make some music in a moment. And it's just going to work. And we're waiting.

Yeah, while you wait, this is interesting.

Because I've been wondering what the learning curve is for this. David you know is a pretty good programmer, I think we can agree. And Sam, you wrote this so you're obviously very familiar with all that it can do. But how have you seen children or people without such a great programming background, how have you seen them interact with this and level up to the point where they can make great live music?

It's blown my mind, to be honest. I went up to a primary school in New Castle in England a few weeks ago. And they were already using threads and loops to create repeating patterns and making music. They were jamming along and changing on the fly. And it wasn't the best music I've ever heard in terms of sophisticated music. But in terms of computer programs, people think that threads is something you teach at university level, not to 10-year-olds. And these kids were just absolutely fine. People don't think that code is creative. They think it's a business, right? Complete nutcases, thinking it's just for business. Code is so much more than…

Yeah.

Writing a blooming business app. in the same way that reading and writing is so much more than writing to-do lists or CVs or contracts. I ask kids today, why do you need to learn to read or write? And they were saying, “To express ourselves.” They were saying, “To be able to remember things and recall things.” And one girl said, so she didn't actually answer the question but she said, “If someone could read or write then it's their duty to help others who can't.” That's amazing. And it's the same with programming. [Music plays]

There we are. Tilburg.

So, I've got the volume turned back a little bit so that you guys can just keep talking.

I like it.

Yeah. So, the cool thing with this, this track uses randomization. But randomization is deterministic. So, that melody is a grand [inaudible] of 16 notes in pentatonic scale. And I've always [inaudible]. [Music stops]

There we are.

Yeah, we're getting echo unfortunately.

[Laughs] Well, people can play it at home. What I was trying to say is that that piece of music is expressed in a very simple way. You've got a bunch of live loops. One just playing the bass drum, one playing that za-wa sound, that wa-wa-wa. And that's like three lines of code. And I guess the main part which is that melody you're hearing is really nice. What I’m doing, you've got a loop, live loop, and it's saying… I’m recalling this from memory so correct me if I’m wrong. It's saying, “I want a bunch of notes. And those notes are the scale, like E3 minor pentatonic.”

And so, that just gives me, 2.6 that’s going to be an immutable vector of notes. Not a stupid musical array that Ruby normally has by default, but a nice immutable data structure that I can share across the threads and it doesn't change. And then once I've got that list, what I can do then is I can say, well just give me 16 notes just randomly. And if I like them, I can use those as my melody. And if I don't, just give me a different 16. And so, I've looped that around giving different 16 until I found a 16 liked. And then I've seeded it so that every time it repeats around, it's going to give me the same 16 notes. This is why you're hearing that melody go round and round.

Nice.

So, a fun thing to do is to comment out that use random seed line. And then you'll hear the randomization just fly off into the ether. And it won't repeat. It'll just keep doing random stuff. So, from a performance perspective, we have this way to introduce repeatability which has this musical property. But we also have the ability to set things free and bring them back and change them. And when you go to kids and you say, “Can you create me a melody?” that's where you've got a hard proposition.

But if you say, “I can teach you how to generate 16 random notes from a set of notes. All you need to do is just to say if you like them or not. And if you don't, just choose another 16. If you don't, just choose another 16. Until you do like a set of 16, or 8, or 9, or whatever number you want.” That's your melody. And so, using randomization as a compositional technique is really, really powerful. It's also great at teaching iteration, teaching randomization, deterministic behavior, all these nice computer science concepts.

I saw Joseph Wilk from SoundCloud speak at RubyConf Australia. And he was actually demonstrating Sonic Pi. I believe that's what he was using for his setup. And he talked a lot about teaching kids to program through music and how music is just something that kids intuitively grasp. And they pick up the programming concepts that they need through the process of trying to create something that's in their heads. Would you agree with that?

It's absolutely right. So, you've mentioned both Xav and Joseph. They're both on the core team of Sonic Pi. Really cool guys, talk to them all the time. Yeah, and Joseph's absolutely right. So, when I first created Sonic Pi, I'd already built this Overtone system which is the most powerful system I

could imagine. So, this is a really cool Clojure environment which I had a band called Meta-eX and we toured the world doing live coding. And it was a whole hoot. And so, there was an opportunity. The Raspberry Pi Foundation had a bit of money to pay someone for a little small guerrilla project to build something which could potentially engage kids in programming. And then, [inaudible] made some connections and said, well Sam might be a good person to do this because he's got a musical background with code.

And so, they said, “Do you think that you can build something that could run on the Raspberry Pi that could do something like your Overtone system?” It's not my system. It's Jeff Rose's, the guy who actually originally wrote it. And I was just maintainer at that point. And so, I said yes. So, I built a really simple DSL in Ruby that ran on the Raspberry Pi. And then it went into schools. And all it did was play 15 and go beep and you sleep for a second and then play 17 and go boop. Well actually, 17's higher than 15 so it'll be boop. And off you go. They make these melodies. And then you'd introduce iteration or whatever. And so, the first couple of lessons were great. And then, because in the UK we have this new computing curriculum that's just come in. So, we're teaching computing to kids of all ages as a fundamental science.

And so, this new curriculum had come out. And so, we're thinking, well we need to make sure that what we teach maps onto the curriculum so the teachers are happy and the examiners are happy and everyone's happy. So, in that curriculum there are things like functions and variables and yadda-yadda, stuff. And so, we're like, “Okay, we need to start teaching these curriculum things.” So, we did a lesson on, so I was also, skipping a whole bunch of details, but I developed a system myself. But I worked very closely with a teacher, a lovely lady called Carrie Anne Philbin who now currently works for the Raspberry Pi Foundation. But at the time she was a teacher in a school teaching computing. And so, I would go and I would take the latest prototype of Sonic Pi into the school and say, “You think we can use this to teach such and such a thing on the curriculum?” She's, “Yeah, yeah. Let's give it a go.”

And so, we'd sit there. We'd jam out a lesson in the morning, over about an hour and a couple of teas. And then we'd go and deliver the lesson. And so, she would deliver the lesson and I would sit and watch all the kids interacting with the computer. And then use that feedback to modify the system for next week. And then we'd teach a new concept. So, the first few lessons went really well. And then we said, “We need to teach some computer science.” So, we organized a lesson on functions and variables, because obviously they're pretty useful things. It was just a complete horror show.

The kids didn't really get it. They were interested. They were creating variables called justin_beiber equals five. Like, why are we creating variables? And so, it really dawned on me that teaching straight up computer science like that is a really… well, I can't imagine doing it in a really effective way. And it was a really depressing day, that day. We thought, “Well okay, we've been doing so well these first few lessons. We really engaged kids. And now, when we get to the meat of things, it's just all falling apart.” And this music thing just seems like a thin veneer. Initially it's got them hooked. But it's just not delivering on teaching the core computer science.

And so, we put our heads to our hands at that point. And we didn't know what to do next. So then, I say, “Well, why don't we teach…” or maybe Carrie Anne said, I can't remember. We were working together so closely. “Why don't we teach riffs, bass riffs? Let's teach them how to make a bass riff.” And then once you started to say, “Let's do a bass riff today,” they're, “Oh, okay. This bass riff's pretty cool.” And then you say, “Well, what do you need for a bass riff?” Well, we need notes. Well, what are notes? What we've [been using] is numbers, right? And what is a bass riff? It's a lot of notes. Well, are they ordered? Are they unordered? Well, they're ordered. What do we need for an ordered set of numbers? Well, we need a list. So suddenly, we have all these computer science concepts come in to deliver something interesting. Oh, once you've got a list of numbers, how do we play them? Well, we need iteration.

So, it dawned on me that the music thing actually did work well, but not as background to computer science but as foreground. And the computer science being the background, even in a computer science lesson. That way, the kids do things they care about but the computer science is like Trojan horse slipped in without them worrying about too much. The computer science is the tools for them to help themselves, which is why functions or variables are terrible things to teach I think initially. Mainly variables, they suck completely badly in all cases of programming, to be honest. But this is my personal opinion. I'm much more of a variable-free person.

But the main problem is that these are tools for managing complexity and tools for managing system which change through time, which are very sophisticated concepts to complete beginner programmers. You do not need functions if you're writing a piece of code just 10 lines long. You just don't need it. So, you only need a function if you're writing something that's doing the same thing but slightly different, or you're using a function if you're using a bit of code that you're going to repeat a hundred times. Or you're going to use it in various parts of your program and you want to make sure you've only got one place for that function. So, if you change it, it changes it everywhere, right? Rather than cutting and pasting it.

But when you start off coding, I think cutting and pasting is totally fine, because I think it's about expressing yourself. It's about having fun. And it's about writing something interesting. And then when you've cut and pasted too much and it becomes annoying, “Now, I've got to change all these numbers,” suddenly these tools like variables and functions and iteration become really useful. And at that point, I think the kids are interested in using them, because they see the value. But if you start with those concepts like, “Today we're going to do iteration,” it's not interesting for the kids at all. Does that make sense?

Yeah. I want to jump in here.

Absolutely. That's fascinating.

So, I have a bunch of kids over at a charter school that they attend and we're out for summer break now but we'll be back in a few months. And I think this would be really fun to go through with them. Is the curriculum that you're talking about the tutorial that's here? Or…

Well no, that's just for you guys, right? So, when you open Sonic Pi you have a tutorial. It's 30,000 words. But it's written for people who don't know how to code and who don't know about music. So, if you know either of those things or both then you're going to shoot through. But if you don't, they're for you. But we also have supporting material for teachers on the Raspberry Pi website. And also supporting… that's for computer science. But we also have supporting material for musical teachers, which is on another website which I can link to. So, they're specific schemes of work for teachers. So, that's separate from the tutorial built into the app. And that will link to the curriculum stuff. So, that's there for you as well.

I'm just super excited to go through this. My kids are all very musically inclined much more than I am. And so, I think this would be something that they'd really enjoy.

Yeah. But the thing is, I’m going to call you out on that one. I hear so many times parents say, “This is going to be great for my kids.” And I think it's great if you get involved, too. I think parents really…

Oh, yeah.

Should be playing with this stuff. I'm not saying you specifically wouldn’t do that. But I do hear of so many parents who just push this stuff onto the kids. And really, the fun happens when everyone gets involved. And you have a whole family jam session. Or, you have… you could take it in. So, one cool thing to do is a live code battle where you'll set up a live loop like that bass drum you had earlier. And you just get that going and then you take turns to modify it and see if you could outmaneuver the other person. So, you add a few lines here and then, “Whoa, that's going to do something interesting.”

So then you think… It's a bit like, do you ever watch that Layer Tennis stuff? Where it was Photoshop people sending layers of Photoshop to each other to see if they can out-maneuver the previous layer. So, you'd add these layers on top. And there was commentary that went on alongside. So, it's a bit like Layer Tennis but for live coding. So, you could totally do that as a family act. So, see if you can out-maneuver each other.

I can just see my kids, “Dad, that sounds terrible.” [Laughter]

Yeah, yeah, yeah. Then you say, “Well, how do you improve it?” right? Challenge them.

Yeah.

So Aaron, a lot of people complain about threading in Ruby but it's obviously pretty essential to what you're doing with the Sonic Pi. What lessons have you learned about threading that you could share?

Yeah, can you give me an example of some of the complaints that you typically hear?

It's hard. [Laughter]

Yeah. Like, Ruby, it's crappy in a sense. You get all the problems with threading but none of the benefits. It's not actually [multi-call]. That's on [inaudible]. But I actually use, I prefer the threading. I actually really take advantage of the fact that you can safely kill a thread, because it's greenthreaded. And there's no operating system stuff that's potentially dangling and doing weird things. So, when you press the stop button in Sonic Pi, it does kill all the threads.

But I've written my own threading model on top of Ruby's threads which have specific semantics to work with a live-coding situation, particularly my threads store parent-child relationships. So, I know which threads belong to a particular piece of music that's being played right now. So, if I stop that, I

can stop its children independently from another piece of music's children, for example. So, I can control hierarchies, bits of Erlang style. But threading is easy. What's hard is coordinating state across threads. That's the hard bit. Threading is super easy. I could just spawn a bunch of stuff and just say, “Go at it.” If they're all independently executing doing orthogonally distinct tasks, that's great. Everyone could do that already. I have 10 apps running on my Mac right now. That's multithreading. People can do that now. What's hard is when I want to actually coordinate these things such that they work together collaboratively or they don't disrupt each other's work or they don't pull the carpet underneath each other's feet.

And so, those kinds of problems are, there's lots of really interesting solutions to them. The language that I enjoy most programming isn't Ruby. It's Clojure. And Clojure has amazing tools to manage complexity caused by concurrent programming. And the main key strategy really is to not actually have mutable state, to not have variables that can change. And so, by reducing the number of variables you have, I eliminated them, making all the data structures you use completely immutable, then you can really start to simplify this. And so, in Sonic Pi you don't tend to need to do too much coordination right now. I have two main tools for that. One is to declare variables. It's the best I've got right now, because you're in Ruby. But to have the value of those variables be immutable.

So, in 2.6 which is about to be released, if I say notes equals scale E3 minor pentatonic, notes isn't a normal Ruby array. It's an immutable vector in a Clojure-like style, which means that I can't change it. I can give you that vector of numbers that represents E minor pentatonic scale. And you can do diddly squat with it. So, if you're another thread, you can't suddenly shuffle it and then my execution is going to change because suddenly something I thought was ordered is now changed and reshuffled. And so, this is really important. So, having immutable data structures is really important.

And then the other thing I've got is I’m starting to build a channel-like communication mechanism across threads which I call queue and sync, which allows you to coordinate multiple threads so that… because the typical problem is if I’m performing in a night club I've got that bass drum booming out. I've got my bass riff going. And they're all working in time because I’m choosing my sleep times between. So, I've got my bass drum where I’m saying like sample bass drum sleep for half a second, loop. So, it's just going around, buff-buff. And then maybe my melody, I've got my list of notes and I’m saying every eighth of a second, play the next note. And because an eighth and a half are factors of each other, we've got a nice rhythmical pattern here. But if I change my bass drum to instead of being 0.5 to 0.6 then you've suddenly got this thing where the bass drum's going to sound out of time with the melody. And so, that's a problem.

So, maybe I’m live coding and I make a mistake. I've accidentally added that extra digit in. So, I delete it, put it back to 0.5. So, they're both now in synchronization with each other. However the base drum is out of phase. It's not actually hitting on the beat. It's hitting before or after the beat. And so, this queue sync mechanism allows me to coordinate across threads to say, “Hey, wait,” tell the bass drum “Wait for the melody to loop around again, then kick in. And then when you kick in, kick at the same time.” And so, you can coordinate. It's like thread barrier synchronization. But it also shares the logical time, so everything is super timed. But then you can also pass data through that so you can say what the current call is or the current tempo is or stuff like that. So, you can poke down little bits of data to a channel-like thread barrier synchronization thing. So, I’m building tools but it's still very [inaudible] really.

You've mentioned Clojure a couple of times and some of the…

Yeah, yeah.

Features and functions of Clojure that make it nice to deal with threads and things like that.

So, why did you pick Ruby?

Good question. So, I really didn't want to. [Laughs] Because I'd built this really cool system, this Overtone system which is wicked and still is. And people use it all over the world. It's great to watch it grow. The problem is I needed to build something which ran on the Raspberry Pi. And at the time, the JVM support was pretty rubbish. So, I couldn't really use anything on the JVM. So, at that point then, Clojure's out the window. And so, I then fall back onto my next most familiar language, which is Ruby. So, I used to be a professional Ruby programmer. So, it was easy to build a prototype of a DSL in Ruby in a couple of weeks. And so, that's what I did. And then also, there's a bunch of the political reasons. So, if you're going to schools and they say, “What's this language? It's not Python,” because in the UK it's all Python.

Because Python, they're doing an amazing thing. So, they have committees and organizations and funding. And I just don't see any of this in the Ruby world at all, which is really disparaging. Why don't we have similar things? Why aren't we doing… Because Ruby's such a fantastic language for kids to learn. I've noticed so many fewer [frictional] barriers of Ruby, particularly the whitespace stuff or the fact that you don't need parentheses here. The fact that you can be a bit more flexible with the syntax. It's really important for when you're learning.

So, when the teachers ask me, “Why is this not Python?” I can say, “It's Ruby.” And they say, “Well, what's Ruby?” And I say, “Well, the first version of Twitter was written in Ruby.” They go, “Wow.” And I say, “Well, in the UK all the government's work, all the open source work is mostly done in Ruby.” And they go, “Oh, okay.” Then it's okay. So, you've got to get past the teachers and the headteachers who somehow have these fixed ideas about what programming is, which is often not necessarily completely in line with what the industry is doing. But you still need to play these political games. And Ruby passes the tests very well. Clojure wouldn't, I don't think, so easily. Because it's so distant from Python that it becomes a barrier, whereas with Ruby I could say, “It's pretty, like it's basically Python. So you're okay.” [Chuckles]

With Clojure you have to say, “Well, it's basically Java,” because it runs on the JVM.

But it's also this Lisp thing. And you're going to…

Yeah.

[Inaudible] different places. And yeah, and everything's functional and immutable. And so, teachers already have such a nightmare at the moment trying to work with this new curriculum and to teach computer science effectively that they really need to support each other. And so, Python already has a huge amount of people who share work, who share ideas, and support each other. And so, being able to tap into that is actually pretty useful. Whereas yeah, it's a shame with Clojure it's so different. But I am morphing Sonic Pi away from Ruby and towards Clojure every version. [Laughs] So, I am taking it into a different direction.

I'm curious as to what's on the road map for Sonic Pi in the near future.

There's a whole bunch of stuff. I need help. So, we have a core team which is great. It's Xav and Joseph and Jeremy. But yeah, I've got lots of ideas but little time. What's next really is taking advantage of the fact that we have text as our medium of composition and performance. And what I mean by that is this. At the moment, I’m jamming in my house, practicing. And after which, well maybe it'd be nice to press a button and to stream this stuff out so people could listen in if they wanted to. And, oh I could listen to other people's jams. So, of course we could do this with screencasting or Twitch.tv or whatever. But actually, when you're working with text as your medium of communication, I don't need to send the audio and the video data. I could just send the text with timestamps of when I did stuff, like having subtitles.

So, being able to jam with each other just by sending timestamped Ruby strings essentially would be pretty wicked. And also, is a way of recording what you did, just to have that as a very, very small file format to have just text with timestamps, would be pretty wicked. So, when I’m jamming often what will happen is mostly I sound pretty crappy and then I would get to the part where, “Oh, that sounds really sweet.” And then the challenge then is to recreate that. So, if I have a timeline, if I can just go back in time to the point where it sounded good and then press play again and then hear that music, that'd be pretty cool for learning and collaboration. And also be pretty useful for learning in schools as well. So, taking advantage of text being the medium in terms of creating some sort of timestamped immutable data structure than can go back and forward in time would be pretty sweet. And then collaborative jamming, being able to jam together is something I’m working on as well. That would be pretty nice.

But really, what the main focus right now for me is, is supporting the classrooms, making sure that when teachers ask for something, that it's in Sonic Pi, which I’m very happy that I’m achieving right now. There are very few things the teachers are asking of Sonic Pi that it doesn't have in. And then the other side is to make sure that it’s a bad-ass tool for making music with. And so, doing performances is part of that. So, every performance I’m doing, I’m adding new cool tools like snippets. Or I have this really cool mechanism for ticking through what I call rings, these immutable data structures. And new kinds of data structures which are really useful for working with music, building those and working with them, and making them simple. Because the goal of Sonic Pi is to build a really sophisticated tool that passes this test that every feature, I could teach to a 10-yearold. And if I can't teach it to a 10-year-old, I don't put it in.

And so, it's a really hard fast rule. And so, yeah. And if I've built something which is too complicated, then I'll take it out. And that's not needed to happen very much. But yeah, that's something. Because if I can teach a 10-year-old, I can teach it to everybody. It's not about 10-yearolds. It's about everyone. And if you've got an adult who says, “Oh, I don't get technology,” it makes me a bit angry. But then you can say, “Well, if a 10-year-old can do it, then you can totally do it. Just open your mind a bit. Explore and have fun.” And don't say programming is not for me. Just say, programming hasn't been for me yet. It's a much more powerful and optimistic statement.

Oh, wow. Sam, can I put a bug in your brain about the timestamp revert stuff?

Yeah.

There is a mode, and by the way we can talk about this after the call, but I’m an Emacs guy as well.

Yeah, yeah.

And I totally want to know how to hook into this from Emacs.

So, there already is an Emacs mode for Sonic Pi.

Oh, sweet. Okay, cool.

So, Joseph Wilks, yeah.

Okay, so the bug to put in your brain about this is there is… I haven't used it so I can't claim authoritatively that it's perfect. But there is an Emacs mode out there that every time you save your file…

Undo-tree?

It's not Undo-tree. But it might be.

But if it detects that you're in a Git repository and you modify a file and you hit Control-X, Control-S, it will create a private branch off of the current branch and it will save that. And you keep saving, keep saving, keep saving. Every time you save the file, it does a commit to this little branch. And then when you say, “Okay, I’m ready to commit this,” it squashes them all into a single… so all of the 15 auto-saves that you made over time vanish when you're ready to do a commit. But if you want to go back in time later and say, “Oh, I need something from 15 minutes ago,” you can actually just start unwinding back through the saves.

Sweet. So, it's integrated with the editor so it can actually go back in that. Yes, that is exactly what I want to build into Sonic Pi. But I have to build in a way that 10-year-olds can understand. And I

haven't figured that out yet.

So basically, if you remember what branch, you just hide Git inside this. And if you remember what branch you're on…

Oh, in Sonic Pi every time you press play it actually does, I’m using GitHub's Git stuff. It always saves everything. So, you've got a whole history of every run you've ever played in Sonic Pi now.

Perfect.

I'm just, I'm not taking advantage of it yet. But what you've said is exactly what's already in my mind. So, in all versions of Sonic Pi, it stores all runs in a Git commit, a local Git repository.

That's awesome. That's awesome.

Yeah. But yeah, if you're up for helping, that'd be wicked. If anyone else is listening…

Yeah.

And wants to help with this stuff, then please do. It's all on GitHub, Sonic Pi. You just google it. You'll find the repo. And we're really looking for help. Looking for help for these kinds of features and we're really looking for help with people who know their QT stuff. Because I’m really crappy at C++ programming. And the GUI, it shows that. [Laughs] So, anyone who's happy to really get involved and to help improve that would be pretty sweet. But anything, really. When people start using it and find frustrations and what it doesn't do in terms of what they want, and if we can figure out a way to put those frustrations into features which passes 10-year-old test, then it'd be wicked.

I'd really like to help support and to coordinate development of those ideas.

That totally makes sense.

Yeah, people should check out… I've just created a Facebook page which is like a musician/band. So, it's really weird. I'm a programmer. But I’m starting to call myself a musician, which has got some cool pictures of recent gigs and some videos of recent performances. I did a performance for a festival called Node in Frankfurt a few weeks ago. And I took a section of that set which I'd recorded. And I did the whole gig on a Raspberry Pi as well. And for 400 people. So that's like, this is really live coding with really low bare bones hardware. And so, they're taking a piece of that and I made a Vimeo video from that. So, people can watch the kind of sound you can create with Sonic Pi that's beyond just making some beeps and some drums.

That's amazing. Sam, there's some interesting things that you have said about coming from a Clojure background into Ruby to try and make these systems.

Well, so I went Ruby to Clojure to Ruby.

Okay, which actually still matches the pattern of what I’m thinking. How much heritage do you draw from tools like Archaeopteryx or Midiator?

Yeah, so I don't know Midiator. I know of Giles's work with Archaeopteryx. That was around the time we were working on Overtone. And I remember looking at that thinking, “Oh, it's pretty sweet. But it's very, very simple.” And it has its fundamental flaw that I was trying to fix and I had fixed in Overtone. And I fixed in a different way in Sonic Pi, which is the management of time in that Archaeopteryx just used Ruby sleep for time.

Right.

Which is pretty poor, because you've basically got the operating system can kick in. GC can kick in. Your scheduler basically says sync for at least this amount of time, but maybe it's a bit more because you're doing other stuff. And so, you've got no guarantees. And so, the first version of Sonic Pi because it's just really a [nodding] two-week job uses the same approach, just use sleep. But as soon as you had two threads where one was doing drums, one was doing bass, you could hear them get out of sync pretty quick, especially on the Raspberry Pi which was instantly out of time.

Yeah.

And so, yeah it's cool that Giles [wrote it]. It's just a shame that it didn't do any… it didn't really go anywhere with it. I had this really cool presentation. I've got people excited DJ-ing with Ruby. But it didn't really seem…

Yeah.

Whereas the stuff we were doing at Overtone… it was funny because at the time he sort of poopooed SuperCollider which is the system that both Overtone and Sonic Pi use and said it was far too academic. But to be honest, it's just an amazing system that's just fabulous that is just so incredibly capable of making amazing sounds. I think he was wrong to… But Giles has since then, he spent a bunch of time with Overtone and I’m sure he's messing around with Sonic Pi now. So, if you're listening Giles, hi. Sorry for dissing the sleep thing.

But so yeah, it's cool that people are doing it. I just, I’d like to get more people doing it really, to be honest. And so, Sonic Pi is a gift for that. But if people want to make similar systems… in the live coding world, there's a bunch of really cool live coding systems, like Alex McLean's Tidal, Thor Magnusson’s ixi lang. There's the JavaScript one, jibber. I can't remember the chap who's written that. SuperCollider itself is okay for live coding. But I wouldn't really recommend it. And so, there are some really cool systems. But a lot of them have been developed by individuals for their own use, with exception I guess with ixi lang.

And so, where Sonic Pi's goal isn't just to build a sophisticated live coding system. It's to build one which is accessible to everybody, or as many people as possible. So, it's the only system I’m really aware of which is focusing on getting 10-year-old kids to work with whilst at the same time have this laudable goal of getting it to be a rich, sophisticated night club environment. And I achieved that by narrowing its range of what it can do. It can only do music, really. You wouldn’t want to write anything else in it. So, by narrowing the range I can extend its capabilities from beginner to expert.

So Sam, is there any truth to the rumor I’m starting right now that your ultimate goal is to get 10year-olds into night clubs?

Well, when they're old enough, absolutely. [Laughter]

Excellent.

Yeah. I think that's absolutely a way to do it. I think that when these kids… because if you look at dance music, how did dance music start? It started by kids picking up old bits of hardware from second-hand shops that the adults didn't want because they didn't really understand how to use them. And these old bits of hardware were drum machines and bass synths that were built for guys in pubs playing with the guitar too, or the lady playing her guitar and having the drum machine playing the drums, the backing drums. And so, you wouldn't need a drummer for example. But these things are hard to program, hard to use, and didn't sound very good. So, they're expensive as well.

So, when people found out they weren't very good to use for their intended purpose, they all went to the second-hand shops. And when the kids picked them up, of course they didn't have any desire to play crappy pub music. They wanted to make music that was different. And they wanted to play and experiment and tinker. And so, they did things with these systems that no one had imagined. They changed the rates up. They tweaked the settings. They completely perverted the system. And out of that came dance music. Out of kids tinkering with technology and using innovation, using systems in ways that people hadn't imagined, new things came about. So to me, I’m making interesting music that I’m pleased about because I’m expressing myself.

But the real joy comes when some kids do things that I can't imagine with it. And the music they're going to make with Sonic Pi is going to blow everyone's face off. It's going to be fantastic. Yeah, and when they're old enough to do night clubs, yeah. And whether it's Sonic Pi they're using or another system, it doesn't really matter. What matters is people realize that code is one of the most, well pretty much the most powerful, exciting, creative tool we have available today. And the more we could teach computers to od in the real world, then the more creativity, the more excitement we can put into working and changing the world, and expressing yourselves in new ways.

Absolutely. I just listened to the Acid example.

And I have a new favorite coding tune. This is freaking awesome. So, what about external… do you have plans to hook into MIDI, to talk to drum pad, to talk to other output?

Yes, yes, and yes. Yes.

Excellent, excellent.

Yeah, yeah. It's just the time system's a bit of a pain right now because of the way it works to get event in and have them work out latency. I've still got some problems to solve there. But it's just a matter of time. So, yes.

One other thing that I’m wondering is, and I haven't had a chance to play with it, but it seems like there are different types of sounds. So, do you have a set of instruments that you can put in there? Like the drums and…

Yes, there are two kinds of sounds in Sonic Pi. There are two functions, really. Well, there are three functions. There's play which does this beep and you can change the synth. But really, the command is synth. There's a function called synth. And you give it a parameter which is the name of the synth. There's a dropdown menu with a choice of synths. [They're all] Sam Aaron pretty much designed SuperCollider synthesizers. So, these are real-time generated sounds that are generated in real-time on your computer using a bunch of maths running quickly through your machine doing lots of computations.

And those instruments, those synths, they're really very parameterized. So, one of the parameters is the pitch. One might be the amplitude or the cutoff frequency. But some of those synths have 25 parameters. Tons of parameters. So, you can really go nuts and change those parameters in crazy ways. I built, the thing with SuperCollider is it's not very safe in terms of you can pass parameters which make horrible noises or kill the server. So, I’ve really tried to explore all the possibility of combinations. And where I've made horrible sounds, I’ve built functions which stop you from doing that. So, certain values of those parameters will raise an exception saying, “Sorry, that's not a good value.” And you can click a little button to turn that off if you're really sure what you're doing. But so, you can feel free to change those values to whatever you want and see what happens.

And then the other kind of sound is a sample. So, a pre-recorded sound. So, there's a whole bunch built in, like 70 of them. They're all Creative Commons Zero License so they're free for you to play around with. They're from a website called freesound.org. And those things are just pre-recorded sound. So, I've got sounds of drums. I've got sounds of drum beats. I've got sounds of guitars being played, the choir singing. And you can totally bring your own sound, you own samples. You can record your own samples. You can buy sample packs. So, when I perform I often work with a couple of sample packs I bought from artists that I really like and use those and mix those into the sounds. So, you can bring your own sounds in. So, they're the two, the core sounds you can create.

And then the third thing which is the real magic, is the effects. So, I talked earlier about this with effects block. And you can say with effects reverb or slicer or distortion or flanger. There's a whole bunch of these effects. And those too are also parameterizable. I can change the speed of the slicer. I can change the [inaudible] of reverb. I can change the noisiness of the distortion. And again, some of these effects have 20 parameters. So, you can go really fine detailed in how exactly you're going to precisely change those things. And also, how you change them through time as well. So, I don't have to have one setting. I can, through time and in really precise ways change those values if I wanted to.

And so yeah, the ability to play these synths, the ability to play any pre-recorded sound, and then to manipulate and modify them through effects, and also yeah, the effects are nestable. So, I can have a sample played through reverb, played through distortion, played through flanger. And again, each of those nested items I can individually parameterize, individually control. So, with just those three components, and then the fourth one being time, being able to change when I start and stop these things, I have huge amounts of control of the sound.

Cool.

Does that answer your question? And then with the control structures you get from programming like looping and iteration and the control structures Sonic Pi gives you like this live loop, then that allows you then to really take those things I just described and put them into a performance where it's always constantly changing and moving and doing what you want it to do.

I'm just waiting for this to be taken from the say command on your command line where you make your computer say words to the sing command.

Yeah. Well I guess you could backtick say into a Sonic Pi program. I guess it would work.

Alright, well do you guys have any other questions or things you want to bring up before we get to the picks?

I'm good.

I'm going to have to cut myself off. This is just amazing and I could talk for three hours about this, but I’m good.

Alright. Parts two and three, next week in the… no, I’m just kidding. Alright, well let's go ahead and do the picks then. Coraline, do you want to start us off?

Sure. I have a couple of picks. The first is a blogpost by Cate Houston called '5 Strategies for Making Progress on Side Projects'. And basically it's about having side projects and trying to juggle time, bouncing time between work and life and everything else to actually make some progress on things, other things that you care about. So, the blogpost covers tips for scheduling, for to-do lists, shipping small and often, execution, and what she calls strategic Saturdays which are a great way to parcel off some time to work on things that are also important to you. So, I’ll post to a link to that blogpost in the show notes.

Second pick is a program called TIS-100. It stands for Tessellated Intelligence System. It's basically an open-ended programming game by a company called Zachtronics. In the game you rewrite corrupted code segments to repair the computer and unlock its secrets. So essentially, it's an Assembly language programming game. It includes an 80s style reference manual. It's absolutely joyful to read. It comes with more than 20 programming puzzles. You can compete to see how well you're able to minimize cycles, minimize instructions, minimize node counts. You can even create your own code challenges in the sandbox. It's available on Steam right now for Windows and OS X and Linux. And I will post a link to that as well.

Alright. Dave, do you have some picks for us?

Sure. I got a couple of books today. The first one is 'Building Microservices' by Sam Newman. This is from O'Reilly Press. I think a lot of us have worked on SOA projects now. And that means that a lot of us have worked on SOA projects that have just gone bad where you end up with all of the same problems that you had with your monolith, only now your monolith is on 17 different systems. And you can't monitor. You can't control. It's just out of control.

And to sum the book up quickly if you don't want to read it, each of your services should be rewriteable in two weeks. Or otherwise it's not a microservice. It's too big. Your services should be violently fault-tolerant, meaning if any system goes down, everything else should always keep working, even if all they can do is return a, “I can't help you right now because the service I need is down. But just because that service is down doesn't mean I’m down. I just can't take care of you right now.” And then ubiquitous logging, monitoring, and just inspection, the ability to see into every piece of the system. And this has really, really addressed a lot of the pains that I’ve had with SOA systems. Things like failure domains where the failure domain of a service is everything that you will take down with you if you go down. And in microservices, you're not allowed to have a failure domain. Or you need to minimize your failure domain. And with a lot of SOA headache projects, the failure domain of every service is the entire system, right?

[Chuckles] Yes.

And so, we've all been there, right? So anyway, 'Building Microservices' by Sam Newman. I think it's absolutely fantastic.

The second one, I’m only halfway through because I’m taking the author's advice. And that is to sweat through the book. And that is 'Clean Code' by Uncle Bob. Basically it's just a manual for how to write better code. And the really interesting thing about it is that he just flat out comes out and says, “Going from okay code to really good code is really hard.” You have to sweat over it. You have to labor over it. You really have to think about it. And this whole red/green refactor stuff, that's great.

But we've all been on projects where it's like red/green, ship it, whatever.

And he's basically saying red/green is the easy part. The refactor is where you really have to sweat blood and tears into the code to make it okay. And to be a good citizen you have to stay on this code and clean it until it is proper, until it does pretty much what you would expect it to do. And it's intuitive and other people can understand it. And those are actually my picks for today, just those two books. There's definitely a lot of work and a lot of reading and a lot of learning in those two volumes. So, those are my picks.

Alright. I've got a couple of picks. This whole conversation reminded me a bit of a talk that was given at MountainWest Ruby Conference by Ben Eggett. It's about making music with Ruby. And it was kind of cool. So, I’m going to pick that.

And then yeah, I’ve just come off of the end of Ruby Remote Conf which was last week. When this comes out I guess it'll be two weeks ago. So, one of the talks that really struck me was Dave Thomas's talk. And we talked about some of the concepts here. But anyway, he got me playing with Elixir. So, I’ve been playing with Elixir for the last week and I’ve really been enjoying it. So, I’m going to pick Elixir and I’m going to pick Dave's book about Elixir.

And then yeah, I think that's it. I think that's all I’ve got for picks this week. Sam, do you have some picks for us?

[Inaudible] Peter worked on the Erlang VM. I'm jealous of those guys, what they've got. But picks. Good thing. Books I guess. two books. I would say first book would be 'Wabi-Sabi for Artists, Designers, Poets & Philosophers'. It's a really beautiful book about [inaudible] but it talks about this new, this Japanese idea which is the antithesis of modernism. And it talked really about messiness being an important thing to accept and understand, and always focusing on clean. So, this is like an anti-Bob statement, right? It isn't necessarily what we always want. And especially when we're working with change and things actually moving through time all the time. Focusing on this modernist perfect, cleanliness is probably a bad move. It's a beautiful book.

Yeah.

Another thing is 'The Joy of Clojure' by Fogus and Houser. It's a wicked book if you want to get yourself around some Clojure. It's one of those books where every page is a footnote to some really interesting paper or other book. So, it takes you an absolute nightmare amount of time to read it, if you do it properly.

And then piece of hardware would obviously be the Raspberry Pi. I recommend people get one of those, the Raspberry Pi 2. Not because it's just fun but when I make music, I've got a really expensive Mac but I actually use a Raspberry Pi. I have a little projector. I project it on the wall. Because it changes my attitude to programming. Because I’m not logged into Twitter or Facebook or Google. I'm not doing that. I'm using the computer as an instrument and focusing on its capabilities and what it can do and its constraints. And enjoying them for what they are. And so, really [seeing] programming as a performance. And I think the Raspberry Pi helps me to achieve that. And especially when I don't use a screen but I use a projector on the wall. It's a lot of fun. So, if people really want to get serious with Sonic Pi, I really recommend using a Raspberry Pi with a projector on the wall, and some headphones and some good speakers. Because it changes your whole approach and attitude.

Alright.

Awesome.

Well, this is really cool. I'm really looking forward to playing with this. Of course there are a million things to play with. So…

Anyway, thank you for coming, Sam.

You're very welcome. Thank you so much for having me. It's been a complete blast.

Thank you, Sam. It was delightful.

Thank you.

Alright. Well, we will wrap up the show. Thank you all for listening.