My year teaching Sonic PI - Week 2

#1

This week was the first time using the computers and getting acquainted with the SPi interface. I had to take some time to establish the protocol for getting out computers as well as headphones. I feel this is crucial to stress in the beginning, so that moving forward you can try and maximize instruction time using the program. Unorganized set up time can eat up a good chunk of time if you let it and then figure a similar amount to put everything away. I make sure the kids are aware of this fact early on and will even time them to put things into perspective.

Students are working in pairs for now and each one is assigned a computer. I have 3 cases of headphones (12ea) with each headphone numbered. I have the students sign out on a sheet saying which # headphone they are using. This creates the illusion of accountability as if one gets broken, I’m not sure if I could track down the culprit depending on how much time had elapsed. But none of them have broken yet, so I guess it works. They also use splitter cables so two can work together on one computer. These don’t get signed out, but when I first started, a few disappeared so now I have them counted at the beginning and end of class to make sure they are all accounted for.

As kids are going through the motions of getting set up, once they have the computer up and running, I had them sign into Google Classroom. I created a class where I could have them submit projects and keep some documents. I had the idea to have a Google Doc that the whole class can share. On it I had planned to have them write questions or comments while they were working that we can all see and also copy and paste code to share examples without having to bring computers up to the Smartboard. I figured getting them signed on early would be one less thing to worry about moving forward.

I was surprised at how few kids were able to locate the program file on the laptop which were running Windows. Some went to a web browser, some tried to do a search, some just sat there clueless. It amazes me how these kids are in some way very tech savvy and live on their phones, but they lack very basic computer skills, like adding an attachment to an email or knowing how basic folder directories work.

Once I was sure everyone was open to Sonic Pi, I did a brief introduction of the interface. I showed them the play and run buttons, the text editing window and the console. I explained that the console gives us information about our code and we can use it to find out other information when we need to. My first demonstration was that we will be writing code in the text editing window. I just wrote “hello” and then ran the code. This brought up the error message. I did this for a couple of reasons. 1st, I wanted them to see where the error messages would pop up. This brought us back to debugging and if you make a mistake, Spi will give you some information to let you know what went wrong and how you might fix it.

I also did it to show that you can’t just type anything you want and expect a result. I had seen some kids already try to type something in the text window and just get error messages. Computers are very picky when it comes to code and if they don’t understand what you mean, they will not run the code. This brought us to the term “syntax” I explained syntax as being similar to grammar like punctuations and commas. However, the difference is that with incorrect grammar, you can still get your point across and be understood. With incorrect syntax, the computer will not run the code.

I like that the musical coding environment isn’t a free-for-all. Students cannot just type in anything and make something happen. They have to follow certain syntax first and then find areas where they can experiment. Even if they are exploring things they don’t understand they are learning how to use reference material to advance further into the program. In something like Garageband, you can input a bunch of random notes and make sounds but there is a very low bar of thought that needs to be put into it. The result is usually a big mess of notes that the students convince themselves sounds good but it rarely does. There is a bit more nuance and refinement in coding music. You can still start adding random notes, but you have to have a basic understanding of what you are doing first and the end result isn’t as sloppy.

To start the students off, I showed them the first command = play 60. I ran the code and they all heard the beep. I then instructed them to do the same. I walked around to make sure everyone did it correctly. “Congratulations” I said “You all just wrote your first line of code. You are now a computer programmer” I wanted to instill a small victory in them right from the start. I gave a brief explanation of Hello World and what it means. This is the Hello World of Sonic Pi.

From there, I said you now have a command which takes a number. This is called an argument. I then let them take some time to experiment with that to see what else they could make happen. As expected, most of them played around with different numbers and adding more play commands with varying results. Some would complain they couldn’t hear anything, but when I’d look at the code they would have a number like 6 or 34567632, so I would just say “Try another number and see what happens” I wanted the first few sessions to be about exploring without me giving too much guidance right off the bat. Also, since this is my first time doing this, I was curious to see what direction the kids would go in and what types of problems they would encounter.

One thing I hadn’t planned on was that some students used the auto-complete when typing commands to try new commands like play_chord. Once I started seeing it happen, it made perfect sense that they would do it, but my adult brain hadn’t really anticipated that they would try it out. When I was learning, I was usually following along a tutorial or had a specific command I wanted to test. I rarely would look at other possibilities for commands I could use that popped up in auto-complete. Needless to say though, almost none of the kids who did that were able to make much happen with it.

I had also encouraged them to write any questions or comments they had in the Google Doc. This didn’t work out quite as well as I’d hoped as I got some weird observations that were kind of ramblings. I saw some kids who seemed too concerned with making sure they wrote something in and others who had ignored it completely. I didn’t really get any of the questions I was hoping for (or any at all really) so I just kind of let it be and when I called the kids attention back to me after about 10-12 minutes, I just went moved forward with some of the answers to the questions I had hoped they would ask which it turned out they seemed like they had thought of but weren’t able to formulate into a coherent thought.

I first asked what did we notice when we changed the numbers. Several pointed out that the sound changes when the numbers go lower or higher. I asked them to be more specific and they said when the number gets higher, the pitch gets higher. I did a few examples of this in front of the class by doing play 67 then play 72 and pointing out how the pitch did change. I asked how many tried decimal points. A few had, so I showed that we can do numbers like 67.5. I mentioned the concept of microtonal and semitones but that’s over their heads and I didn’t want to go off on a tangent, so them knowing they can do decimals was enough.

I then asked how many put in a number and didn’t hear anything. Most hands went up. A few kids had experimented with finding what was the highest note they could still hear was (somewhere around 140). I explained that these notes are called MIDI notes and again without getting too deep into it, I explained was a method started in the 80s of sending musical information through computers and since computers, especially back then, really only dealt with numbers, a system was created where every musical note was given a number value.

In 6th grade, I do a whole unit on pitch and we discuss cycles and hertz and how the speed of a vibration affects its pitch and how certain hertz are outside of our range of hearing. Having this as a frame of reference gave me the opportunity to introduce two commands that otherwise I would probably not bother with. First was puts. I explained that this will “put” some information into the console. I did puts 60 and showed that ‘60’ appears in the console. I showed them that we can do math operations like 5 + 5 and get results in the console. I had also mentioned we could do math in the play command like play 60 + 5, but no one seemed too impressed by that so I kept it moving. The next command I showed them was midi_to_hz. I did puts midi_to_hz 60 and showed them that in the console was a number = 261.something something. I explained that this shows us that the pitch we hear when we type play 60 is 261 hertz and that each pitch we hear when we play a number is just a frequency created by the computer. Since SPi understands this, we can then go back to play and do play hz_to_midi 261 and we get the same pitch as play 60. I pointed out that using hz_to_midi isn’t really a great way to play notes, but it is there as an option and is helpful to just explain a little about what is going on behind the scenes.

I had planned to introduce sleep since quite a few students had experimented with trying to get several notes to play in a row and kept getting all the notes playing at once. However, it was almost time to pack up and the last thing I wanted to do was go long since we haven’t done our pack up routine yet. So I just took a moment to demonstrate that when I put two play commands right after each other, they play together. Remembering one of the many talks I saw online by Sam Aaron, I took this chance to explain that the way a computer reads code is going through each line from top to bottom and that the computer was, in fact, playing each of those play commands separately. This is called iteration. But computers are so fast at processing information, computing as it were, that to our ears it sounds like they are played at the same time. In order to get them to play separately we need a new command……….which we will learn next time. TIme to pack up.

Some takeaways I got from this first lesson:

1.) I noticed when I was trying to explain the concepts behind MIDI and hertz, there were quite a few kids who clearly weren’t paying attention and just fiddling around on the computer. While I’m happy they are really into experimenting, I really don’t like taking time to explain something only to have to explain it again several times to kids who weren’t listening the first time. So for the next lesson, I planned on having kids put the laptop screens half down as a sign of good faith that they were going to listen to me.

2.) The Google Doc idea needed some refining. WhIle I like having kids share observations, the ones that really make a worthwhile point in relation to what I am planning to do that day are few and far between and often take us way off track. At this point, I am also more interested in pulling questions out of them. I want to see that they are thinking of ideas but don’t have the skill set to execute it yet. I find creativity is fostered by setting boundaries. When you do that, it gets them thinking “If I didn’t have these boundaries, I would do this” and it gives them a direction to go in once you do give them more freedom.

3.) Most students will try to go beyond the initial command that you give them. They will always try to experiment. Try to encourage this within reason as long as they are not getting too far off track or if they are, they should be prepared to share what they did with the class. I want to see kids figure out stuff on their own and then put them in charge of sharing it with the class. Since this is all new to me, I’m not necessarily sure what the best sequence of lessons is, especially since this isn’t a Computer Science class, it’s a music class. So a kid figures something out that is within reason of where we are, I will ask that student to do their best to share what they did with the rest of the class. They might not explain it in the best way, but I know that kids are always more receptive to learning from each other then they are from a teacher, no matter how much they like you.

Net week, I plan to introduce sleep and show them they have the option to use musical note names as arguments for play.

7 Likes
#2

Great detail on your week 2 class, with some good ideas for getting going. I look forward to reading how week 3 goes! When I was teaching (now retired) I always found it a temptation to go too fast, and I like the balance you struck between introducing new stuff and making sure that the pupils followed the basics, and yet allowed (and found some unexpected eg autocomplete) experimentation.

2 Likes
#3

Some familiar experiences in here. :smiley:
I highly recommend telling them to turn their computers around and/or close them when you are trying to talk. Good work on the headphone management.I have definitely had to set boundaries for parameters. I try not to let them get too far ahead, especially if they rely on my guidance a good bit. The kids who are showing me they can jump ahead independently I let go ahead and do their thing, typically these students have some coding or music background. I like to give them play and sleep early, then I have them make me Mary Had a Little Lamb to show that they understand the process. I’ll definitely keep an eye on these updates as it looks like you have some great ideas and likely a good bit more teaching experience than I.

2 Likes
#4

Thank you. Always nice to get feedback and hear what others are doing.

I am hesitant to have kids compose a traditional piece like that.
I would rather see what they come up with on their own. Some will try to recreate a piece, but I don’t want to force that on them. I’d much rather have them make something of their own. That is one of the great things about SPi, you can compose your own song with relatively little musical knowledge. I love when they hold out their headphones and say “listen to what I did!” You can tell they have a sense of pride because they made it on their own.

At this point, no one is really going too far off independently, but occasionally someone is trying to do something that involves a more sophisticated concept we haven’t approach yet. So I’ve been giving those kids just what they need and seeing what they do. I also am keeping track of those examples because I plan on using them as examples when I do get to those concepts. For example, one kid kept doing play 60.99999999999999, so I showed him how to make that a variable so he doesn’t have to write that long float # every time. Or another group wanted a synth to change the first time through a 4.times but not the second time, so we talked about conditionals. I’m trying to be flexible and see what the natural progression of the kids curiosity is and base my planning on that.

2 Likes
#5

I think it’s very much down to the taste of the educator, but in this case I’m with @mrbombmusic. I think there’s a danger with emphasising cultural notions of ‘right’ and ‘wrong’ with music - i.e. “see if you can code this piece correctly”. I think for some individuals who don’t necessarily get modern western traditions of music, it might be an alienating move. Firstly, perhaps because the music isn’t meaningful to them, so doesn’t provide sufficient motivation and secondly perhaps because they don’t yet have the skills to do a decent translation so it acts as a barrier.

I personally prefer letting people loose with Sonic Pi - emphasising personal creativity - ensuring they know that there are no mistakes, just lots of different sounds to be created. I think the goal should be to get people coding, not necessarily get them coding ‘correctly’ - that can come later. Of course, some individuals may benefit from having a guide piece to work towards, so having it as an optional resource that they can cherry-pick might help you cover more bases.

Also, for the “listen to what I did!” moments, I massively recommend having a decent portable speaker so you can plug it in and show the whole room - it will serve as a talking point, and you can encourage people to share ideas :slight_smile:

3 Likes
#6

@samaaron Do you have any recommendations for a portable speaker. I have one or two small ones, but haven’t yet found the “killer” speaker for such a job. I have a Drok amp from Amazon which is good with external speakers, but bit too unwieldy for portable use.

#7

Hi Robin,

let me jump in: I am using the Creative D200 for classroom and presentations which has a decent quality and an affordable price: https://en.creative.com/p/speakers/creative-d200

Martin

#8

Looks quite a good spec, but I’m not sure if it is still available. Doesn’t show for sale on Creative shop site and no longer available on Amazon.

#9

I use a minirig - if you also get the sub it’s amazingly loud and very decent audio quality :slight_smile:

#10

This is why I like the idea of having everyone open to a Google doc from Google Classroom. As the teacher, my laptop is already hooked up to the main speakers in the room and a Smartboard/projection screen where I do all my examples and slides for the class to see. With the google doc I can just ask the student to copy and paste their code on to the Google doc which I also have open, then I can quickly copy and paste it to a buffer in SPi on my laptop. This way I don’t have to move speakers around AND everyone else can now see the code on the projector in addition to hearing it which it seems is the whole point of sharing out in the first place. I know I’ve heard @samaaron talk about performing and showing code or watching someone play guitar hiding behind something. I feel like that is applicable here. :ear::eye:

3 Likes
#11

Oh, yes you are right. Some time ago when I bought it. So either a used model or some other portable loudspeaker (with good bass support). You will probably have to spend at least around 100 EURs, better more. I heard that the JBL Charge 3 is quite good (and even better portable because it runs with batteries).

But mostly I can also use the sound system of the room (which is in most cases the best solution). Nevertheless the Creative loudspeaker serves the purpose if I have to present and can not rely on an existing sound system.

1 Like