Assigned Date: Wednesday, Sep. 29
Due Date: Friday, Oct. 8
Due Time: 30 mins before class
Write a Jython program that generates an interesting piece of percussive music.
The piece should last between 30 secs to one minute, but longer pieces are OK (as long as they continue to be interesting throughout).
The piece should contain at least three Parts (with at least three different percussive instruments).
It should use several Mod functions, for economy and smart design of the piece.
It should be your own piece (preferable), but you could transcribe an existing piece (lesser).
The idea here is that your piece should “hook” us by following such an interest curve… in terms of:
- Items you introduce and when, or
- Items you remove and when, e.g.,
- sudden silence can be attention grabbing…, or simply
- taking some thing(s) away, only to re-introduce them later (same or altered somehow)), etc.
- It is OK to have a hooking melody (e.g., a bass line?), but if so, it should be short, and not the emphasis of the piece
- The emphasis of the piece is rhythmic material, and the different percussive instruments used to deliver it
- You can combine different rhythms (see more on polyrhythms here and also here – this is really cool and attention grabbing stuff!!!
- Experiment – it’s so easy with JythonMusic!!! Play with different time / rhythm subdivisions (2, 3, 5, 7)…
- See what sounds good – and keep it for your arsenal on your napkin…
- It is OK to use both channel 9 sounds, and regular percussive MIDI instruments – just remember to put them in different parts and assign different channels to them.
Here are four “random” examples of percussive pieces. Notice how they succeed (or fail) to build interest. Can you graph (on a napkin – preferably with pizza stains) the interest curve of each piece? Notate what causes the interest to rise at different parts of the piece.
Can you learn from them, and replicate the interest grabbing technique (without necessarily reusing the exact same material)?
- Example 1 (Japanese Kumi-daiko)
- Example 2 (John Cage’s “Third Construction”)
- Example 3 (Max Roach‘s “The Drum Also Waltzes”), and
- Example 4 (by MorningLightMusic – generic rhythmic pieces for “hire”…)
Now, having seen these examples, you should be able to begin creating something interesting of your own.
Start on a paper napkin (yes, preferably with pizza stains…). You will submit it too, so start here.
Draw the interest curve of the piece you are creating. How are you going to achieve these changes in interest (add something, subtract something)?
What instruments will you use?
What rhythms will they play?
Design, design, design – think and make decisions on paper first. Code later. Return back to paper often. Do NOT think in code… think on paper.
Always remember the adage –
“20 hours of coding can save you two hours of design”
Don’t waste your time coding. Think on paper, then code. Code precisely and only what you want. It is OK to experiment a little, but then return back to paper… until you know what you are doing. Then code. Cycle this, back-and-forth… between paper and code. It will save tremendous amounts of time… and produce something much, much better. Trust me.
Do all three:
- Upload a photo of your paper design for your piece (it should show the interest curve and describe in words what elements are added, and where… and why). We should be able to see the structure of the piece and your choices by looking at this page.
- Upload your program file on OAKS.
- Be ready to perform it in class, on the due date.
Your program should have a meaningful name, e.g., stairwayToHeaven.py.
Follow the documentation instructions from Homework 1. In particular, your header documentation should:
- mention the name of the piece and the composer / band where it comes from, and,
- if you used a score available online, include the URL where the score can be found.
Remember, the Golden Rule of Style: “A program should be as easy for a human being to read and understand as it is for a computer to execute.”  Your code should have general comments at the top, which explain what the program does. You should comment all variables, obscure statements, and blocks of code.
Follow the textbook examples on how to write comments.
Your grade will be based on how well you followed the above instructions, and the depth/quality of your work.
- Cooper, D. and Clancy, M. (1985) “Oh! Pascal”, 2nd ed., W.W. Norton & Company, New York, p. 42.