After going through all the compositions the students made for the first project assignment, I had noticed a few things that I wanted to address in the following class. One was that I didn’t feel like all the students were clear on what the expectation were for the assignment. I felt like I had explained it clearly in class, but I also know from experience that not everyone is always listening to everything you say when you are talking. Even those who are listening might not quite understand what you said and don’t want to feel silly by asking a question while others might think they understood everything you said but actually didn’t and do the wrong thing thinking it was right.
I was willing to accept the blame for this as the teacher because I didn’t provide some sort of clear reference or checklist for students to follow. One thing I always try to do is pre-emptively eliminate possible excuses a student could use for not doing an assignment correctly or at all. For example, when I give a homework assignment, if I give a hard copy of the assignment sheet, I always put a digital copy online for students to eliminate the excuse of “I lost the paper”. In this case, I didn’t have something to point to if a student said they were unclear about something for the project thereby legitimizing their excuse.
There was also a number of issues in the code of students who had submitted their projects. There were several recurring mistakes either in syntax or the student’s understanding of a particular function or concept which I wanted to address. Finally, as I had mentioned last time, some of the students didn’t realize that I wanted the assignment turned in at the end of last class, so there was a handful of students in each class who hadn’t submitted anything yet.
Because of all these reasons, I made the decision to allow an additional class period to either complete and submit the assignment or to redo the assignment based on the grade they received. Students who had completed and submitted were given a rubric score along with feedback which highlighted things they did well as well as addressing any mistakes or misunderstandings in their code. This would give them a direction to go in if they did decide to do it again. Below is an example of feedback provided:
I also created an assignment sheet with the task clearly stated at the top, a check list for all the basic commands they were expected to use and the rubric for the project. I made a slight change in the checklist for the commands by not putting in a specific argument for a function like sleep 1 or play 60 or use_bpm 90. I had noticed quite a few students were using the exact examples I had included on the basic command reference sheet I had provided and I don’t think they realized they could put any number they wanted. I hoped this new format would make it more clear. Also this time, I provided a paper copy of the basic commands and the assignment sheet linked [here]
At the beginning of class, I let everyone know that this period would be dedicated to continue working on this project. If they hadn’t yet submitted, they now knew it had to be submitted at the end of this period or it would be marked as incomplete. Those who had completed it would have the option to resubmit the project if they wanted to improve their grade. Those who submitted and did not wish to do it again would be allowed to have some free time to explore and I would provide them with a few new concepts to play around with.
From there, I had a short list of issues I wanted to share with everyone as they had come up enough times that I felt it would be beneficial for everyone to hear it. I started off with errors I saw that stopped the code from running. These are critical errors and the fact that I received some projects that did not run made me question if some students were even running their code before submitting it. I let them know that for future projects, I would penalize any code I got that stopped running because of an error message.
The first mistake was using capital letters for commands like play or sleep. I know using capital letters is something they have been trained to do for a long time, but for coding, it was a big no-no. I had a few examples of code on the Smartboard of play or sleep in capital letters and ran it to show the code would stop once the program got to that line of code. I also reminded them to use the error message console to help find the bug in their code to fix it.
The second error (which I am also often guilty of) was not including an ‘end’ at the bottom of a block of code, in this case for a repetition block (4.times) or a loop. This becomes more common when you are using multiple blocks and have multiple ‘end’s as a result. One method I shared which I learned from someone with Javascript when dealing with open and closed curly brackets, is to count the number of ‘do’s on your fingers, holding up a finger for each ‘do’, then lower a finger for each corresponding ‘end’. If you are left with any fingers up, that should indicate a missing ‘end’. I ran an example of code missing an ‘end’ to familiarize them with what the message looks like and in this case, sometimes it says a line of code which isn’t there and : end which usually means Sonic Pi is looking for that command but doesn’t see it.
Something else I had noticed when circling round the room last time was that students would complain their code had stopped or they could no longer hear their code. These students all had loop blocks on their code. I realized that they would make a change in their code and then run the code again without first stopping the code. I did a demonstration of running a loop, changing the code and running it again, making sure I started the code on an offbeat of what was already running so that the problem was more enhanced to their ears. When I showed them the loop function, I had forgotten to mention that if you don’t stop the loop from running before starting the loop again, the first one will keep going because you never told it to stop and the result will be two loops (or in some cases, 30 or 40) going at the same time. In my own practicing with Sonic Pi, I was using live_loops pretty much exclusively, so it made sense why I overlooked this.
Next were issues that weren’t syntax related or something that would stop the code from running but rather redundancies in the code. The first and more common example of this was using the same use_synth or use_bpm command multiple times in the code (as indicated in the feedback example above). Students would, for example, put use_synth :saw, then write some plays and sleeps then put another use_synth :saw. I explained that once you put that command, Sonic Pi will continue to use that synth until you tell it to use a different synth or bpm, If you are already running use_synth :saw, putting it again isn’t going to change anything.
The second example of this was students putting either use_bpm 60 (more common) or use_synth :beep (less common). I told them that these were the defaults, which is a term I had to also make sure they understood since it would come up again. It means that this is what happens automatically without putting in a command, When you run your code of just plays and sleeps, it runs at 60 bpm and uses the beep synth. Writing this in the beginning of your code isn’t going to cause any problems, but it is also unnecessary and since ideally we want to write nice,clean code, we want to avoid putting anything in that is unnecessary.
The next batch of issues were all based around the concept of iteration. These were things I noticed in several different projects which I wanted to bring to everyone’s attention, not because they are “wrong”, but just something we should be aware of. I felt like sharing these examples would also help get students thinking more about how their code was executed and get a deeper understanding about the flow of their code which could benefit some debugging issues in the future. I made it clear that these things may have come up in your code and if you were ok with it, then by all means keep it. It might have been what you were going for. However, it may have given you an unintended effect which had you been aware of it, you might have decided to do something about it, but being relatively new to programming, you might have just accepted it as a reality without really questioning what was going on.
First, the placement of use_bpm or use_synth. I had a few examples where students would put those commands towards the bottom of the code so only one or two play commands would be affected. In the case of use_bpm especially, this isn’t going to do much. If you are at 60 bpm and then your last two lines of code are use_bpm 90 and play 76, that change in bpm isn’t really going to affect anything noticeable.
Second, putting use_bpm and use_synth in between play commands. The result of this is going to be both of those play commands happening at the same time. Even though visually there appears to be a separation between each play, changing the synth or bpm happens instantaneously when the code executes, so without a sleep in between, you will get multiple notes at the same time. I pointed out that putting the use_synth command between plays could also create an interesting effect of having multiple notes playing together, but all with different sounds. This would be an example of a creative use of a basic command which was something that I had included on the rubric to achieve a 4.
Third, when using a repetition block or loop, if you start with just some plays and sleeps on the default synth or bpm and then include a use_synth or use_bpm halfway into your code, when the code repeats the next time around, it will carry that new synth or bpm with it, so that the initial synth or bpm (most likely the defaults) that happened when you first ran the code will be replaced by the command you included halfway through the first run of your block. I showed an example of this by having some plays and sleeps with a use_synth :chiplead in the middle so they could hear at the beginning of the block the second time around, it stayed as the chiplead synth.
I went with the synth over the bpm because I feel like a synth is easier to hear in terms of an audible change. I have learned over years of teaching music that you can not assume students will hear what to you seems obvious. You can never predict how someone else is going to perceive a musical example, so I always try and go with something very, very clear for my demonstrations. I have found changing from the default beep synth to chiplead, or even better, the mod synths have a very jarring change that is seemingly unmistakable to miss.
Last, students were putting a play as the last line of their repetition blocks or loops. I pointed out that this was creating the effect of two notes playing at the same time. I asked why that was. I pointed to the last play and then explained that when repeating it went back to the top, making a motion back with my finger, pointing to the first line of code in the block which was another play. I felt like this was a good opportunity to allow the students to think about what was going on and try and work through the problem. It wasn’t too sophisticated and since it was related to the other examples we had been talking about, I wanted them to try and figure it out. Sure enough, a few pointed out that we were missing a sleep at the end although I can’t guarantee these were the same students that made that had this in their code in the first place. Regardless, I was looking for more opportunities for students to start going through the code and having to debug a problem and this seemed like a good place to start.
That ended my laundry list of issues with their code from the first project. For the students who didn’t need to resubmit, I presented two new concepts. One was the use of variables. I asked what that word meant. Some had ideas from math, that it was a letter which represented a number, which was true. I asked what it means when something varies or has variation which brought reponses of something that is different or changes. So from this, I provided them with the idea of using a letter as a substitute for a number but that number can be different or change. We assign it a value using the equals sign ‘=’, for example n =1. Now Sonic Pi knows that if it sees the letter ‘n’, that it has the value of 1. So I can put sleep n and it will read that as sleep 1. I put a few plays along with sleep n in between them. One benefit of variables is that say I want to change the length of my sleeps to 2. If they were all sleep 1, I’d have to change each 1 to a 2. But now with my variable, I can just reassign the value to 2 and look. I ran the code and (hopefully) they could all hear each sleep lasted twice as long. I then changed the value to 0.5 for a more pronounced change from 2 to 0.5.
There was a student in one class who had told me he had taken some Ruby tutorials online. He had already started trying to use variables in his code which I thought was great. The variable names he chose seemed fitting for a 7th grader as they were names like “spam” and “eggs” although I assumed those were examples from the tutorials. I mentioned this student to make the point that variable in code can be words, not just a letter. As long as it begins with a letter, you can call it whatever you want. You could call it “hello’ or “bob” or “orangutan”. They LOVED this idea 
. You could see their eyes widen with the possibilities. They began shouting out possible variable names of which there are too many to mention here. I said yes to all of them, but made the point that a good practice of programmers is to have variables which make sense in regards to what your code is doing so if someone else were to look at it, it will make more sense instead of wondering why the word “orangutan” keeps popping up in your program. It wasn’t until looking over some shoulders later on that I realized I needed to put one limitation which was that all variable names needed to be school appropriate. Middle schoolers will always take free reign as an excuse to do something inappropriate.
The last thing I demonstrated was the live_loop. Since we had looked at the issues with running a loop again after changing the code, I took this chance to show one of the benefits of the live_loop. First, it differs because we need…… no, we GET to give it a name, just like a variable. From here, I can enter some code and it will loop over and over again just like the regular loop. I just put play 60 and sleep 1 for my example. But now if I decide to change my play note to play 67 and rerun it without stopping (which I did) we can hear that we don’t get the overlap effect. Sonic Pi stopped the last loop, made the change and continued running without actually stopping the program. From here, I made more changes to the play note, added some more plays and sleeps, added a variable and changed that etc.
This is now where we get into the idea of live coding. I am making changes on the fly while my code runs continuously without stopping. Here is where it becomes less like composing and more like performing, which was a concept we had discussed the first week in class. I also reminded them of the video we watched of Sam Aaron live coding and explained that was also using live_loops. I suggested that they take turns trying to do a short live coding experiment for their partner and then switch. From what I witnessed though, no one really seemed to latch onto the live coding idea and were just using it like a regular loop, which at this point didn’t bother me too much. I suppose it would find its place in due time. I was fine with just having them continue to experiment.
At this point, I said I would stop talking and let them work. I handed out the rubric scores and feedback sheets and gave them the rest of the period to work. There weren’t too many who decided to redo the assignment. Most just wanted to take this opportunity to play around some more. Some who hadn’t submitted yet were basically done but had just had some issues logging into Google Classroom last time and were quickly able to take care of that. I personally recommended to some groups that they should take advantage of redoing the project. Some did, some didn’t. When I give these opportunities to redo something, I never make it mandatory. I want students to make their own decisions in these situations. More often than not, the ones who take advantage of it are the ones who got a decent score but wanted a really good grade, it’s not the ones who got a really bad grade. I know there is a life lesson in there somewhere but I can’t really articulate what it is. 
Full disclosure: Another reason I gave this extra period was that I wasn’t sure where I wanted to go next. I had purposefully left out that you can also run multiple live_loops at once. I felt that was too much to digest and required a bit more of an explanation. I also had further that I wanted to go just in running one thread at a time before getting into concurrency. I wanted to show them conditionals which seemed like it might connect to using variables, I wanted to talk about lists, arrays and rings to start incorporating concepts of scales and chords. I also wanted to show them samples and making drumbeats although that felt more like it would be a good springboard into multiple threads and concurrency so I figured I put that off for a bit. I was feeling at that point like conditionals were going to win out. They did.
Next week: Conditional Statements