It’s the last day of my summer break, so I thought I’d take some time to reflect on my live coding experiment. After all, this was meant to be a learning experience and self-reflection is an integral part of the learning cycle.
How’d I do?
I ended up streaming for approximately 16 hours over 8 different sessions. I then edited the live footage down to about 95 minutes of time-lapsed video. Truth be told, I had expected to stream more often but kind of got side-tracked after going to see the Overwatch League Grand Finals live in Brooklyn. I know it might not seem relevant now, but I’ll come back to that in a bit.
Was it “fun”?
It had it’s fun moments, like hearing my first composition come together, hearing my first randomized chord progressions, and remixing a recorded sample. There were some moments of genuine excitement recorded here! It’s amazing when things finally come together to produce something new and different. However, there were also hours of work going into each of those moments. Around this moment is where I realized that my “mathematical function” approach wasn’t going to be fast enough in Python to do what I wanted in real time. I even ended up spending an entire episode just debugging my previous work. I’m also still kind of uncomfortable with the whole camera situation, so I’m doing all this is a state of perpetual social anxiety. That part of the experience was slightly less fun… Overall, I’d say it was about 20%”fun” to 80% “work” and that’s probably what kept me from a more active streaming schedule.
What did I learn?
The first observation I made is that I have a lot of little sub-conscious behaviors I do when I’m deep in thought. There were lots of “umm”s, whistling, tapping, and beard stroking that I didn’t really notice until I was going back through and editing the videos. It makes me wonder how often I do these things in the classroom. I’m pretty sure I’ve been called out on the beard stroking by students before — it helps me think! I also found it difficult to narrate my thought processes while in this state. It’s like I needed to separate the act of thinking about the code from the act of describing it verbally.
Math-wise, I discovered that I had a lot to learn about digital signal processing. I had started exploring these sounds by thinking of them using real valued functions, but eventually learned that the floating point approximations I was actually using were introducing small rounding errors which quickly added up to audible artifacts. Fixing that issue required me to be more aware of the differences between discrete and analog signals. I started reading up on DSP in my off-stream time and am now starting to think that there are ways to dramatically simplify some of the things I was original trying to do. It will probably be some time before that research pays off, but at least now I know where to look.
I also realized that the approach I took to generate my randomized chord progressions is actually a well established procedure called a Markov Chain. This is one of the amazing things about studying math — you can independently come up with an idea on how to do something only to realize that someone else came up with the same idea a hundred years before you. Like my DSP observation, this has opened my eyes towards mountains of existing research on this approach.
How will this impact my teaching?
I think this has given me some new respect for creative assignments. I had been so focused on aligning assignments to standards that perhaps I underestimated the amount of connections between those standards and creative activities. Furthermore, the announcement that Desmos will be available on the upcoming SOL tests has given me a solid reason to devote substantially more time to using it in class. I want to make “Desmos artwork assignments” a regular occurrence over the upcoming year. My hope is that I can construct the assignments in such a way that will generate authentic curiosity about the topics we’ll be learning about in Geometry in the same way that this project inspired me.
Where do I go from here?
I’m not going to abandon the project, but I think there’s some serious “re-conceptualizing” I need to do in order to continue. Honestly, I wouldn’t want to watch me live code based on the present quality of my stream. There’s just too much inactive time. If I’m going to live stream, I want to do it in a way that’s more engaging. To do so, I think I need to talk some cues from all the Overwatch streams I watched this summer.
I’ve been watching a great deal of Kabaji’s Twitch stream, and am thoroughly impressed by his ability to narrate what he’s doing and why throughout the stream. Not only that, but he manages to be constantly engaging the members of Twitch chat between fights. I think those are the two things that I need to work on to make this “LiveCode” more successful in the long run.
First, I think I need to rehearse what’s going to happen in the stream before going live. This will let me cut down on the number of bugs that I need to track down, the time I spend reading documentation, and will allow me to put more focus on narrating as I code. Alternatively, I could separate the coding and narration aspects into two different streams — one where I write the code and one where I “cast” over it with commentary later.
Second, I need to come up with a way to involve Twitch chat in the production process. I’ve already done a bit of research in this direction, and think it’s possible for me to connect my Python session to Twitch chat server. This would help me from getting tunnel vision and I could use data from the chat to influence the music production.
Despite these goals, the new school year is starting soon and that means a lot less time for a side project like this. If I do continue these live streams, it will probably be a much sparser schedule than I tried to do in July. Follow me on Twitch for notifications when I go live!