My year teaching Sonic Pi - Week 1

#1

The first class I told them we would be using something called Sonic Pi this year and then without any further explanation showed about 6-7 minutes of Sam Aaron live coding. From there I asked the students to think about what they had seen and heard and what they thought was going on. Responses varied but most pointed out that the music they were hearing corresponded to the words on the screen. I was also surprised that quite a few of them went right to the word “code” which is where I was hoping things would go. From there, we had a brief discussion on what “coding” was and how it can be used for creative purposes.

We also talked about the concept of “Live coding”. I did a quick demo in p5.js showing how each time I wanted to make a change, I had to stop the code and rerun it. Sonic Pi (as we all know) has the ability to change without stopping. It’s funny how this seems like a no-brainer when making music, but I had to explain that in the world of computer programming, this is not the easiest thing to do. But the ability to do this provides us with the option of using Sonic Pi not just as a compositional tool but as a performance tool as well.

I used this opportunity to pose a question “What is the difference between composing and performing?” I also asked how our mind state differs when doing one or the other. Kids had some interesting answers. Several equated performing with being in front of an audience while composing is done alone away from others. Others pointed out that when composing, you have the opportunity to make changes while when performing, you have to just do it and “can’t make mistakes” .

This led to the point I wanted to make: “What happens if you make a mistake when composing?” The consensus was that you can change it or fix it. “What about when you are performing?” They had to think about this one. “You just have to keep going, I guess”. I used this line of questioning to stress that mistakes do happen and in performance, you can’t go back and fix them, you have to move forward. I shared a piece of advice someone told me once “It’s not a mistake unless you let the audience know it was a mistake” They might think you meant to do that. Sometimes the mistake winds up being better than what we originally intended to do.

I shared the piece of wisdom given by Sam Aaron when referring to Sonic Pi “There are no mistakes, only opportunities”. I really like this idea, but I also wanted to set the tone from the beginning that mistakes are part of the process. We are going to make a lot of mistakes. We will learn from them. Mistakes are not a bad thing.

I referred back to my p5.js demonstration where I had tried to get a circle to move across the screen but couldn’t and that was where I had ended that demo. While the kids were discussing the differences between performing and composing, I took a second to debug the code and it was just a capital letter where there should have been a lower case. I was glad this had happened so I could point it out to the kids that often your code will not work because of a simple little problem like that. When I told them what the bug was, many couldn’t believe that a simple oversight like that would stop everything from running (especially as middle schoolers who regularly make punctuation mistakes but somehow are able to get by). But it was a great opportunity to highlight that these types of mistakes will happen and happen often and we just get used to it. All programmers experience this. In fact, it happens so much, they don’t even call them mistakes, they call them bugs and the process of fixing is called debugging. This was the first real programming term I used up to this point and it wasn’t by accident.

Students, especially middle schoolers are always afraid to make mistakes in front of their peers and give a negative impression, so much so that many refuse to do anything simply to avoid that even being a possibility. So I had made a conscious decision to make the point of my first lesson be that mistakes are ok. They come with the territory and we will embrace them and learn from them.

7 Likes
#2

@mrbombmusic - this is wonderful to read - thanks so much for sharing.

Just to be clear, this is something I adopted from the jazz world :slight_smile: Also, I’m really glad you’re emphasising risk and mistake making as part of the reality of live coding. Personally I expect mistakes in live coded gigs - and when they happen I’m excited to see how the performer responds. I think the sign of a good live coder is not someone that avoids mistakes, but someone that embraces them and responds in ways that excite the audience.

#3

I come from a Jazz background, so this is like improvising 101 (or at least should be). I also want to make this idea go beyond just Live coding and make it about coding in general and even more so about learning in general. I think students often have the notion that a mistake is something to avoid but mistakes are how you learn things. Education should be about encouraging mistakes and being comfortable with making them. Our job as educators should be to provide a toolkit for students to use so they can look at their mistakes and know how to proceed from there.

Someone posted this on twitter which I thought was spot on:

My Principal shared this TED Talk with our staff which goes deeper into this idea and even breaks it down into two different zones Learning Zone vs Performance Zone:

1 Like