Music 620: Electroacoustic Techniques

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.

Assignments

Below is a listing of assignments for Music 620.

Assignment 1 for Thursday September 6th

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:

Score11 Documentation
Csound Beginning Tutorial

Assignment 2 for Thursday September 27th

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:

PD-extended installers

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:

JSTOR Reading

You may also wish to review the attached PDF by John Smalley, a more condensed and rather introductory essay.

Study Piece One, due October 4th 2007

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).

Documentation

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.

Basic Unix Commands

Unix commands (HOME DIR)

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"

Csound Beginning Tutorial

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.

Score11 Documentation

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.

Secure shell access, remote login

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.

Eastman Csound Library instruments

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.

Allan Schindler's Eastman Csound Tutorial

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.

Syllabus

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