After introducing concurrency and running multiple threads of code together, I wanted to try and teach some understanding about how to make the code more rhythmically connected. I have avoided teaching any concept with a clear “right” and “wrong” way of doing things as I want the students to feel unbound by those types of rules and by rules I am mostly referring to music theory. I feel more and more that using code as the vehicle for musical expression is a different beast than more traditional instrumental music or even other types of electronic music, so the rules that musicians and composers are bound to in those environments don’t necessarily apply when composing with code.
However, I also recognize that I am teaching young people who have a preconceived notion of what “good” music sounds like and at this point I feel like very few of them have been able to recreate that in Sonic Pi with what they have learned so far. This is not to say that what they have made up to this point isn’t good or even that they don’t think it is good. I have learned that students are much more open minded about what “good” can mean when they are the ones making it. But if they were to hear their own compositions played anonymously with no context, they probably would not be so forgiving. The point is that I want to give them some tools to understand how to make the music “fit together” in a more familiar way, to feel more cohesive and deliberate. Whether or not they use them in the future will ultimately up to them.
So for this class, I planned to teach them the basics of subdivision using threads by making simple drum beats using three sounds: kick, hi hat, snare. I wasn’t going to frame it as “subdivision” or get into the basics of musical notes ie quarter note, eighth note etc. I preferred to just teach the concept without giving it an official title which wouldn’t have any meaning to the class. I presented it as getting our different blocks of code to play “in sync” with each other, although I told them that probably wasn’t the best word because there is a command in Sonic Pi called sync which we would encounter later. The idea is that the sounds in each block are going to fit together evenly even if they aren’t playing the same amount of notes.
I decided to try a different approach to how I presented this concept. What I have been doing up to this point is presenting some concepts by showing the class some demos of the code, occasionally getting their inputs or suggestions, answer their questions and then let them play around with the concepts on their own. But for this lesson, I was going to have them follow along by typing in some code I gave them and then tell them what we want the code to do next and have them experiment with how to do this. One reason I wanted to do this was to try and keep students more engaged throughout the lesson. I’ve noticed when introducing concepts, students seem antsy to get started, some of them are already trying to write code, some of them are spacing out, so by giving them something to follow along with throughout the lesson, I thought might keep everyone on task.
Another reason I wanted to try this was more of a pedagogical reason. As a public school teacher, I am subject to receiving observations from administrators at various points during the year to evaluate my teaching performance. There are several different areas that the observation is based on, one of which is questioning and discussion techniques. The idea behind this is that as a teacher, you shouldn’t just be teaching at the students or even just engaging with questioning the students and having them response to you. The tool of measurement for evaluation in this area encourages teachers to present the students with a question/problem and then allow the students time to discuss with their peers about possible answers and solutions for solving the problem. This allows students to be more engaged and share ideas with each other. It is also supposed to have more students engaged since everyone is involved in a small group discussion as opposed to one student in the class answering a question asked by the teacher. After the small group discussions, the class reconvenes and students are asked to share what they were discussing. This also avoids putting students on the spot when asking a question as they have had time to think, discuss and hear others’ thoughts so if asked to answer, they are much more prepared.
While I do this type of thing more when I am teaching other music classes, I wanted to try out doing something that would fit this method more with coding. Up til now, I figure the time the students are working together on the concepts presented at the beginning of class allows them to have discussions on how to apply the concepts in their own compositions which could be satisfactory for an administrator. But I know that the type of question and discussion method I mentioned earlier are always preferably to see happening in the classroom. Now I have always struggled to find a balance between what I feel is the best way to teach music versus what the evaluation criteria says is the best way (and keep in mind this criteria was not really developed with the music classroom in mind). But if part of my goal in teaching Sonic Pi is to try to legitimize it as not just a genuine teaching tool for Computer Programming but for Music as well, finding ways to apply this type of pedagogical approach can only help to elevate it to that status.
As students entered the class and got their computers set up, I told them to copy the following code that was up on the board:
t = 1
in_thread do
4.times do
sample :bd_haus
sleep t
end
end
Once everyone had the code, I talked through what each line meant.
t = 1 - A variable I am going to use for my sleep value
in_thread do/end - The command which will allow the next block of code to play concurrently with this block
4.times do/end - A repetition block for the number of times I want my sound to play
sample :bd_haus - A sample of a bass drum
sleep t = The amount of time to wait before the next sample plays. The value of t is 1 as specified at the top of the code.
I played the code so they could hear it is just 4 beats of a bass drum. Since I was going to have them try to create other patterns for the drumbeat, I wanted to give them a visual of what they were doing in addition to the music as I think most students have difficulty parsing out exactly what is happening in a musical example, especially when asked to differentiate between what’s going on with multiple parts playing at once. Because of this, I then switched to the website Chrome Music Lab. This is a great website developed by Google Creative Labs where you can explore several different musical concepts through creative interaction. I use it a lot in 6th grade to explain multiple different concepts, so I knew all my 7th graders would be familiar with it. I went to the rhythm section to show them a visual of the code I just wrote. This consists of two animal characters who play a bass drum, snare drum and hi hat to a rhythm based on a grid below where you can fill in the beats you want to play for each sound. There are 4 beats subdivided into eighth notes:
Here they could clearly see 4 beats of bass drum. The only differences were this beat played on a loop and the tempo was a bit faster. To accommodate for the tempo, I went back to my code and added use_bpm 90 at the top which was closer to the tempo in Chrome Music Lab. Next, I said I wanted to add another drum sound, the hi hat to play on the same beats as the bass drum. I first filled in those beats in Chrome Music Lab and played what it would sound like:
I then went back to Sonic PI and wrote the code necessary to produce the same effect. I asked all the students to also copy that code which now gave us the following:
t = 1
use_bpm 90
in_thread do
4.times do
sample :bd_haus
sleep t
end
end
in_thread do
4.times do
sample :drum_cymbal_closed
sleep t
end
end
I told them that I could have left out the in_thread block and everything would still play the same, but I am putting it there in anticipation of writing more code later. I ran the code so they could hear both sounds playing together at the same time. Now what I want to do is have 2 hi hats for every 1 bass drum. I went back to Chrome Music Lab and showed them what this would look like and played what it would sound like:
What I asked the students to do was to change the code so that it would replicate what was happening in Chrome Music Lab. I told them to discuss it with their partner and experiment with the code. Listen and see if it works. If not, try something else. One thing to keep in mind was the number of sounds happening in total. There were 4 bass drum beats and now we have 8 hi hats. As I circulated the room, students were thinking it through and trying different approaches. This is an example of a discussion question in which the students would have to think it through with their partners. They would try different approaches until they were able to figure it out. From there we would have groups share with the class their solutions to the problems.
It was interesting to see what the students came up with. At first some of them saw that they needed to make the change to the number of times the hi hats would repeat, going from 4.times to 8.times. When I saw this, I would ask them if it sounded the same as the Chrome Music Lab example. They would shake their heads no and I would point out how the hi hats and bass drum played at the same times but the hi hats would still be playing after the bass drum stopped. I asked them to think about how to change that to have two hi hats per one bass drum.
Other students, after changing the number of repetitions, started to play with the bpm in the hi hat thread. I hadn’t really thought about this approach, mostly because I only added the use_bpm on a whim so it would sound more similar to the tempo of the Chrome Music Lab example. But it did work. I made sure to credit those students that this was indeed one way to make it work, but also explained that playing with the bpm in different threads can get a bit messy if we continue to add more sounds, so I asked them to see what else they could do to achieve the same effect.
Other students saw that they would need to change the sleep value for the hi hats. Some hard coded the value for the hi hats which was 0.5 to make it work with the bass drum. Some did it by making another variable to use for their sleep value in the hi hats and gave it the value of 0.5. Both of these approaches were also correct and closer to what I wanted to have the students do. So I first let them know that this approach did work, but then asked “what if I decided to change the value of my variable? What is another way you could write the code so that you wouldn’t have to change anything else if you change the variable value?” The hint I gave them was that you can perform mathematical operations on variables. I left them with that to see what they could come up with.
This is another teaching practice that administrators like to see: Differentiation of instruction. Each group of students had a different level of understanding on how to solve this problem. Some were struggling with the basic concepts while others were able to solve it more quickly. The approach is to give each level of student something to help move them forward while not just giving them the answer. This is especially important for the students who are able to solve the problem more quickly. Challenging the higher level students is something that shouldn’t be overlooked. You don’t want those kids sitting idle since they finished quickly. I always try to have some sort of prompt or next step for them to keep their progress moving forward.
After about 5-6 minutes, I called the class’ attention back to the board and had students share some of their experiences. Most of the examples I mentioned came up. There were very few who got to the solution I was planning on presenting. I highlighted that we would need to change the repetition but that because of this we would also need to change the sleep value. I acknowledged that students who put 0.5 for the sleep value were correct and played that example with the value hard coded. But as I had said to some of the students, I want to keep my sleep variable as part of my code so if I decide to change it, I only have to change the variable and nothing else. Since I wanted to have 2 hi hat hits for each bass drum hit, I can indicate that by dividing the sleep value by 2.0 (t/2.0) Since t = 1, this would be the same as putting 0.5 for the sleep value, but I find that using the division operator gives us a helpful visual reminder of what we want to happen ie two hi hats for each beat.
t = 1
use_bpm 90
in_thread do
4.times do
sample :bd_haus
sleep t
end
end
in_thread do
8.times do
sample :drum_cymbal_closed
sleep t/2.0
end
end
To see if they understood this concept, I asked them to have 4 hi hats for each bass drum beat. To keep consistent with showing them visuals, I had to go to another website since the Chrome Music Lab example did not subdivide that high. I went to another website which I like a lot for teaching musical concepts in a digital space which is learningmusic.ableton.com. This site covers a lot of concepts, but all I needed was the page for making beats which gives another drum grid that subdivides into 16th notes. I first showed them the previous examples we had done in Chrome Music Lab just so they could get a sense of the new visual design for this drum grid and then showed them what we were now looking to do in our code:
I didn’t give the students as much time for this example since the basic idea of what they needed to do had already be established. After a couple of minutes, I asked the class what they had come up with and we established that two things needed to change. The number of repetitions had to be 16.times and the sleep value was now t/4.0. I pointed out that the connection between the number of repetitions and the number we divide the sleep value by is the number of beats total in the thread which in this case is 4 as indicated by our bass drum thread.
With this in mind, we could choose what we divide the sleep value by before we know how many times to repeat if we know how many total beats we have in our thread. I chose something uneven just to break the traditional even subdivision we had been doing. I changed the sleep value to t/7.0. I explained this means we are going to have 7 hi hats per one bass drum beat. To find how many times we need to put for the repetition block, we need to multiply the number of hi hats per beat (7) by the total number of beats we have in the thread which in this case is 4. The students who were quick at math yelled out 28.times. I entered in those numbers and played the result. It was interesting to hear a 7 to 1 subdivision in this context as it sounded pretty seamless. I don’t think the kids even questioned that this is a “irregular” subdivision. This is one reason I really like Sonic PI. It makes it very easy to not adhere to the traditional Western theory and normalizes all approaches and practices.
The final part of this lesson was to add a snare drum thread. I went back to the Ableton website and added the snare drum (listed as a “clap” in Ableton) on beat 2 and 4. I played what it would sound like and asked the students to replicate this in their code. I reminded them that we have been looking at the number of drum sounds per beat. In the case of the hi hat, we had 2 or 4 per beat, but now we have 1 snare drum for every 2 beats. I also pointed out that we only have 2 snare drum hits over 4 beats which will factor into our repetition block:
I knew this was going to be tricky for the students even if they were able to figure out the math involved. A few students were able to get that they needed the snare to play half as many times as the bass drum so they divided the sleep value by 0.5 (t/0.5). This was a different approach then I had considered which was actually great to see students come up with solutions beyond what I had anticipated. A few other students did what I thought made more sense which was to multiple the sleep value by 2 although I realized we had never really discussed mathematical operation in Sonic Pi so they didn’t know they had to use the star character to multiply.
However even with these solution, there was one issue that no one was able to address. I drew attention back to the Ableton drum grid and pointed out that the snare drum doesn’t happen until the second beat which means it actually has to sleep before it plays. If we do it with the sample first the snare plays on the first beat. I showed them what this would look like in Ableton. Now if we let the beat play through enough, eventually our ear flips the beat count and it will sound correct. But in the case of our example, it is only playing through for 4 beats so it will not play enough for our ears to flip the beat. I wrote out what the code would need to look like and told them that this was not a solution I necessarily expected them to get but just wanted them to experiment with.
t = 1
use_bpm 90
in_thread do
4.times do
sample :bd_haus
sleep t
end
end
in_thread do
8.times do
sample :drum_cymbal_closed
sleep t/2.0
end
end
2.times do
sleep t
sample :sn_zome
sleep t
end
At this point there was only a little bit of time left so I just let them continue to play with adding some other sounds to their code. I realize they wouldn’t be able to dig too deep but since we had spent time exploring code throughout the class, I didn’t feel as bad about not having time to play towards the end.
There were some differences in this class from other lessons I’ve taught that I would like to recap.
1.) Having students start with a template of pre-written code. I usually go through a few examples and then give the students more freedom to try and incorporate those concepts into their own ideas. I will often leave the code from the examples displayed on the screen and have found that several of them will copy form that code to start their own projects. I have no problem with this. I know many people learn how to code by copying some code and then playing with it to see how it works. But for this lesson, they all had the same starting off point by copying the code given at the beginning.
2.) Having students work in small spurts and then taking time to discuss that work as a class. One of the first lessons when I taught the students play and sleep, I had them work for a bit and then we discussed questions they had to add more to their code. While I liked that format, I found that we wound up running out of time after giving some new commands to work with. In this case, the students had enough working knowledge to play around with what they had learned in this lesson.
3.) Giving students a definitive goal to work towards. In most cases, I just want to see that students are using the concepts correctly in their code but there are several ways that they can execute those concepts. In this lesson, there was a final result I was looking for that was more specific and could be looked at more as “right” or “wrong” in a way that wasn’t just based on syntax or writing the code correctly. It was actually the musical result that we were looking at to determine if it was done correctly which up to this point was something I was trying to avoid. I haven’t been evaluating how their compositions sound but rather the execution of their code.
4.) Using visual examples and other digital music making formats to explain what we are trying to make. I have basically just been giving code examples in Sonic PI when presenting concepts (with the exception of when we did our first form project where I gave them some musical examples of a Rondo). In this lesson, they were not only able to listen to how the code would sound in a different context, they could see a visual representation of what that would sound like which I think can make a big difference.
I am not saying any of these differences are better or worse then what I have been doing previously, but it was fun to try something new are experiment with different approaches to how I can teach coding to make music. Since it is all still relatively new to me, I feel like the more things I try, the better I will become and find what works and what doesn’t. The first year teaching something is always full of trials and tribulations, but through learning what works and what doesn’t, my method of teaching will continue to grow and improve.