This class is "about" several things all at once.
First and foremost, the goal is to learn the fundamentals of programming.
Second and almost as foremost, the goal is to create some interesting pieces of music and musical programs.
The hidden agenda of the class is to make you fall in love with
the ability to translate thoughts into reality—
Students entering this class are expected to understand algebra, trigonometry, and some very basic physics ("what is sound?") and calculus ("what is a derivative?").
Students in this class are not expected to know how to program. Students that have programming experience are also welcome and important; you will be a great asset to your teams.
John Clements, aoeuclements @ brinckerhoff.org
Lecture: 10:00-10:50, MWF, room 192-242
Lab: 11:00-11:50, MWF, room 14-303
See my Contact Info page for my calendar. You can add it to your calendar, if that makes your life easier.
Office hours also appear on this calendar; you may find them easier to see if you click on the "week" tab of the calendar.
This is the course web page, its link is http://www.brinckerhoff.org/clements/2158-cpe123.
I think that an interactive and lively classroom is a better learning environment. In particular, I will almost certainly learn everyone’s name, and I’m likely to notice if you’re missing. My experience is that if you come to class reliably, you’re extremely likely to pass the class—there’s a reason that we conduct classes face-to-face; it keeps you engaged, and ensures that you’re connected to the other students in the class.
In addition, I’m likely to call on you, in places during the lecture where I want to see if you’re following what’s going on. If you don’t know, it’s totally fine to say "no, I have no idea." In particular, this is probably evidence that I’m going too fast or not explaining things well. However, I try to respect the wishes of students for whom this technique is disruptive. Please let me know if you don’t want me to call on you.
Finally, my experience standing in front of classes and more especially my experience of sitting behind classes has convinced me that laptops are useful for note-taking in approximately 1% of cases. Essentially, never. In addition, some studies suggest that longhand notes on paper are significantly more useful than even careful laptop notes, and other studies illustrate how distracting laptops can be to those around you.
For this reason, I do not allow the use of laptops in class without special dispensation. If you need to use a laptop to take notes, please come and talk to me; otherwise, just put it away and take notes on paper.
You will be required to complete the assignments in this class using PLT Racket, version 6.2.1 (or a newer version). It is freely available for all major platforms, including Mac OS, Windows, and UNIX.
It is pre-installed on the lab machines. Follow the instructions given in Lab 1 to install the rsound package.
I’ve made a small number of YouTube videos, illustrating some basic DrRacket skills. These are online at
Every student will be required to maintain an online "portfolio" page, highlighting his or her work on the projects that each team carries out.
The recommended (a.k.a. simplest) way to get such a portfolio page is to use Google Sites, at http://sites.google.com. This will require you to have a google login, which should be free if you don’t already have one.
You’re welcome to build your portfolio page in some other way, if you like.
Your portfolio pages must be public, and you need to submit the URL to the Portfolio URL form .
This class does have a required textbook, but you will read it online, so no purchase is required. The book is called How To Design Programs, 2e. If this site is down, there’s a (possibly slightly outdated) mirror available here.
In addition to this book, there are a number of good books on sound manipulation. These are strictly optional, if you find that you want more information on a particular topic.
The Computer Music Tutorial, by Curtis Roads, has a nice high-level introduction to most of the advances of the last fifty years in digital music and sound processing.
Musimathics, Vol. 1, Gareth Loy
Musimathics, Vol. 2, Gareth Loy
This class will use Piazza. This will be the principal means that I’ll use to notify you of deadlines, organizational updates, and changes to assignments. If you’re not keeping up with the group, you’re going to be missing important information.
It’s also the best way for you to direct questions to me and/or the class. Feel free to e-mail me with personal questions, but use the Piazza group as your main means of communication. It’s possible to post anonymously, if you like.
You should already have received an invitation to the Piazza group; let me know if you need an invite.
Don’t post your code or test cases to the group; anything else is fair game.
Also, please keep in mind that I (and everyone else) judge you based in part on your written communication. Spelling, complete sentences, and evidence of forethought are important in all of your posts & e-mails. One easy rule of thumb: just read over what you’ve written before clicking post or send, and imagine others in the class reading it.
I encourage collaboration with your team members—
On the projects, you will be working together on a piece of code, and it is not necessary to indicate which team member wrote which parts of the code. If you get code from other teams, you must acknowledge this in the code. For instance, you might write a one-line comment like "This function adapted from one written by the Scabrous Crabs."
When doing labs, the code you write must be your own. It’s fine for your team members (or anyone else) to read over your shoulder and give you advice, but you must write the code yourself.
Naturally, quizzes and exams must be entirely your own work.
Labs in this course take the form of simple exercises to be completed in a week during lab periods, designed to help you understand the lecture material and to lead you toward solutions for the larger assignments.
I’ll be checking these off during the lab; you’re responsible for demo-ing your lab solutions for me. Your marks on these labs will be simple credit/no-credit.
The labs will be due at the end of your lab period on the last day of the week, typically Friday. If we run out of time to check them, I will generally elect to accept them on Monday as well, but you cannot rely on this occurrence; the labs are due on Friday.
When you successfully demonstrate a lab, I will give you a number. You may enter these numbers at http://desmond.brinckerhoff.org:8026/servlets/standalone.rkt .
My experience suggests that frequent quizzes are a good way to ensure that you’re understanding what I’m teaching, and that I’m teaching things that you understand.
This class will have quizzes on Wednesday of weeks 2, 4, and 8. These quizzes will probably be twenty minutes long, and will probably take place during lab.
There will be a midterm and a final exam in the course. The midterm will be during the lecture period on Wednesday, October 29th, in the sixth week of class. The quizzes and exams will be closed-note. No electronic devices, including calculators, phones, or mp3 players, will be permitted during the quizzes and exams.
Before the final project, there will be two smaller projects with more constrained parameters. Unless otherwise specified, these projects will be due at 11 pm on the day specified in the schedule.
a music tool that you can use to mix and/or perform music, or
a single piece of music.
On this project:
You will work in teams. The team size will be around 4, but will depend on the number of students in the class.
- There are four milestones associated with your project (see below).
You will demonstrate your project in class and lab during the last week of the quarter (we’ll signup for times). Your project must be working by this point or everyone in the group will receive 0 points for the entire project.
Each member of the group will be questioned, in person, about various aspects of the project and will be assigned individual grades based on their answers.
Each member of the group will provide an assessment of every other member in the group.
Each member of the group must submit weekly progress reports (due every Friday). Students may also use this report to inform me of any group related issues. Progress reports will affect each member’s final project grade.
Milestone #1: Oct 27th, 3% of final grade
Milestone #2: Nov 7th, 3% of final grade
Milestone #3: Nov 21st, 3% of final grade
Milestone #4: Dec 5th, 21% of final grade
Grades will be determined by performance on programming projects, the exams, and class interaction. The breakdown of the grade is as follows:
Midterm Exam: 10%
Final Exam: 15%
Late Policy: Except for exceptional circumstances, late assignments will be given 0 points.
Schedule & Assignments appear here. (There’s also a link at the top of the page.)