1300 CSCI Homework 3: Song Generator
Read: About characters and strings: Zelle 4.1-4.3 About text files: 4.6.1-4.6.2 About conditionals: 7.1-7.3 Representing music. As weve seen, sounds can be represented by sequences of numbers representing air pressure measurements. But there is a much older practice of representing certain kinds of sound, music, in another way: as a sequence of notes. In this homework youll write a program that uses a representation of notes to specify music and generate sound from it. We wont be using real musical notation (the staff, notes with tails, and so on), but a simpler representation that uses just text. Well represent notes by letters, C,A,B, and so on, just as they are described when people talk about music. Well also use letters to represent the length of notes: whole note, half note, quarter note, and so on: W will stand for a whole note, H for a half note, Q for a quarter note, and E for an eighth note. In music, a whole note is played for some period of time, a half note for half as long, a quarter note for a quarter as long, and so on. Over the course of the assignment, you will work up from a program that can play a song like this scale: C D E F G A B c which has no length indications, and plays only one note at a time, to a program that can play this, in which there are two note chords, with different lengths. H CE Q DF Q EG H FA Q GB Q Ac H Bd Q ce
The format of this assignment is a little different from the first two. In those, I got you started by providing what I hoped were pretty complete plans for the programs you needed to write. You then exercised your understanding (I hope) by making additions and modifications on the basic plan. In this assignment Im going to move you towards self sufficiency (your ultimate goal) by providing less of a plan. Im still going to describe some of the pieces of work your program needs to do, and how to do them in Python, but youll need to do more of the planning. To provide some support, Ill be suggesting an order in which you can develop progressively more capable programs, in stages, so that you dont have to make a plan for the most complex, most capable program, all at once. Phase I. Playing single notes. This program is going to read a file like scale.txt (on the moodle; you may need to paste this into a .txt file if it doesnt download), that has these contents (and some more): C D E F G A B c For each note it is going to generate a corresponding tone, and its going to string these tones together, and put them in a WAV file. You can then play the WAV file to hear the music. You already know how to do parts of this. In particular, you know how to: string tones together, by concatenating lists of samples record samples in a WAV file
But there are other pieces you dont know how to do, other than perhaps getting some ideas from what you have read in Zelle. Piece: Reading information from a text file. As Zelle explains, getting information from a file involves opening the file and then reading from it. This code gets a file name from the user, and then tries to open the file: noteFileName=raw_input("What file are the notes in? ") noteFile=open(noteFileName,'r') Opening a file means asking the system to find the file (given its name) and getting it ready to be read from. In Python, when the system opens the file it gives you a kind of handle that you use to refer to the file. The assignment statement gives that handle the name noteFile, so you can refer to it later in the program. You might be thinking, why
dont we just use the file name to refer to it? Answer: As this example shows, we often dont know the file name when we write the program. Once you have opened the file, you can read from it in a number of ways, as Zelle explains. For our purpose where we want to process each line in the file, this code is the neatest way: for line in noteFile: #process line in some way In this loop, the body will be executed repeatedly, once with the variable line having as its value the first line in the file, then with line having as its value the second line in the file, then with line having as its value the third line of the file, and so on. (Note: Ive used the variable line: to make clear what is going on. But Python doesnt care what name you use for the variable. I could have written for eggplant in noteFile: #process eggplant in some way just as well. The variable eggplant would take on as its values each line in the file. Piece: Making a tone of a given frequency. tone=[10000*sin(i*freq*2*pi/44100) for i in range(int(LENGTH*44100))] This line generates samples for a tone LENGTH seconds long, with sample rate 44,100 samples per second, with pressures ranging from -10000 to +10000. A reasonable time for each line in the file would be 1 second, so you can set LENGTH to 1.0 near the beginning of your program. By the way, Ive written LENGTH in all caps to indicate that it is a constant: once its value it is set I dont intend to change it while the program runs, unlike typical variables. This is a common style that you should adopt, as it helps you and others to read your code. Piece: Recognizing letters and assigning frequency based on what letter you have. Here are the frequencies that corresponds to the letters that are used for notes: note letter R (a rest) C D E F frequency 0 (produces silence) 261.63 293.66 329.63 349.23
G A B c (lower case is an octave higher) d e
392.00 440.00 493.88 523.25 587.33 659.26
OK, you read a line from the file, and the note on it is (say) A. How do you get from there to the frequency? Heres how: if line[0]=="A": freq=440.00 This is a conditional, or if statement, described in Zelle 7.1-7.3. As Zelle explains, Python has a special keyword, that can be used to chain together a bunch of tests like this: if line[0]=="A": freq=440.00 elif line[0]=="B" freq=493.88 elif line[0]=="c" freq=523.25 and so on. Notice that we are checking line[0] and not line. Thats because line[0] is the first character in line, and line may have another character in it that we dont want to look for: the character that marks the end of the line. Putting the pieces together Here is an outline for this program: get file name open file song=[] #the empty list for line in file: a bunch of ifs to set freq tone=tone with that freq song=song+tone #concatenate the new tone onto the song record song as WAV
Q3.1. Write the program as described above, and test it using the file scale.txt. Does it work? If not, give the best description you can of the difficulties you had in making a working program. Phase II. Chords (Playing More Than One Note at a Time) This program is going to read a file like chords.txt, on the moodle (you may need to paste this into a .txt file if it doesnt download), that contains stuff like this: CE DF EG FA Here each line of the file can have more than one letter. Each letter represents a note in a chord, that is, tones corresponding to the different letters will be played at the same time. To do this you are going to generate tones corresponding to the different letters, as you did in Phase I, and you are going to mix these together to get the sound of the chord, and then you will string these sounds together, and record them as a WAV file. You already know how to mix two sounds, say s1 and s2, using a list comprehension like this: combinedSound=[s1[i] + s2[i] for i in range(len(s1))] But how are you going to control this, so that you add together as many tones as there are letters in a chord? Here is how. Piece: Building a chord. Lets use the variable line to stand for a line from the text file, containing (for example) CEG. As Zelle explains, a string of characters like this works in many ways like a list. In particular, I can write a for loop like this:
chord=int(LENGTH*SAMPLERATE)*[0]#line 1 for letter in line: #line 2 tone= the tone for that letter #line 3 chord=[chord[i]+tone[i] for i in range(int(LENGTH*SAMPLERATE)] #line 4
Line 1 starts chord off as silence. In the loop were going to be adding notes to the chord, so it makes sense to start it off with nothing in it, that is silence. By nothing we mean something that wont affect the sound we end up with. Line 2 causes the statements in the body of the loop (Lines 2 and 3) to be executed repeatedly, with the variable letter taking on the different values in line. If line is CEG
the loop will be executed three times, once with letter having the value C, once with letter having the value E, and then with letter having the value G. Line 3 you can take with very little change from your Phase I program: there you worked out how to generate a tone of a frequency that corresponds to a letter. Actually, Line 3 wont be one line, itll be several, with ifs and elifs, as you used for this purpose in Phase I. But theyll all be in the body of the loop at the indicated point. Note: Theres a subtle problem at this point (I missed it when I first wrote this program for the notes). The string line will probably contain an extra letter at the end, a character that represents the carriage return at the end of the line. There are different ways to process that extra letter. You could try removing it from line before your process line, but its a little tricky to do that, because its not always there. Another approach is not to remove it, but just to give freq the value zero for any letter that doesnt represent a note. When freq is zero, you get silence, so this means any stray letters will not mess up your chord. To do this, add this at the end of your big sequence of elifs: else: freq=0 As Zelle explains, the code following the else will be executed if none of the tests is satisfied. This is just what we want, since it means the letter isnt any of those we have checked for. Line 4 adds the note we are processing to the chord weve built up so far. If there is just one letter on the line, the chord will just have silence and a tone of the frequency corresponding to that letter in it. If there are two letters, we go through the loop twice, and the chord will be silence plus the first tone plus the second tone, so that it really is a chord. A nice thing about this loop is that it doesnt matter how many letters there are on the line: the tones corresponding to each of the letters will be added into the chord. A note about the number of notes in a chord. The file chords.txt has only two notes on each line. If you follow the suggestions above, your program will work regardless of how many notes there are in a chord. You should aim for this! Its actually easier to write a program that works for any number of notes in a chord than to write one that only works for (say) two notes. At some point well discuss this seemingly paradoxical, but pleasant, fact. A note about amplitude. As we saw in Homework 1, when sounds are added the amplitudes (the size of the pressure measurements) get big, and they can get too big to record in our WAV file. If you are going to process chords with three notes, you want the amplitude of each tone to be something like 5000, so that you wont get overflow, this as its called. If you create a text file with as many as five letters on a line, which will generate chords with five notes added, youll have to use an even smaller amplitude. Piece: Stringing the chords together.
This isnt really a new piece: you can use the same loop over the lines in the text file as you used in your Phase 1 program. Its only what you do with each line thats different. In Phase I each line has just one letter, so you just generate that tone and stick it onto the end of the song. In Phase II each line may have more than one letter, so you use the loop we just discussed to generate the chord, and then you stick it onto the end of the song exactly as you did in Phase I. What youll end up with is called nested loops: The loop we just discussed, that loops over the letters in a line, is in the body of the loop copied from Phase I, that loops over the lines in the file. Schematically: loop over lines: loop over letters in a line: process the letter In a little more detail: song=[] loop over lines: chord=silence loop over letters in a line: generate tone for letter chord = mix of chord and tone song=song+chord Here mix of chord and tone means our way of adding corresponding samples of two sounds so that the resulting sound is that of playing the two parts at the same time. Q3.2. Write the Phase II program as described, and test it on file chords.txt. Does it work? If not, give the best description you can of the difficulties you had in making a working program. The accumulation plan. This program has two uses of a common programming plan called the accumulation plan or the running total plan. A programming plan is a pattern of code that shows up over and over again in different problems. Knowing common plans is a big work saver: you dont have to invent a new solution to each new problem, if you can use a familiar programming plan. The simplest example of the accumulation plan is used for adding numbers, which is why the plan is sometimes called the running total plan. If I am given a list of numbers to add, I can do it this way: total=0 for n in list: total=total+n
You can see that what is happening is that we start our total out at zero, when we havent processed any numbers yet, and then we loop through the numbers in the list, adding each one on to the running total. Suppose we want the product of the numbers in a list rather than the sum. Take a minute to try to do that, before reading on. Heres how: product=1 for n in list: product=product*n Can you see that this is really the same pattern, or plan, as the running total? You just change two things, the operation you use in processing each element in the list (* instead of +) and (maybe a little more subtle) you have to start product out at 1 instead of 0. (Why? Because 0 is the identity for addition, and 1 is the identity for multiplication. By starting with the identity, we are not influencing the final result.) Can you see the two instances of the accumulation plan in the code outline in the previous section? One, that also showed up in Phase I, is the one that builds up the song from the separate chords. We start song out as the empty list, and then we concatenate each tone onto it. We started with the empty list, because the empty list is the identity for concatenation, just as 0 is the identity for addition. The second instance of the accumulation plan is the loop that builds up the chords from the separate notes. We start chord out as silence, and then we add, or mix, each tone into chord. We start chord out as silence, because silence is the identity for mixing tones. Q3.3. Write a program that finds the sum of the numbers from 0 to 9. What answer do you get? Phase III. Adding lengths for the notes. Once you have your Phase II program working, go on and create a program that can process a file like rhythm.txt, on the moodle (you may need to paste this into a .txt file if it doesnt download). The lines in this file each look like this: Q CEG Here the first letter is a length indicator, as explained at the beginning of the assignment, then there is a space, and then there is one or more letter making either a single tone or a chord. Notice that after the space each line is just like a line your Phase II program processed.
Your Phase III program will be very similar to your Phase II program. There are just two new things you need to know how to do. Piece: Processing the length indicator. Suppose line is a line in the file, like Q CEG. Because a string is much like a list, you can use an index to pick out the first letter: line[0] will be the length indicator. So you can write code like this: if line[0]==W: length=LENGTH elif line[0]==H: length=LENGTH/2 and so on for Q (quarter notes) and E (eighth notes). Here we are setting the variable length to contain the number of samples needed for a whole note, a half note, a quarter note, or an eighth notes. You will then use length, rather than LENGTH, when you generate your tones. Apart from changing LENGTH to length, nothing else in your code from Phase II that generates the chords and sticks them onto the song needs to change, if you use the following piece. Piece: Isolating the chord so you can generate it as you did in Phase II. You already have code for generating a chord, given a string like CEG. Youve got a string like Q CEG. If you can extract just the CEG part from this, you can process that part just as you did in Phase II. Because strings are so much like lists, you can use the slice idea for this: line=line[2:] Here we are creating a slice with just one number, not two as we used before. The first number gives the index with which the slice should start. When we leave out the second number the slice runs to the end of the string, which is what we want. Heres where this line fits into the overall structure of our code: song=[] loop over lines: set length based on line[0] set line to line[2:] chord=silence loop over letters in line: generate tone for letter using length chord = mix of chord and tone song=song+chord
See how this works? The assignment line=line[2:] strips off the first two characters, the length specifier (Q, in the example), and the space, and leaves just the chord (CEG in the example.) With the extra stuff stripped off, we can process line exactly as before (apart from changing the length of the tones in the chord by using length rather than LENGTH.) Q3.4. Write a program as described, and test it for the file rhythm.txt (on the moodle, and an attachment to a message on the forum). Does it work? If not, give the best description you can of the difficulties you had in making a working program. Reflections on representations in these programs. These programs illustrate again the layered nature of representations. We are using musical notes, represented by letters, that represent sequences of samples, that represent sounds. A couple of new points about this, as compared to the representations weve been using. (1) We see in this program that computational stuff can include things other than numbers, letters in this case. (2) Up to now our representations have had a physical basis: louder sound, bigger pressure swings, bigger numbers. Thats physics (and whats called psychophysics, the study of how things like loudness or pitch are perceived.). We cant say, Lets have bigger pressure swings represent softer sounds. But in the programs here we are using representations that are conventional, not physical. Its just a convention that the letter A represents a tone with frequency 440.00 Hz. Other cultures dont represent notes that way. As youve seen, theres no problem using conventional representations in a computational representation. It would be trivial to change these programs to use different letters to represent the notes. This is a strength of computational representations: we can easily automate essentially arbitrary mappings between representations. If statements are key to this: they allow us to associate pretty much anything to anything, by using a sequence of ifs. Files and persistence. What are files all about? Much information in a computer is volatile: it goes away when the program using it stops running (think of alcohol evaporating). To make information stay around you have to store it in a file. The file is the part of the computers memory that doesnt go away. Information that doesnt go away is called persistent. Some computer scientists argue that we should be able to make any information persistent, just by marking it persistent, rather than having to use files as a special mechanism for saving it (see Wikipedia to read about this idea). But no mainstream programming language yet fully supports this idea, though some are approaching it. Further work.
Do any of these that interest you. If you are interested, you can volunteer to show your work when we go over the assignment. Compose a nice song in the form of a txt file for your Phase I, II, or III programs. All of our notes here are represented by pure tones, but real musical instruments produce complex sounds. Record notes played by a real instrument, and modify one or more of the programs to use these rather than pure tones. Or read about music synthesis, and see if you can make the program generate more realistic tones. Garage Band and Hyperscore are music editing systems. Read about them and compare their approaches to representing and manipulating music. It would be possible to make our programs produce a picture of a song using conventional music notation, on a staff. Do this, or think about how it could be done. You could also make a song editor that would let you compose a song in conventional music notation, and then translate it into the text file representation our program uses. Our programs dont handle sharps and flats, or dotted notes. Add one of these features. What to turn in, and how. Submit a single Python program ( a .py file)to the moodle, using the submitter for Homework 3, that contains the following: (A) Your Phase III program. If you werent able to complete Phase III, submit the most advanced version of the program you were able to write. Then include the following additional material in the same file, as comments. You can make part of a .py file into a comment easily using the comment out region on the Format menu in IDLE, or you can put three double quotes before and after the material you want to make into a comment. (Making something a comment is often called commenting it out, because when you run the program the system acts like the comment material isnt there.) (B) Your BRIEF answers to question Q3.1-3.4 (C) A program that includes anything you did for the further work. Yes, this should be in a comment. The idea is that the TA can run the file you submit to test your program for Q2.9. If they want to test your other program they will comment out the first program and comment in the second one. (D) A statement of when you began work on the assignment, how much time you spent on the reading, and how much time you spent programming, and any other work you did and how much time you spent on it.