In 2008, I was hired to teach on the music faculty at Texas A & M – Commerce. Great job. Great people there. On my contract, the final sentence said “other duties as assigned,” and one of those dates ended up being a music technology course. I had no experience teaching a class like that and no formal training in a class like that, but that didn’t change the fact that I was going to teach it. So, I got started on figuring out how to do that and not feel like an idiot in the process.
The first step was to find an existing syllabus, of which there was none to be found. The next step was to ask the faculty what had been covered in the class in the past, which nobody really knew (this is not uncommon). There was a textbook that had been used, but it was not geared towards the population of students I was going to be teaching (according to my boss….and he wasn’t wrong). So, the next logical step was to get a sense from the faculty (and my bosses) what they would like me to cover in the course.
What I got was a laundry list of softwares and technologies students should be able to know, many of which were incredibly outdated or not relevant to the entire class. For example, being able to use a drill writing software like Pyware or EnVision is not going to be a meaningful exercise for people who intent to teach choir, orchestra, elementary, or middle school. It is also a really difficult to learn, because it requires knowledge in other areas besides just how to operate the software. This left me with these questions to resolve:
- What softwares and skills are transferable across all students in the class?
- What can we reasonably expect students to be able to know and be able to do within the confines of the semester and technological resources available.
- What kinds of activities and assessments can we create to achieve these goals?
The result was a series of projects that centered on 3 main areas of being a music teacher and how technology could be used to serve them. Those areas were teaching, creativity, and administration. Projects were designed to scaffold learners in a way that not only helped them gain knowledge and understanding of software, but how to leverage those skills against their own interests to create new knowledge and digital fluency. Some projects were the same across degree tracks (choral, instrumental, general music, etc), while others were specific to each tracks. Examples of projects that remained consistent across tracks included the missing part assignment and the digital audio assignments, while some of the projects that bifurcated were the orchestration projects and the final projects.
The result was something unexpected. Students got really into the projects and we all ended up helping each other learn together. Eventually I became the most knowledge person in the room with respect to the various technologies, but we never stopped learning together. With each passing year, I found that the more interesting and authentic assignments were and the more they allowed for students’ interests and creativity to come out, the more wonderful the projects became.
Years later, I came to understand that this approach was known as Problem Based Learning (PBL) and Authentic Context Learning (ACL). These approaches have become huge interests of mine across all domains of learning and have had some wonderful experiences in classes that use them in areas like the Applied Statistics program at Penn State. Now, as I finish my PhD in the time of Covid-19, I see the importance of creating meaningful projects that students and teachers can both learn from to increase engagement and understanding. Below are some examples of projects I have developed in the past for any of those that are interested:
Music Notation Projects:
Digital Audio Projects:
- Recording & Editing Project
- Digital Audio Transformation Project
- Composing & Creating with Digital Audio Workstations
The Data Runner 