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.
