This class was dedicated to students working on their in_thread projects that I had rolled out the week before. Unfortunately they were two weeks removed from the last time they worked on it as there was an assessment they had to complete for a different, unrelated part of my music class. As a result of this, I felt like remembering the main concept for this project which was making each block in a section last for the same number of beats was going to be forgotten or at the very least, hazy in the students’ minds. This has been a struggle for me through the year. Since I am only teaching Sonic PI once a week, what we cover does not have high retention. There is not really a clear solution to this problem either. I try to provide accompanying reference sheets and do brief reviews at the beginning of class, but it only can do so much for students who have a lot of other things going on for them academically.
The students were making various levels of progress during the class. By the time we were getting close to packing up, it seemed like quite a few groups were not going to finish on time. While I did want to make sure the students had adequate time to complete their projects, we were going to be on vacation the following week which meant it would be another two weeks before they got back to these projects. But it didn’t seem fair to have students turning in incomplete projects, so I decided to allow an additional class period. However, I wanted to get a sense of where everyone was at, so I asked everyone to submit their projects to Google Classroom. I figured I could go over each group’s code to see how they were doing up to this point.
It was very helpful to get an opportunity to check up on the progress that students had been making over this time. I was also glad to be able to point out where there were mistakes or misunderstandings in regards to the concepts of the project by using the comment feature in Google Docs. Several students seemed to not have a solid grasp of how to make the math work out to have each in_thread block last for the same number of beats. I tried doing the best I could to explain in the comments but I didn’t want to write too much. When giving feedback, I’ve learned that you need to keep it as succinct as possible. If students bother reading it at all, you want it to quickly address the point or they will miss out on what you are trying to get them to do as the result of the feedback you’re giving them.
Providing this feedback also proved valuable because our class got set back an additional week due to State Testing happening on our class day. While I had known about this in advance, our class was scheduled for after the test was finished. However, since these tests are now untimed, several students took more time than anticipated and those who hadn’t were pretty spent mentally, so I decided to let them have a breather instead of continue their projects. So by the time we met the following week, it had been 3 weeks since they last saw their code. I think it was helpful for the students to have something to refer to in their code to help get them on the right track. I also took a little time at the beginning of class to address some of the more common mistakes I had seen and quickly run down the main concept for the project.
Once the projects were done and submitted, I was disappointed to see that some students had not really looked very closely at the comments I left for them and in some cases hadn’t looked at the comments at all. This can be frustrating after putting in a lot of time providing feedback on student work only to have it completely ignored but it just becomes a way of covering your bases as a teacher. The same goes for reference sheets, checklists and rubrics. When I hand them out, a lot of the students do not even look at them or if I leave them at the front of the clas only a handful will actually come to get them. But I want to be sure that I have something there, at the very least to avoid excuses that the project was unclear or they were unsure how to do something. This is a common occurance amongst middle schoolers. They are just inclined to ignore most of what you say and try and figure it out on their own, even if past results of doing that indicate it is probably not the best strategy.
Overall, it was a mixed bag in terms of how the students did. Some of the requirements on the rubric were merely based on the amount of code they were writing ie the number of blocks in a section or the overall number of sections they made. So low scores in that area are essentially just because they didn’t include as much code as they could have. But the main concept of getting rhythms to align was an area where at least half of the students struggled. In some cases, it was merely just attempting to do something complicated and making a mistake or just having one block out of four that didn’t line up which is bound to happen. But others clearly did not understand what was being asked of them.
Here’s an example of some code which is not getting the concept correctly:
w = 1.75
in_thread do
40. times do
sample :drum_tom_lo_hard
sleep w/4.0
end
end
in_thread do
use_synth :dtri
22. times do
play scale(:a2, :indian, num_octaves: 1).choose
sleep (ring, w/5.0, w/10.0, w/2.0, w/5.0).tick
end
end
in_thread do
15. times do
sample :bd_boom
sleep w/2.0
end
end
5. times do
sample :tabla_ghe6
sleep w
end
These students were clearly putting in effort with the amount of code and trying to fulfill all the requirements but the rhythms clearly do not align. One thing that troubled me about this was that when you listen to the code, it is obvious that it is not ending all at the same time which should be a clear indicator that something was off. But I have felt for most of this year that there is a disconnect between typing the code and really understanding what is happening when listening to the code and how that related to what was written. This is something I think that in the future, I need to provide examples to help them practice. It is kind of like using your ears to debug as opposed to just looking with your eyes. You need to be actively listening for something and if you are unsure of how to do that, you won’t be able to figure it out. I think it would be helpful to do that for each concept to help solidify they students understand beyond just how to write the code.
I also wish there was more time to go back and revisit the project, so students could see what they had done wrong and make the proper corrections. But as I have indicated in this post, we have very little time as it is and when we miss a week here or there, it really adds up. This project took 5 weeks from beginning to end even though we technically only met for three 40 minute classes. If I add another week to do corrections, we have spent almost an entire marking period on this one concept if you count the introductory classes when I first present the concept to them. I really want to expose the students to as much as possible, so I have made the decision to forego corrections and continue to move forward. It is not like this is Math or English with a clear set of standards that they need to meet in order to be adequately prepared for the next grade where everything they learn will build upon that knowledge. They very well may never use Sonic Pi again after they are done with my class, so I figure the more I show they, the better the odds may be that some of them might feel inclined to check it out on their own based on the variety of concepts I was able to expose them to.
I’ll end by providing the code for a piece that I enjoyed which met the requirements for the project since I feel like I was more focused on what wasn’t working out for this post. I think that in part is just me getting end of the year fatigue. But I am determined to press on and see this experiment through to the end.
use_bpm 100
s = 1
in_thread do
16.times do
sample :bd_haus, amp: 8, rate: 16
sleep s*1
end
end
in_thread do
60.times do #made 15 beats only for reason
sample :perc_bell, amp: 6, rate: 16
sleep 0.25
end
end
in_thread do
32.times do
sample :drum_bass_soft, amp: 7, rate: 16
sleep s*0.5
end
end
in_thread do
8.times do
use_synth :zawa
play scale(:c8, :chromatic).choose, amp: 8
sleep s*2
end
end
in_thread do
16.times do
sample :drum_cowbell, amp: 5, rate: -1
sleep s
end
end
use_synth :gnoise
60.times do #15 beats for reason
play scale(:c4, :hex_major6, num_octaves: 8).choose, amp: 9, rate: 16
sleep s*0.25
end
sleep 4
#sect. 1 end
use_bpm 100
in_thread do
16.times do
sample :bd_klub, amp: 9
sleep s
end
end
in_thread do
16.times do
use_synth :tech_saws
play 64, amp: 6
sleep s
end
end
in_thread do
16.times do
sample :elec_hollow_kick, amp: 7
sleep s
end
end
use_synth :pluck
32.times do
play 70, amp: 8
sleep s/2.0
end
sleep 4
#sect. 2 end
use_bpm 100
in_thread do
16.times do
sample :bd_haus, amp: 9
sleep s
end
end
in_thread do
2.times do #this is different from the other commands purposely.
sample :perc_bell, amp: 9, rate: -1.5
sleep s*8
end
end
in_thread do
64.times do
sample :drum_bass_soft, amp: 9
sleep s/4.0
end
end
use_synth :zawa
48.times do
play scale(:c8, :chromatic).choose, amp: 9
sleep s/3
end
#sec. 3 end
#end