Assignment 2
In the second assignment, you’ll be working with your team to translate about two minutes of written music into sound.
The class is working on Mozart’s String Quartet in G Major, K.387. Each team has one line of the composition (Violin I, Violin II, Viola, Cello). You are only responsible for the first 56 measures of the piece (up to the "repeat").
Each team has been assigned one of the four lines. Your team should already know what line they’re working on.
Your program, when run, should define song-part to be an rsound representing the given line of music. Your program should not play any sound; rather, calling (play song-part) in the interactions window should play back the sound.
Your program should define a global constant called tempo that controls the tempo of the generated piece. So, for instance, if I change tempo to 184 and run your program, your song-part should now contain a 184-beats-per-minute version of the music.
You may use any tone generator that you like; the synth-note function will work well, but you’re also welcome to use others, or to create tones by layering existing tones and possibly altering their pitches slightly.
1 Abstraction
One way to write this assignment would be to simply rs-append a sequence of hundreds of notes. I’m hopeful that you won’t do this.
Specifically, I’m hoping that as you start on this process, you notice that there are certain repeated pieces of code, and that you define functions to eliminate this repeated code.
To begin with, it should certainly be the case that you define functions for tone generation, so that if you decide you want to change the tone of the generated piece, you can do that in one place, and not have to change hundreds of sites in the code.
A more sophisticated use of abstraction would be to notice repeated forms in the music. These may be rhythmic—there are a lot of sequences of four sixteenth notes—or melodic—perhaps it’s very common for ‘c’ to follow ‘d’.
There are one or two places in some of the lines where whole measures are repeated; these are easy to define once and use multiple times.
2 Design Recipe
When you design functions, follow the design recipe: think about what kind of data each function consumes and produces, write down a signature, purpose statement, and header, write test cases, and only then should you implement the function.
I will deduct points from assignments that are not clear and easy to read, and that do not include purpose statements, signatures, and test cases.
3 Team Work
The best teams will work effectively together. This means communicating! You should make a plan, and make sure that everyone knows what it is. If you’re having trouble with a part of the project, let your team know! Keeping everyone in the loop is the best way to avoid problems. This project is a warm-up for the final project, so now’s the time to get things ironed out. Arrange a meeting time as soon as possible!
Also, I will be asking you later on in the quarter to assess the contribution of each of your teammates to the project, so make sure that you’re responsible for your parts of the project.
4 Final Submission
For this project, you should submit a single racket file called "a2.rkt" to a polylearn handin bin that I’ll be creating.
Your program file should contain a one-paragraph write-up, in the form of a comment. Describe your ideas and your process, and the state of the program.
As before, only one team member needs to submit to PolyLearn.
5 Grading Rubric
The grading for this assignment will be as follows:
5 PolyLearn bundle handed in
4 Correctness: generates the right music at the right tempo
4 Data definition quality
5 Coherent and legible code
4 coherent and legible paragraph
6 Help!
If you need help, I strongly advise you to post to the Piazza group rather than contacting me directly: I’ll respond to both, and that way others can see your questions. Often, you’ll get a good answer more quickly from someone other than me.
7 Sharing Code
Naturally, you’ll be sharing all of your code with the rest of your team. There are a number of nifty ways to do that, including GitHub and other public repo tools.
Beyond that, though, you’re welcome to use other teams’ code, with proper attribution. So if the PowerSheep come up with a really cool sound, it’s fine with me if you use it in your program, indicating the chunk of code that came from the PowerSheep.