Course Description:
Intended principally for doctoral students in music composition but open to others by permission. The course presents a practical overview of both classical and state-of-the-art techniques for computer music including digital synthesis, signal processing and sound manipulation, analysis and resynthesis, spatialization, and real-time and/or interactive applications. Students will produce several short studio projects as well as one larger piece to be presented in a final concert.
Below is a listing of assignments for Music 620.
1) Read the attached article by Jean-Claude Risset, "Computer Music, Why? It covers some of the general ideas and trends we discussed today as well as many of Risset's best works. I would encourage you to listen to these pieces, especially:
A) Songes, library CD 14870
-- this disk also includes Computer suite from Little boy and Sud
B) Oscura, in the studio /snd/sflib/listening as risset_oscura.wav
-- "lsfl listening" shows the contents, "psfl risset_oscura.wav" plays the file
C) "Historical CD of digital sound synthesis", library CD 14926
-- Risset refers to this collection from time to time. There is much to be explored here, a resource to revisit throughout the semester
We will listen to an additional work together next week, the 8-channel version of Resonant Sound Spaces, also mentioned in the attached article.
2) After your lesson with me, please produce 3 short Score11/Csound examples using the additive synthesis instruments marimba, carillon, or celeste mention in class. Review your Documentation as a reminder of how to use the system.
Related resources:
1) Create a classical "tap delay" structure in PD. All of the objects required for this patch can be found in the attached document, "delay_requirements.pd". You may also wish to refer to the PD "Help" browser found in the help menu, especially "3.audio.exmaples/GO2.delay.loop.pd". Please download the PD-extended application for your operating system from this site:
2) Read "Though the Sensory Looking Glass: The Aesthetic and Serial Foundations of Gesang der Jünglinge" in hard-copy in B27 in B27 discussing Stockhausen's "Gesang...". It can also be found through JSTOR here:
You may also wish to review the attached PDF by John Smalley, a more condensed and rather introductory essay.
Looking toward your mid-semester project and performance, begin direct work in the form of a "study/etude". This can be an exploration of a technique or of a musical idea or concept. It may well be that your musical idea is ahead of your technical capacity. Please be sure to see me and discuss your intentions so I can help you find the necessary tools (perhaps beyond those we have looked at together).
All documentation below can be accessed in hard copy within Studios A and B (B27 amd B35B). Online documentation often contains additional resources such as video demonstrations and tutorials. Feel free to supplement this existing information with a Google search, particularily when the question relates to unfamiliar terminologies or technical details. Or post your question directly to the forums where other students are probably lurking and wondering the same thing.
Note: All unix commands take the basic form:
command file (where “file” is the file to execute “command” upon)
Or more generically:
command argument1 argument2 [argument3]
ls lists current directory contents
ls -l long listing (owner, permissions, size, etc) – add “-h” for human readable sizes
ls -a list all, including those files that start with a dot (.).
pwd print working directory
mkdir [directory name] create a subdirectory
cd change working directory
- cd [directory name]
- cd .. moves up 1 directory level
- cd - toggles back to previous directory
cp copy a file
- cp [filename1] [filename2] (-R does recursive copy of all subdirectiries)
mv move (or rename) a file
- mv [filename1] [filename2]
less view a file one page at a time, advance pages with SPACE
less [filename] or less [filename]
rm remove (delete) a file (Note: there is no “undo”)
- rm [filename] (-r does recursive removal...useful, but be CAREFUL)
rmdir [directory name] note: the directory has to be empty
cat view the contents of a file (or better, “output” its contents), concatinate
> redirect output to a new file
cat [file1] [file2] > [newfile]
>> adds or “appends” to an existing file
cat [file1] [file2] [file3] >> temp_file
| Pipe, allows you to pass the results (stdout) of a command to another command
- ls | more
history shown a list of previously executed commands (-h for no command numbers)
!! run previous command in history (also “up-arrow”) number in history
!# run command from “history” where “#” is the command number
* wild card used to stand for “all”
- ls *.txt list all files with the extension .txt
Soundfile directory commands (SFDIR)
lsf lists current soundfile directory contents
lsf -l long listing (owner, permissions, size, etc)s
pwdsf print working directory
mkdirsf [directory name] create a subdirectory
cdsf change working directory
- cdsf [directory name]
- cdsf .. moves up 1 directory level (or “../../” for up two, etc)
- cdsf - toggles to previous directory (like “Back” in a browser)
cpsf copy a file
cpsf [filename1] [filename2] (-R does recursive copy of all subdirectiries)
mvsf move (and/or rename) a file
- mvsf [filename1] [filename2]
rmsf remove (erase) a file
- rmsf [filename] (-r does recursive removal...useful, but be CAREFUL)
rmdirsf [directory name] note: the directory has to be empty
play (p) play a soundfile or soundfiles in your current working directory
- p soundfile1.wav [soundfile-n.wav]
sfinfo view information about a soundfile in your current directory
- sfinfo soundfile1.wav [soundfile-n.wav]
playsflib(psfl) play a soundfile from the soundfile directories
- psfl fl.c4.wav
findsflib search the soundfile directory by character string
- findsflib character_string
findsflib -p search the soundfile directory by character string and play them as they are found
- findsflib -p character_string
CEMC specific commands (more to come)
lsex list available tutorial examples
getex obtain a copy of a tutorial example
- getex tutorial1 > mytutorial1
lstp list available templates (blank examples)
gettp obtain a copy of a template (blank examples)
cemchelp view available help files and read file designated by argument
cs shortcut to “csound”
- cs orc sout (compile files “orc” and “sout” with Csound
ssgdig shortcut for ssh access to "digital.music.cornell.edu"
ssgdev shortcut for ssh access to "devel.music.cornell.edu"
by Barry Vercoe, Massachusetts Institute of Technology
The Orchestra File
Csound runs from two basic files: an orchestra file and a score file. The orchestra file is a set of instruments that tell the computer how to synthesize sound; the score file tells the computer when. An instrument is a collection of modular statements which either generate or modify a signal; signals are represented by symbols, which can be "patched" from one module to another. For example, the following two statements will generate a 440 Hz sine tone and send it to an output channel:
asig oscil 10000, 440, 1
out asig
The first line sets up an oscillator whose controlling inputs are an amplitude of 10000, a frequency of 440 Hz, and a waveform number, and whose output is the audio signal asig. The second line takes the signal asig and sends it to an (implicit) output channel. The two may be encased in another pair of statements that identify the instrument as a whole:
instr 1
asig oscil 10000, 440, 1
out asig
endin
In general, an orchestra statement in Csound consists of an action symbol followed by a set of input variables and preceded by a result symbol. Its action is to process the inputs and deposit the result where told. The meaning of the input variables depends on the action requested. The 10000 above is interpreted as an amplitude value because it occupies the first input slot of an oscil unit; 440 signifies a frequency in Hertz because that is how an oscil unit interprets its second input argument; the waveform number is taken to point indirectly to a stored function table, and before we invoke this instrument in a score we must fill function table #1 with some waveform.
The output of Csound computation is not a real audio signal, but a stream of numbers which describe such a signal. When written onto a sound file these can later be converted to sound by an independent program; for now, we will think of variables such as asig as tangible audio signals.
Let us now add some extra features to this instrument. First, we will allow the pitch of the tone to be defined as a parameter in the score. Score parameters can be represented by orchestra variables which take on their different values on successive notes. These variables are named sequentially: p1, p2, p3, ... The first three have a fixed meaning (see the Score File), while the remainder are assignable by the user. Those of significance here are:
p3 - duration of the current note (always in seconds).
p5 - pitch of the current note (in units agreed upon by score and orchestra).
Thus in
asig oscil 10000, p5, 1
the oscillator will take its pitch (presumably in cps) from score parameter 5.
If the score had forwarded pitch values in units other than cycles-per-second (Hertz), then these must first be converted. One convenient score encoding, for instance, combines pitch class representation (00 for C, 01 for C#, 02 for D, ... 11 for B) with octave representation (8. for middle C, 9. for the C above, etc.) to give pitch values such as 8.00, 9.03, 7.11. The expression
cpspch(8.09)
will convert the pitch A (above middle C) to its cps equivalent (440 Hz). Likewise, the expression
cpspch(p5)
will first read a value from p5, then convert it from octave.pitch-class units to cps. This expression could be imbedded in our orchestra statement as
asig oscil 10000, cpspch(p5), 1
to give the score-controlled frequency we sought.
Next, suppose we want to shape the amplitude of our tone with a linear rise from 0 to 10000. This can be done with a new orchestra statement
amp line 0, p3, 10000
Here, amp will take on values that move from 0 to 10000 over time p3 (the duration of the note in seconds). The instrument will then become
instr 1
amp line 0, p3, 10000
asig oscil amp, cpspch(p5), 1
out asig
endin
The signal amp is not something we would expect to listen to directly. It is really a variable whose purpose is to control the amplitude of the audio oscillator. Although audio output requires fine resolution in time for good fidelity, a controlling signal often does not need that much resolution. We could use another kind of signal for this amplitude control
kamp line 0, p3, 10000
in which the result is a new kind of signal kamp. Signal names up to this point have always begun with the letter a (signifying an audio signal); this one begins with k (for control). Control signals are identical to audio signals, differing only in their resolution in time. A control signal changes its value less often than an audio signal, and is thus faster to generate. Using one of these, our instrument would then become (next page):
instr 1
kamp line 0, p3, 10000
asig oscil kamp, cpspch(p5), 1
out asig
endin
This would likely be indistinguishable in sound from the first version, but would run a little faster. In general, instruments take constants and parameter values, and use calculations and signal processing to move first towards the generation of control signals, then finally audio signals. Remembering this flow will help you write efficient instruments with faster execution times.
We are now ready to create our first orchestra file. Type in the following orchestra using the system editor, and name it "intro.orc".
sr = 44100 ; audio sampling rate is 44.1 kHz
kr = 4400 ; control rate is 4410 Hz
ksmps = 10 ; number of samples in a control period (sr/kr)
nchnls = 1 ; number of channels of audio output
instr 1
kctrl line 0, p3, 10000 ; amplitude envelope
asig oscil kctrl, cpspch(p5), 1 ; audio oscillator
out asig ; send signal to channel 1
endin
It is seen that comments may follow a semi-colon, and extend to the end of a line. There can also be blank lines, or lines with just a comment. Once you have saved your orchestra file on disk, we can next consider the score file that will drive it.
The Score File
The purpose of the score is to tell the instruments when to play and with what parameter values. The score has a different syntax from that of the orchestra, but similarly permits one statement per line and comments after a semicolon. The first character of a score statement is an opcode, determining an action request; the remaining data consists of numeric parameter fields (pfields) to be used by that action.
Suppose we want a sine-tone generator to play a pentatonic scale starting at C-sharp above middle-C, with notes of 1/2 second duration. We would create the following score:
f1 0 256 10 1 ; a sine wave function table
; a pentatonic scale
i1 0 .5 0 8.01
i1 .5 . . 8.03
i1 1.0 . . 8.06
i1 1.5 . . 8.08
i1 2.0 . . 8.10
e
The first statement creates a stored sine table. The protocol for generating wave tables is simple but powerful. Lines with opcode f interpret their parameter fields as follows:
p1 - function table number being created
p2 - creation time, or time at which the table becomes readable
p3 - table size (number of points), which must be a power of two or one greater
p4 - generating subroutine, chosen from a prescribed list.
Here the value 10 in p4 indicates a request for subroutine GEN10 to fill the table. GEN10 mixes harmonic sinusoids in phase, with relative strengths of consecutive partials given by the succeeding parameter fields. Our score requests just a single sinusoid. An alternative statement:
f1 0 256 10 1 0 3
would produce one cycle of a waveform with a third harmonic three times as strong as the first.
The i statements, or note statements, will invoke the p1 instrument at time p2, then turn it off after p3 seconds; it will pass all of its p-fields to that instrument. Individual score parameters are separated by any number of spaces or tabs; neat formatting of parameters in columns is nice but unnecessary. The dots in p-fields 3 and 4 of the last four notes invoke a carry feature, in which values are simply copied from the immediately preceding note of the same instrument. A score normally ends with an e statement.
The unit of time in a Csound score is the beat. In the absence of a tempo statement, one beat takes one second. To double the speed of the pentatonic scale in the above score, we could either modify p2 and p3 for all the notes in the score, or simply insert the line
t 0 120
to specify a tempo of 120 beats per minute from beat 0.
Two more points should be noted. First, neither the f statements nor the i statements need be typed in time order; Csound will sort the score automatically before use. Second, it is permissable to play more than one note at a time with a single instrument. To play the same notes as a three-second pentatonic chord we would create the following:
f1 0 256 10 1 ; a sine wave function table
; five notes at once
i1 0 3 0 8.01
i1 0 . . 8.03
i1 0 . . 8.06
i1 0 . . 8.08
i1 0 . . 8.10
e
Now go into the editor once more and create your own score file. Name it "intro.sco". The next section will describe how to invoke a Csound orchestra to perform a Csound score.
The Csound Command
To request your orchestra to perform your score, type the command
csound intro.orc intro.sco (or simply “cs intro.orc intro.sco”
Or if you wish to suppress the display of the funtion tables, do:
csound -d intro.orc intro.sco (or simply “cs intro.orc intro.sco”
The resulting performance will take place in three phases:
1. sort the score file into chronological order. If score syntax errors are encountered they will be reported on your console.
2. translate and load your orchestra. The console will signal the start of translating each instr block, and will report any errors. If the error messages are not immediately meaningful, translate again with the verbose flag turned on:
csound -v intro.orc intro.sco
3. fill the wave tables and perform the score. Information about this performance will be displayed throughout in messages resembling
B 4.000 .. 6.000 T 3.000 TT 3.000 M 7929. 7929.
A message of this form will appear for every event in your score. An event is defined as any change of state (as when a new note begins or an old one ends). The first two numbers refer to beats in your original score, and they delimit the current segment of sound synthesis between successive events (e.g. from beat 4 to beat 6). The second beat value is next restated in real seconds of time, and reflects the tempo of the score. That is followed by the Total Time elapsed for all sections of the score so far. The last values on the line show the maximum amplitude of the audio signal, measured over just this segment of time, and reported separately for each channel.
Console messages are printed to assist you in following the orchestra's handling of your score. You should aim at becoming an intelligent reader of your console reports. When you begin working with longer scores and your instruments no longer cause surprises, the above detail may be excessive. You can elect to receive abbreviated messages using the -m option of the Csound command.
When your performance goes to completion, it will have created a sound file named test in your soundfile directory. You can now listen to your sound file by typing
play test.wav (or simply “p test.wav”
If your machine is fast enough, and your Csound module includes user access to the audio output device, you can hear your sound as it is being synthesized by using the command:
csoundplay
More about the Orchestra
Suppose we next wished to introduce a small vibrato, whose rate is 1/50 the frequency of the note (i.e. A440 is to have a vibrato rate of 8.8 Hz.). To do this we will generate a control signal using a second oscillator, then add this signal to the basic frequency derived from p5. This might result in the instrument
instr 1
kamp line 0, p3, 10000
kvib oscil 2.75, cpspch(p5)/50, 1
a1 oscil kamp, cpspch(p5)+kvib, 1
out a1
endin
Here there are two control signals, one controlling the amplitude and the other modifying the basic pitch of the audio oscillator. For small vibratos, this instrument is quite practical; however it does contain a misconception worth noting. This scheme has added a sine wave deviation to the cps value of an audio oscillator. The value 2.75 determines the width of vibrato in cps, and will cause an A440 to be modified about one-tenth of one semitone in each direction (1/160 of the frequency in cps). In reality, a cps deviation produces a different musical interval above than it does below. To see this, consider an exaggerated deviation of 220 cps, which would extend a perfect 5th above A440 but a whole octave below. To be more correct, we should first convert p5 into a true decimal octave (not cps), so that an interval deviation above is equivalent to that below. In general, pitch modification is best done in true octave units rather than pitch-class or cps units, and there exists a group of pitch converters to make this task easier. The modified instrument would be
instr 1
ioct = octpch(p5)
kamp line 0, p3, 10000
kvib oscil 1/120, cpspch(p5)/50, 1
asig oscil kamp, cpsoct(ioct+kvib), 1
out asig
endin
This instrument is seen to use a third type of orchestra variable, an i-rate variable. The variable ioct receives its value at an initialization pass through the instrument, and does not change during the lifespan of this note. There may be many such init time calculations in an instrument. As each note in a score is encountered, the event space is allocated and the instrument is initialized by a special pre-performance pass. i-rate variables receive their values at this time, and any other expressions involving just constants and i-rate variables are evaluated. At this time also, modules such as line will set up their target values (such as beginning and end points of the line), and units such as oscil will do phase setup and other bookkeeping in preparation for performance. A full description of init-time and performance-time activities, however, must be deferred to a general consideration of the orchestra syntax.
SCORE-11 (Brinkman, 1981 & 1990) is a note-list preprocessor for the CSOUND compiler,[1] which was written by Barry Vercoe at MIT. SCORE-11 was written by Alexander Brinkman of the Eastman School of Music. The SCORE-11 input syntax is based, with some important extensions, on the well known SCORE program (used on the Stanford-Ircam MUS10 system) by Leland Smith (Smith, 1972 & 1980). A composer who is familiar with either preprocessor will have no problems changing to the other one. This will reduce dependency on a specific music system. Some features of SCORE were not implemented in SCORE-11. These are mostly the features that allow data to be copied from one instrument block to another. Several features wer added to SCORE-11 to make it very powerful.
You will find SCORE-11 to be of great help in the process of defining the hundreds of events that make up a composition. In the following pages you will find a comprehensive manual introducing and describing in detail the various features of SCORE-11.
[1] SCORE-11 was originally designed for Vercoe's MUSIC11 system. MUSIC11, which was written in PDP-11 assembly language, was replaced in 1986 by CSOUND, a version of the program written in the programming language C, and which runs on many different computer systems. SCORE-11 works well with either version of Vercoe's program, which will be referred to as CSOUND in this manual except where the distinction is important.
Command Line SSH
Secure Shell Access
Command line access via a Unix terminal/shell is the most reliable, powerful method of accessing the Digital Music Studios. With it users can login and use the functionality and processing power of the CDMS computers remotely.
To login, open a terminal shell (on Mac, Applications --> Terminal; on Windows use Cygwin; on Linux or other Unix just open a standard xterm). Then at the command prompt type:
ssh REMOTE_MACHINE_NAME
...where REMOTE_MACHINE_NAME is the name of the machine you wish to access, for example digital.music.cornell.edu. If you use a different username on your local system than the one on the system you are logging into, you will also need to specify your remote username :
ssh USERNAME@REMOTE_MACHINE_NAME
CEMC systems are named as follows:
jack.music.cornell.edu (B27 Linux system)
devel.music.cornell.edu (B27 Mac system)
b25b.music.cornell.edu ("Film" studio, B25B)
b25c.music.cornell.edu (Undergraduate Studio 1, B25C)
b25d.music.cornell.edu (Undergraduate Studio 2, B25D)
On CEMC systems, convenient command shortcuts are also available using a standard syntax:
sshjack (same as ssh jack.music.cornell.edu)
sshdev (same as ssh devel.music.cornell.edu)
sshdig (same as ssh digital.music.cornell.edu)
sshb25b (same as ssh b25d.music.cornell.edu)
sshb25c (same as ssh b25c.music.cornell.edu)
sshb25d (same as ssh b25d.music.cornell.edu)
When logging in from the outside you will be prompted for your password. Enter it and you will be logged in immediately. Logins from within the studios are governed by secure authorized keys meaning your account will automatically be verified when a remote shell is requested and you will not have to type your password. This will become important later on as we seek to run remote processes inline with local programs.
You may also wish to create password keys between systems, enabling passwordless movement among studio systems. To set this up, type “cornellkeygen” and follow the directions entering no passphrase.
Secure Shell Copying
To copy files to and from local or remote computers, use the scp (secure copy) command. The syntax is identical to ordinary copying with cp.
scp FILE_TO_COPY [MORE_FILES_TO_COPY] DESTINATION
Unlike cp, the file to copy and/or their destination may be a remote computer. The user must specify the remote machine name and directory as a prefix. So for example, to copy a local file named myfile to my remote home directory ("/home/kevinernste") on digital.music.cornell.edu, I would type:
scp myfile digital.music.cornell.edu:/home/kevinernste/
Note the colon ":" between the machine name and the directory in the destination argument. This syntax should be followed carefully.
As with cp (and other Unix commands), all unix "wildcards" will work, so:
scp * digital.music.cornell.edu:/home/kevinernste/
...will copy all files in the current directory to the destination directory on b27. To copy directories and subdirectories, just add "-r" (for “recursive), so:
scp -r * digital.music.cornell.edu:/home/kevinernste/
GUI SSH tools
If you wish, there are also several graphical SSH/SCP/SFTP clients available. Most limited to simple file copying, but some include terminal shell functions as well. To peruse the list of clients available for your operating system of choice, please visit openssh.com and follow the links in the left-hand panel.
Introduction to the Eastman Csound Library
(This section last updated August 2004, Allan Schindler)
The Eastman Csound Library, the topic of this extract from the Eastman Computer Music Center Users’ Guide, is a collection of front-end programs, "instrument" algorithms, score file preparation programs and assorted utilities designed to simplify ECMC/CEMC users’ introduction to, and use of, the Csound music compiler. Csound is a widely used software audio synthesis and signal processing package, available at no cost under the LGPL (Lesser General Public License) from the Csound Home Page web site (http://csounds.com) inversions Linux (and other flavors of Unix), Macintosh and Windows.Csound initially was developed on Unix systems during the 1980s by a team led by Barry Vercoe at the Massachusetts Institute of Technology and employed a commands issued from shell windows. During the 1990s the Csound programs were ported to Macintosh, Windows and other platforms. Today, cross-platform development of the "canonical" (official) Csound source code continues by a world-wide group of Csound users, coordinated by John Ffitch, who update "canonical" (officially supported) versions of the language.
Like other software music compilers (such as Cmix and cmusic) that have been written at academic computer music centers, Csound has its roots in the very first music compilers, called Music I through Music V, written by Max Mathews at Bell Labs beginning around 1957. In most of these compilers, the fundamental means of creating or modifying sounds is a user-defined synthesis or signal processing algorithm, called an instrument inCsound. The algorithm consists of a step-by-step sequence of mathematical and logical operations, coded in the Csound compiler language, and then executed by the CPU. Often, these operations are very similar to the types of operations that takeplace within the electrical circuits of hardware synthesizers, amplifiers, mixing consoles and other types of audio gear. Aparticular instrument algorithm, which generates a particular type of audio signal or timbre, might be likened to a particular "patch" available on a hardware synthesizer or sampler. Alternatively, analgorithm might add reverberation, or echos, to a previously created soundfile, or to the audio signals being generated simultaneously by some other instrument within the same compile job.
Read more in the attached PDF.
Documentation and discussion of the examples found with "lsex sc" on CEMC computers can be found here, Allan Schndler's famous Eastman Csound Tutorial:
http://ecmc.rochester.edu/ecmc/docs/allan.cs
The thrust of the discussion is more generally "Csound proper", but many Score11 examples are illustrated along with their matching orchastras.
Eveything from the ook is accesible on CEMC systems. To look up an example, say example 1-1 one ("ex1-1") from chapter one, do:
lsex sc
(you sill see the example listed)
getex ex1-1
mko ex1-1
score11 ex1-1
cs -d orc sout
You will now have a wave audio file, as usual, called "test.wav that contains the example's audio result.
Music 620: Electroacoustic Techniques, Fall 2007
Kevin Ernste, Professor
kme32@cornell.edu
Office: B27 and 108 Lincoln Hall
Office Hours: Wed. 10 – 2, others by appointment
(607) 255-5795
Course website: http://digital.music.cornell.edu
- please visit the website and register a username
Music 620 is an exploration of classical and state-of-the-art tools for making music with computers. A substantial portion of our time will be spent working with software directly, although “learning software” is not our explicit goal. Instead we will engage several software metaphors – generalized categories of functionality – working toward developing individualized composer toolkits suitable for creative work. In developing our facility with basic techniques, we will examine a body of pieces from the classical repertoire.
In addition to commercially available software, students will be exposed to a number of excellent free software tools, many with unique designs and functionality. All tools are available for download on the course website.
Course requirements include: two one-on-one oral tests, one in-class presentation on a composer or piece of your choosing, one mid-semester piece/study, and a larger final composition to be presented in a semester's end concert. In addition, there will be weekly or bi-weekly assignments to be carried out on the student's own time.
Grading for the semester is as follows:
20% Class participation
20% Mid-semester one-on-one test
15% Mid-semester project
15% Public lecture/presentation
30% Final project and concert participation
Facilities: B27 will be our primary studios with an overflow workstation in B25A. In addition, there is a mobile rig usable for performances and remote recording. To inquire about availability, consult studio faculty or staff.
Selected Listening List:
Reich, Come Out
Schindler, Breath of Life
Berio, Visage
Varese, Poem Electronique
Lansky, Idle Chatter
Stockhausen, Kontakte
Stockhausen, Hymnen
Subotnick, Silver Apples on the Moon
Mel Powell, Strand settings: darker
Davidovsky, Synchonisms #6
Risset, Sud
Chowning, Stria
Chowning, Phone
Babbitt, Philomel
Xenakis, Orient-Occident
Cage, Imaginary landscape no. 1
Semester Schedule
< Week 1 August 23th
Course introduction, Unix fundamentals, remote access
< Week 2 August 30th
Fundamentals of digital audio, basic recording techniques
< Week 3 September 6th
Audio editing, mixing, soundfile libraries
< Week 4 September 13th
Introduction to Csound and the Score11 event preprocessor
< Week 5 September 20th
Csound/Score11 continued, sampling and granular synthesis
< Week 6 September 27th
Advanced Score11, Csound Orchestras, Cecilia
< Week 7 October 4th
Test 1; (test and mid-semester project discussion)
Introduction to PD and Max
< Week 8 October 11th
PD/Max continued, subpatches, externals, abstractions;
< Week 9 October 18th
Advanced PD/Max topics: "best practices" in engine and interface design
< Week 10 October 25th
Advanced PD/Max topics: interactivity, networks and OSC
< Week 11 November 1st
Analysis and re-synthesis techniques, FFT, Phase vocoder, spectral modeling and editing
Mid-semester projects due, Concert is November 8th, Midday Music
< Week 12 November 8th
Concert Performance, Midday Music
< Week 13 November 15th
Supercollider and JACK
< Week 14 November 22nd
SuperCollider; spatialization techniques, methods and formats
< Week 15 November 29th
Final concert preparations
Final Concert Date: TBA