Assignment 0, Due Tuesday, August 30th

Create a user account here and leave a new blog entry describing your background and interests with respect to the course.  What is your musical background: instruments, experiences, etc?  What brings you to Digital Music?  Do you have a creative agenda with the course? Are you interested in working with others, etc? 

I would also encourage you to paruse the site, leaving comments on other student postings as you like.  You may wish to click on "Introductions" the tag cloud below to see what others have posted in the past.

Assignment 1, Due Thursday September 9th

1. Make a recording of the human voice using Audacity.  You may be as creative as you like with what is said, rapped, or read but the resulting sound file should illustrate your understanding of the principles of signal quality as discussed in class.  Work toward a full, warm, sound exemplified by the classic "radio voice".  The resulting file should be approximately 10-15 seconds long and be cleanly edited and ready to play.

Please turn in your finished assignment on the network drive (linked as "MUSIC_1421" on the Desktop in all studios).  The final WAV or AIFF (uncompresed) audio file should be named in a way that makes it's ownership obvious to the TA.  I recommend the following naming scheme...assuming, for the moment, I am turning in a sound file I titled "Vocal Study":

1421-assign1-kme32-vocal_study.wav

coursenumber-assignmentnumber-netid-title_of_track.wav

(hyphens to separate parts of the name, underscores replacing any spaces)

You may wish to consult the following tutorials during your exploration of Audacity and in its use for this assignment:

Audacity Manual Tutorials

Assignment 2, Due Thursday September 22nd

1.  With the recording techniques discussed so far, record and edit together your own soundfile library, a collection of individual sounds suitable.  You may use whatever sound making resources you have or can muster.  Edit and save these samples as short "notes" or individual sounds.  One can always build phrases, loops, melodies, or other time-varying material from these smaller soundfiles. Please look toward creating 15-20 individual soundfiles.

2.  Using the samples you created in #1 in addition to samples from the  CEMC soundfile library (Sound --> sflib) or other legal sources (freesound, for example), create a short "mix" or "study".  This little "piece" should be no longer than 1 minute (2 max!) should suffice.  Be creative. You may wish to use the pieces played and discussed in class as models.

Related resources:

Freesound

University of Iowa Electronic Music Studios (musical instrument samples)

Assignment 3, Due Tuesday October 18th

Using the Reason Subtractor, create a short mix (30 seconds to 1 minute) focussed on timbre and utilizing the layered automation techniques discussed in class. Please see the attached Reason template as a starting point for this piece. Ideally you would leave the notes alone and simply alter the timbre to shape the music over time.

In preparation for this mix, listen to the examples of John Chowning's music found in the studio soundfile library listening directory (Sounds --> sflib --> listening).

1. Stria (required listening!)

2. Phone

3. Turenas

You may wish to remind yourself of the Subtractor's basic configuration:

http://digital.music.cornell.edu/subtractorbasics

Assignment 4, Due Thursday October 27th

1. Build a "classical" vocoder in Reason where a voice sample is used as the modulator and an analog synthesizer (Subtractor) as the carrier.  Please turn the result as a .rns "song" files, Reason's native output format.  If you use samples outside of Reason (those not inluded in Reason's patch/sample libraries), be sure to include your outside samples within the .rns "song" by choosing "File-->Song Self Contained Settings...".  Making sure your sample is checked to be included in the song when saved.

2 (optional). Create s second example which utilizes other combinations of devices.  Your TA gave serveral options in the lab, continue developing one of those or build one of your own.  This second example could, for example, be something you might use in your second semester project.

Project One, Due Thursday September 29th

For the first project you will creating a short piece using the techniques and applications used in the course thus far. You should shoot for 2-3 minutes of music although slightly shorter or longer projects are possible. You must turn in the final project as a .wav or .aiff audio file. The key is to give me a final, uncompressed audio format suitable for listening and evaluating. I may look at the Cubase or Audacity project if you provide one, but I am primarily interested in the musical results. For those who prefer guidelines, here are a few suggested project types:

1. A "song" made from a multi-track recording and mixdown. Using the recording techniques from the course, record multiple layer/tracks to be processed and mixed. Ideally you would use Live for this as it is the most flexible environment for the kinds of non-destructive editing techniques you will likely be using.

2. A collage/pastiche piece using your own samples, those from the soundfile library (sflib), or sounds from other legal sources (freesound, etc). For examples of how this might work you can further explore Varese's "Poem Electronique" in the sflib folder "listening" or read about and listen to pieces by composers of musique concrete such as Pierre Henry and Pierre Shaffer. I recommend Symphony pour un homme seul ("Symphony for a Man Alone"), a piece created by both men in collaboration (Henry is attributed as the composer) or in the Cornell music library, Henry's Entite ("Entity"), call number Rec 175 E4 E31.

3. Some combination of the above two or any other interesting format you can dream up. Some have done audio diaries, audio documentaries, poems, DJ mashups, and on and on.  Please be in touch if you have any questions or need further guidance on your project.

Happy music making!

Project Two, Due Thursday November 10th

As with Project One, your primary goal should be to create something musically engaging (both to us and to you), something beyond the technical focus of the assignments.  The duration should be between 3 and 5 minutes.  I would suggest one of two approaches:

- Continue your work from the first project, expanding upon or reworking materials or ideas from your initial piece.

- Use this project as an opportunity to experiment with a new idea looking toward the final project and concert.

With respect to software tools, I recommend you use any and all of the tools at your disposal which serve your musical intentions.  Here are three possible guidelines:

1. Create a song using Reason.  As we have discovered Reason presents a remarkably flexible and powerful environment, a self-contained compositional toolkit.  Having done several shorter pieces there, now compose something more substantial.

2. Using Reason as a potential sound resource, create a mix/song/pastiche in Cubase or Live.  You can combine the capabilities of these applications via Rewire or simply build your sound sources as individual soundfile/submixes exported from Reason.

3. Use any or all (or none) of the tools from the semester, investigating new ones if needed (perhaps exploring JACK, networked MIDI, or others presented/suggested during lecture).  Try to get beyond what any one applications does "well" to what they can do for your idea.

If you have any questions or would like further information, don't hesitate to contact me directly.

Final Project, due December 3rd, 2011

You final project is to be performed on our end-of-semester Sound Art Forum, Saturday December 3rd at 3pm in Lincoln B20.  You may use any technique from the course and any software you wish.  I would highly encourage you to stretch out and do something you might not othewise have done were it not for your involvement in this course.

Also, on the Thursday before this date (last day of class), please bring me a summary of the technical needs of your piece.

Some further suggestions for those who beneft from them:

1) Try to stay around the 3-4 minute mark (!!)

2) The following equipment will be available (others discouraged but available upon request):

- two microphones

- 4 speakers ("rectangle" arrangement with odd channels on the listeners' left

- the computer and mixer from studio D

- a Kontrol49 keyboard

- a QS8.1 88-key keyboard

3) You are free to collaborate with other members of the class but you MUST CONSULT WITH ME and let me know what each person's role will be.  Outside collaborators are welcome and encouraged.

4) Create something amazing

Reading, Lansky's "Being Digital" (online)

The Importance of Being Digital

Paul Lansky

3/19/04

tART-lecture 2004

commissioneed by the tART Foundation in Enschede and the Gaudeamus Foundation in Amsterdam

Over the past twenty years or so the representation, storage and processing of sound has moved from analog to digital formats.  About ten years audio and computing technologies converged.   It is my contention that this represents a significant event in the history of music.

I begin with some anecdotes. 

My relation to the digital processing and music begins in the early 1970’s when I started working intensively on computer synthesis using Princeton University’s IBM 360/91 mainframe.   I had never been interested in working with analog synthesizers or creating tape music in a studio.  The attraction of the computer lay in the apparently unlimited control it offered.  No longer were we subject to the dangers of razor blades when splicing tape or to drifting pots on analog synthesizers.  It seemed simple: any sound we could describe, we could create.  Those of us at Princeton who were caught up in serialism, moreover, were particularly interested in precise control over pitch and rhythm.   We could now realize configurations that were easy to hear but difficult and perhaps even impossible to perform by normal human means.  

But, the process of bringing our digital sound into the real world was laborious and sloppy.    First, we communicated with the Big Blue Machine, as we sometimes called it, via punch cards:  certainly not a very effective interface. Next, we had a small lab in the Engineering Quadrangle that we used for digital-analog and analog-digital conversion.  (A few years earlier it had been necessary to drive forty miles through central New Jersey—not a pleasant ride—to Bell Labs in order to use their converters.)  Our lab included two large digital tape drives. One was a vacuum column monster that read 800 BPI (bits per inch) tapes, holding about 20 megabytes.  It sounded like a jet engine when the vacuum columns were engaged.   The other was an unreliable 1600 BPI mechanical drive.  We wrote the digital tapes on the mainframe and hand-carried them to the lab.   The first computer made by Hewlett Packard, a refrigerator-sized 2116 minicomputer with 64k memory, ran the drives and the converters.  The noise in the room was deafening when it was all powered on.  Our 16-bit D-A converters were made by Hewlett Packard.  Our A-D converters were 12-bit and custom-made.  At the end of the chain were Ampex and Scully 15-ips tape recorders,

I was in my 20’s, had good high-frequency hearing and distinctly remember marveling at the purity of the signal coming directly off the converters, as best I could hear it through the noise in the room.  I noticed and reluctantly accepted the gentle high-frequency hiss that the tape machine added.  In the mid-1970’s my first computer piece, Mild und Leise, was issued commercially on LP thanks to a competition held by the International Society of Contemporary Music/League of Composers

[1]

.  It was a 19-minute work made entirely synthetically (there were no sampled sounds), and it fit neatly as track 2 on one side of the LP, following a short two-minute piece.  It was not surprising to me that in addition to the tape hiss there was the added noise of the needle dragging through the grooves, and neither was it surprising that the quality of sound was noticeably better the first time I played the disc than the second or subsequent times.  I even learned to accept the mild pre and post echoes of the sound during quieter moments when print-through from adjacent grooves bled through.  What was surprising was that the quality of the reproduction got somewhat worse toward the end of the piece.  I mentioned this to my father, a recording engineer for Capitol Records at the time, who told me that I was hearing ‘inner diameter distortion’.  The angle of the needle to the grooves grew more acute as the inner grooves were reached, creating distortion.  This was very distressing.

So the act of transferring digital sound into the analog domain was fraught with traps and pitfalls at each stage.  But the story doesn’t end there.   During those days we were working with very low sampling rates, typically14khz, in order to accommodate the slow speed of the tape drives (and also save computer time since it could take hours to create a few moments of sound).  Then, as now, at the end of every digital-analog conversion is an analog low-pass smoothing filter that eliminates the mirrored signal between the Nyquist frequency (half the sampling rate) and the sampling rate.  Our filters were hand-designed in our engineering shops and were a delicate and sensitive conglomeration of capacitors and transistors.  But, in order to completely eliminate any frequencies above 7khz the filters had to start to slope down at about 5khz.  Thus the birthing pains of the digital signal were significant even before it hit the tape recorder.  We subsequently worked out a version of over-sampling commonly used in CD players these days.  The signal was up-sampled to twice the sampling rate, allowing an analog smoothing filter to be applied at a higher frequency, well above the signal we cared about, and the digital signal was first low-passed by a digital filter, while still in the digital domain, which we were able to design in software with a much steeper cutoff, thus giving us audible frequencies well over 6khz! (A lot of work for 1khz worth of frequency range.)

Bringing sounds from the analog world into the digital world was an equally painful process and it was actually more perilous since the hardware was poorer and noise entered the picture on the way in, and never disappeared.

My point in describing this process is to develop some perspective on the two sides of the fence that we lived with in those days.  The power of digital signal processing was at our fingertips, but our ears could only hear a poor approximation of it.
 

It was really not until the early 1990’s that things changed much.  In the mid 1980’s our work moved to personal computers, still pitifully slow compared to today’s machines.   In the early 90’s computing and audio technologies converged:  recording studios switched to digital production, and eventually the compact disc became a standard storage medium for data as well as audio. People began to talk about the demise of ‘vinyl’ and the debate on the relative virtues of analog versus digital sound that had been brewing for ten years came to a boil.   Today there still remains an ultimate moment when every sound must be converted to an analog signal, even if it is just at the level of a speaker cone, but now this only happens once in the life of any audio reproduction.

Despite my early trials with digital and analog sound it is not my intention here to weigh in on one side or another in the argument about the virtues of analog versus digital sound.  The heat generated by this discussion has far exceeded the light. Audio technologists rage on about the differences and sound theorists grasp at flimsy straws.   In a 1997 Musical Quarterly article, Rothenbuhler and Durham, for example, go to the absurd extreme of stating:

The crucial difference between phonographic [analog] techniques and digital recording and playback is that the digital storage medium holds no analog of either the original recorded signal or the resulting playback.  The digital storage medium holds numbers—data. These numbers are related to waveforms by a convention arrived at in intercorporate negotiations and established as an industry standard; but they could be anything.

[2]

I suppose the ‘intercorporate negotiations’ they’re referring to were the ones held by shepherds 50,000 years ago while they were sampling the motions of heavenly bodies and deciding how to plot them:  perhaps the first digital representation of a continuous signal

[3]

.   They go on to assert that analog recording has a ‘physical relation’ to the sound and thus has a continuous link to the originators of the signal, while digital representation is merely a ‘measurement’ of the sound.  What reaches our ears from digital signals, therefore, are not the voices of the past, but reports on the voices of the past.  The supposed virtue of analog representation lies therefore in its physical connection with the dead.  Their point is charming even though it is based on a misunderstanding.   

There are certainly things to be said on both sides of the argument concerning the accuracy of either technology, although I would assert that digital technology, if not already, will soon be capable of being indistinguishable from the best analog reproduction.   The ultimate question in the digital/analog debate is therefore, to my mind, not one about sound quality.  What is most interesting is what effect it has on what we are able to do with sound.

There are two important areas I’d now like to consider, both a function of digital signal processing (DSP).  The first is the new status of the idea of an original and a copy.  The second is the distinction between hardware and software.  Each of these areas carries implications for the meaning of music.

It seems obvious that having a digital representation of a signal means that there is no longer any distinction between an original and a copy.  With care, a digital signal is capable of being duplicated exactly an infinite, or at least a very large number of times.   Every ‘copy’ of a compact disc contains exactly the same set of numbers as the original digital master, and is capable of producing the same signal an infinite, or at least a very large number of times.  There is no artifact introduced by copying or processing at any stage, nor any degeneration of the storage medium caused by the act of listening.  There is no trace of a history.  My dismay at the successive stages of degeneration of my precious mainframe-created music in the early 70’s is gone.  Today, everyone who hears my music on CD, for example, is capable of hearing a perfect performance, identical (to within the quality of their audio equipment) to what I hear when the signal is first created.  I no longer have the privilege of best possible point of audition, which is now shared by everyone, and there is only a one-stage transition from the digital to the analog domain, and that of course is necessary because we don’t yet have digital ears.

The current tumult in the recording industry is entirely due to this fact.  Even though mp3 files, a compressed form of digital signals, are inferior in audio quality to the original digital version, the fact that they too can be copied indefinitely with perfect accuracy, further intensifies the debate.   Everyone owns the original, and the propriety of ownership is no longer bounded by physical laws, only by legal statutes.  The pathetic efforts of the recording and media industries to curtail this by introducing degeneration, either by physical means or by software will ultimately fail.   They are attempting to reshape the digital world in the image of the previous analog generation and fail to see the shifting ground beneath their feet.   This leads to concerns over intellectual property and copyright, which I will evade here by choice, except to say that there will be an ongoing battle between opposing forces and this will merely slow, but not stop the realization of the consequences of digital formats.  A digital format is not a result of ‘intercorporate negotiations’, but rather a mathematical object whose manipulation is the business of computers.    Decoding the numbers on a DVD or compact disc, while requiring some advanced knowledge and programming skill, is not rocket science.  Anything in a digital format can ultimately be read as a string of bits, and reproduced by anyone

[4]

.

The profound difference between reproduction in the digital and analog domains obviously lies, then, in the extent to which analog representations trace a history of the actual copying process.  When we view or hear something that is an analog copy we are simultaneously experiencing an intervention between the original and our moment with the object.  Someone at some point had access to an earlier generation and copied it onto some medium, adding artifacts in the process.  When you see a Xerox copy of a newspaper clipping it is clear, for example, that what you are seeing is the result of the specific actions of an individual.  The original peers through the artifacts introduced in the process of copying.  When experiencing a digital representation there is not usually any intervention between us and the original: what we are experiencing is the original.

[5]

The elimination of degeneration caused by copying leads us to a world in which signal processing carries few penalties in terms of the creation of noise and artifacts.  This means that the space between imagination and realization has vast new potential.  Recorded sound is no longer a fragile object, subject to rot, print-through, copy noise, distortion and inaccurate reproduction.  The consequence of this is that editing, mixing, transforming and otherwise modifying sound has an entirely new dimension and creates new realms of potential.  The quality of any processing will basically be subject to degeneration caused only by the attributes of the original.  Nothing is added as a result of external factors.    (There are, of course, limitations introduced by bit-depth and sampling rates, but most processing is now done in floating point format, and higher sampling rates move frequency domain distortions well out of the range of human hearing.) The tradition of Musique Concrête, for instance, rested at first on a very flimsy foundation.  At every stage potential for degeneration entered the picture and exerted a strong constraining influence on what was possible.   The finished product, moreover, was necessarily of another generation and decidedly inferior

[6]

.  The genius of early electronic works by Stockhausen, Varèse, Berio, Schaeffer and others lies partly in the ways they circumvented the limitations imposed by analog processing.  And although constraints are always part of the challenge to the ingenuity of composers (whoever would have thought one can make great music on a harpsichord), the limitations of potential degeneration shrank the conceptual domain in which they were working.   Nevertheless, a gradual transformation of our perspective on the potential meanings of recorded sound begins at about the same time.

The emergence of digital signal processing helps complete an evolution that began many years ago concerning the meaning of recorded sound.  The visionary originators of Musique Concrête saw that recording was potentially much more than merely a notation of past events.  Coming about fifty years after the first recordings they began to imagine musical ways of cashing in on the act of hearing a recording as a primary experience.   We see a gradual acceptance of the loudspeaker as a kind of musical instrument beginning at this point.  Interestingly, film sound theory provides a useful perspective on some of these same questions. The role of sound in film helps develop our perception of the meaning of the loudspeaker.    James Lastra, in Sound Technology and the American Cinema

[7]

distinguishes between  ‘identity’ and ‘non-identity’ theorists.  Briefly, the former believe that recorded sound has the potential to be indistinguishable from the live sound, while the latter feel that recording destroys a large part of a sound’s essence and presents a different order of experience than the original.  The debate has its origin early in the history of film when sound technicians were divided about whether or not the aural perspective of the audience should be as close as possible to that of a potential auditor actually in the scene.   Practice in film evolved quickly to generally abandon any attempt at total realism and as a culture of film viewers we have become accustomed to disparity between the physical structure of a scene and its audio representation.  We’ve long since learned to associate the sounds of struck coconut shells with horse’s hooves, for example, as well as accept the disparity between  the apparent physical characteristics of some architecture and the acoustic signature of sound presumably occurring in that space.  While filmmakers nod toward realism in this respect it is generally the case that their efforts are half-hearted.  Lastra bridges the gap between the identity and non-identity theorists by focusing on our perception of the inner narrative of a sound text.   Our attention oscillates between meaning, timbre, texture, rhythm, syntax, pitch, creating a complex weave  in which the total package matters less than the aggregation of the individual characteristics of perceived sounds.  Quoting Lastra:

There is never a fullness to perception that is somehow ‘lost’ by focusing on a portion of the event, by using the event for certain purposes, or simply by perceiving with some particular goal, say understanding, in mind.

[8]

Film theory helps intensify our perspective on the nature of recorded sound by illuminating questions about our individual interactions with, and understanding of it.  In other words the space created by recording is malleable: though fixed in spectral terms we react to it individually and idiosyncratically.  It goes far beyond merely being a notation of an event.

In essence then, a recording can create what could reasonably (although unfortunately) be called a virtual world and we as listeners have become acculturated to peering into that world, accepting and disregarding its limitations and its contradictions of reality.  It is instructive to remember the astonishment with which each generation, beginning with Edison, greeted the new technologies: viewers fled the image of an oncoming express train; Edison’s ‘tone tests’ challenged listeners to distinguish between a real singer and what we would now consider a terrible recording of one; the wonders of stereo reproduction and now the marvel of multi-channel digital sound poke at the potential for recorded sound to ultimately be indistinguishable from the real thing.  (Whether or not this is ever possible is beside the point.  We certainly are approaching that goal).   In each case we formerly peered into a world that had some sort of curtain around it, and was only a weak approximation of reality as we know it.  As the technology improves the curtain becomes more transparent. But rather than try to cast recording as an incomplete representation of reality it is more useful today to imagine that there are two realities, the experience of recorded sound and the experience of live sound.

Just as in film, unrealistic juxtapositions, overlaps and manipulations of time often contradict our real-world experiences but we accept them as collage-like interpretations of reality, so too in recording we accept things as musical fact that would be impossible to experience in the real life.  Most professional recording today is designed to create an illusion of reality that differs substantially from an original experience.   Not only are errors removed so that the performance is at least letter perfect, but in most cases the point of audition is entirely artificial.   An orchestral recording is going to entail dozens of microphones and many channels, enabling the editors to tweak the balance among many different aural perspectives at any moment.  Not even the best seat in the house has this vantage point.  The difference between hearing a good orchestra recording and hearing a live orchestral performance is vast, and probably not reasonably comparable.  It is impossible to assertively state that either is superior, they are simply different.  In popular music it is probably more common than not that a given recording consists of innumerable overdubs.

[9]

  The difference between a recording and a live rock concert is even vaster than in the orchestral instance.  There is no way to even approximate the body-shaking experience of a stadium-sized amplification system on a home CD.   The rock concert model is, in many ways, an emulation of the CD, which often precedes the concert tour.  The orchestra recording, on the other hand, goes to some lengths to create a virtual image of a concert experience, unrealistic though it may be.  Most other recordings fall somewhere along this spectrum. 

Recorded sound has thus emerged as a complex and rich arena of musical potential.  It is no longer merely archival.  In the past fifty years many composers have been attracted to it as a primary medium, and the emergence of digital signal processing has inaugurated a new stage in this evolution.  I will now walk through a series of examples to demonstrate the power of DSP for musical purposes.

Much of the work that many of us have done in electronic music invests heavily in the idea of hearing recording as a primary experience, and in a world in which we peer at a kind of virtual reality through the windows, or lenses, of loudspeakers.  We cash in on the suspension of disbelief that recording and film has taught us to employ: that even though what we perceive contradicts our experience of reality, we still accept it as a newly formed version of reality.  It is into this virtual world, influenced by our acculturation of recorded listening that the most interesting meaning of digital signal processing arises.  It is here that the worlds enabled by DSP manifest their real potential.

Many, but not all of the things we do in the digital domain are at least theoretically possible in the analog domain.   Analog filters can do the work of digital filters but at considerably more cost and with less efficiency and flexibility.    My primitive example above of using oversampling to move a signal out of reach of sloppy analog anti-aliasing filters, and using finely tuned digital filters to do the work instead, is a simple case.   The power of software, on the other hand, enables us to work with sound in ways that are impossible to imagine using analog tools.  Thus the space behind the speaker now becomes one that is vastly more pliable than before, and as observers and creators of virtual worlds we have significant new abilities.

One of the most interesting aspects of digital signal processing research is in the area of separation of the various components of a sound: pitch, duration, timbre.  A substantial difference between working in the analog and digital domains is the ease with which, in the latter, we can create and store analytical data about various aspects of a signal.  Modeling thus becomes a vastly more flexible and powerful enterprise.  No longer wedded to a direct link between these parameters composers are free to imagine idiosyncratic uses for each, in combination and in indirect ways.  

Some of my earliest work in computer synthesis involved a modeling technique known as Linear Predictive Coding (LPC).   This technique is specifically modeled on the mechanisms of speech and has its origins in the Channel Vocoder, developed  by Homer Dudley at Bell Labs in the 1930’s.

[10]

  This was an analysis/synthesis machine that separated out the components of speech into excitation function (glottal folds) and filters (head, chest, nasal passages).  During the 1960’s and 70’s researchers at Bell Labs developed LPC as a digital technique along similar lines.  Briefly, in the analysis process multi-pole filters are constructed for roughly each 1/100^th second of speech to approximate the vowel formants at that moment. In the synthesis process an artificial excitation function, easy to synthesize, is fed through these filters.  Various means are used to detect voiced/unvoiced speech in the analysis and in resynthesis white noise is used in place of a pulse to create plosives, fricatives, etc.   By independently varying the rate at which the filters change, and the frequencies of the pulse excitation-function we have effectively separated pitch, timbre and tempo.  In other words the crippling stranglehold of the tape recorder, in which changes in tape speed uniformly affected pitch, timbre and speed no longer holds.  In addition to this, Kenneth Steiglitz devised a method of altering the formant characteristics of the filters allowing us to change the apparent dimensions of the original source: changing a violin into a viola, a man into a woman, etc.

[11]

  Example 1a demonstrates different LPC resyntheses of a single spoken phrase.  Examples 1b and 1c are from my early work Six Fantasies on a Poem by Thomas Campion.

Audio Examples 1

[12]

http://www.paullansky.org/beingdigital/example1a.mp3

http://www.paullansky.org/beingdigital/example1b.mp3

http://www.paullansky.org/beingdigital/example1c.mp3

The Fast Fourier Transform,  (FFT) a quick digital shortcut for the Discrete Fourier Transform is another way to separate out various components of an audio signal.  Working digitally in the frequency domain with windowed frames enables us isolate and arbitrarily modify frequencies, timbres and speeds.  A rather brilliant use of this is demonstrated by the Shapee program of Christopher Penrose.

[13]

  In this example the frequencies of an arrangement of the Brahms Lullaby are mapped onto the timbres of a vocal work by Perotin. 

Audio Examples 2

http//:www.paullansky.org/beingdigital/example2a.mp3

http://www.paullansky.org/beingdigital/example2b.mp3

http://www.paullansky.org/beingdigital/example2c.mp3

This technique is similar to convolution, in which two signals are multiplied by each other in the frequency domain, resulting in a merging and exchange of characteristics.  There are an endless number of examples of convolution, and of transformations using frequency domain rather than time domain characteristics.    The Phase Vocoder, developed at Bell Labs in the 1960’s and subsequently by Mark Dolson at UCSD in the 1970’s, is a further development of Homer Dudley’s Channel Vocoder.  Much of the work by composers such as Chris Penrose, Paul Koonce and others has been based on this technique.  Unlike LPC, the Phase Vocoder does not attempt to understand the particular physical characteristics of a signal to begin with; it separates out frequency and amplitude characteristics according to FFT derived data rather than formant regions.  Wavelet Transform analysis

[14]

is an approach that is more sensitive than a simple FFT in that it is attuned to the difference between short-term high frequency changes, and slower moving low frequency events while an FFT will view both in the same temporal domains.   

Working in the frequency domain provides extraordinary power, but some time domain approaches are equally suggestive.  An approach that I have found interesting is to map envelope and frequency characteristics from a source sound to another, artificially created sound.   In my 1988 piece, Smalltalk

[15]

, I mapped the amplitudes, rhythms and frequencies of casual conversation onto plucked string filters.  All that was necessary to do this was a frequency and envelope analysis of the original signal.

Audio Example 3

http://www.paullansky.org/beingdigital/example3.mp3

Some years later I made a few pieces that extended this technique.  In Now That You Mention It

[16]

the same parameters are mapped onto piano sounds

Audio Example 4

http://www.paullansky.org/beingdigital/example4.mp3

and in For the Moment

[17]

Audio Example 5

http://www.paullansky.org/beingdigital/example5.mp3

they are mapped in a different sense.   

The power of software lies not only in the extent to which aspects and qualities of sounds can be teased apart, but also in the freedom it provides to arbitrarily patch amongst and between sound’s dimensions.  These mappings are useful concepts in fleshing out a virtual world in sound.  Just as objects in virtual reality can have aspects that are familiar to us but behave in unexpected ways, so too in the audio domain the apparent products of physical actions, speaking, striking something, pulling a bow, can appear logical but act irrationally.  

Every analog synthesizer had a random number (white noise) generator.   The works of Morton Subotnick and others are rich testimony to the value and use of random control voltages.  In the digital domain, however, random numbers are generally created by formulas that approximate white noise.  There is generally not going to be much difference between the spectra of random signals in the analog or digital domains except in one respect: they are precisely repeatable in the digital domain.  While this may at first seem contradictory it can be quite useful.  When used in non-audio time, i.e. to control choices of notes, timbres, envelopes, etc. being able to reproduce results is extremely valuable and casts the use of random numbers in an entirely different light. A number of my pieces, beginning with Idle Chatter

[18]

in 1984, use randomness as a generator of foreground detail.

Audio Example 6

http://www.paullansky.org/beingdigital/example6.mp3

I typically use ‘random selection without replacement’ to control the distribution and qualities of textures.     In 1998 I composed a piece for sampled piano called Heavy-set

[19]

that used a model of the right hand of a pianist.  The model worked by randomly selecting intervals to play, deciding when to play two notes instead of one, choosing directional changes, periodically, deciding to play some notes louder than others, and making various other decisions that were modeled on the kinds of thoughts an improvising pianist might have while playing.   The system was thus capable of producing an infinite, or at least a very large number of pieces that were similar in harmonic terms (since this was not chosen randomly) but different in detail.  The detail is the fine grain but nevertheless has a consequential effect, and thus a significant part of the compositional process involves choosing among randomly seeded synthesis runs.  Here is an example of a passage that repeats a phrase that seemed especially effective.  

Audio Example 7

http://www.paullansky.org/beingdigital/example7.mp3

These examples create something of a paradox for me.  While I’m happy with the results, I also realize that there are probably an infinite number of possible versions of these pieces that will sound similar on the surface, but differ entirely in detail.  With the power of computers today it is certainly possible to generate these pieces in real time, thus creating the potential for this infinitude of pieces, and also the possibility that things I prefer will be fleeting and disappear.  I’m also faced with the realization that my ‘frozen’ versions of these pieces represent, in fact, just one among many possible instances of the music.  Distribution of a work like this in software rather than audio form is presently feasible though not yet practical.  It does appear, however, that the day is not far off when this will be practical.  This will mean the emergence of a new form of recorded music, different on every hearing.

As listeners, we have long since ceased to be puzzled by an apparent contradiction in our listening worlds.  Every recorded sound carries with it an architectural acoustic signature.  This is simply a series of reflected and diffused images of the signal that gives us clues about the space in which the sound was originally recorded, or in which the composers and audio engineers want us to think it was recorded.   Indeed, it is rare that a recording ever is released that sounds as if it were recorded in an anechoic chamber.  The function of reverberation is to project the image of a sound into a virtual environment that has palpable acoustic characteristics.  But every space we use to listen has its own characteristics as well.  Therefore we have to factor two environments in creating the audio image.

Artificial reverberation provides a penumbra that intensifies the virtual image of a signal.  It helps us to imagine a location, a place, a physical space for it.  While its use is frequently designed to smooth imperfections in a signal this smoothing process is the same one provided by a reverberant space.   The components of digital reverberation are simple: delay lines, feedback loops, and filters, generally low-pass.  While most software reverberators are designed with parameter controls based on the physics of real spaces, wet/dry,  reverberation time, percentage of signal being reverberated, location of the source in a three dimensional space, and so on, the specifics of a reverberant space need not be tied to realistic parameters.  In other words we can create a space where the apparent dimensions are constantly shifting, or where the resonant character of the space reinforces a particular harmonic texture, and so on.   Imagine a room tuned to C major or an echo that rhythmically reinforced a rhythmic motive.  In the following example, Things She Noticed, from my larger work, Things She Carried

[20]

.  the reverberant characteristics of the speech change harmonically from utterance to utterance. 

Audio Example 8

http://www.paullansky.org/beingdigital/example8.mp3

The lack of any reverberation at all in a recorded signal provides an interesting contrast, however.  In most of the electronic works of Xenakis, for example, as well as much of the music of some current electronica artists such as Matmos and Autechre, there is virtually no reverberation at all.  Many of their signals never pass through the air, in fact, and come to the loudspeakers with no acoustic signature at all.  (This is partly because their sounds resist interpretation as the results of human physical activity.)  In this case the world the speakers envelope is not a virtual world in the same sense as the one I have been describing.   The aura of physical reality lies only in the signals themselves, not in an imaginary space they describe.  Loudspeakers have now become actual instruments.   They are no longer vehicles of transduction as much as engines of creation.

Physical modeling is a relatively recent development in computer music, led by Perry Cook, Julius Smith and others.  Rather than attempt to imitate the sounds of real instruments physical modeling uses a toolkit approach in which individual aspects of the physics of real instruments are hobbled together.  To simulate a flute for example,  (greatly simplified) a pressure wave is fed into a filter modeled on a cylindrical tube open at both ends, and the output is mixed with a returning wave.  The model actually behaves like a real flute in that increasing the pressure results in overblowing and results in harmonics.  Here is an excerpt from my work Still Time

[21]

, in which flutes of various sizes combine. 

Audio Example 9

http://www.paullansky.org/beingdigital/example9.mp3

Finally, a whole new area of work has recently emerged as a result of the arrival of processors capable of creating sound in real time with some degree of complexity.  At Princeton, for example, Dan Trueman and Perry Cook

[22]

have been designing controllers that range from traditional forms like violin bows, digereedoos, and percussion instruments, to more unusual objects armed with arrays of sensors.  These controllers generate sound by sending performance data to a computer which then interprets it and synthesizes and processes signals in real-time.  This is another instance of arbitrary mapping but now it is directly connected with physical activity.  To add another level of reality they use spherical speaker arrays so that the sound radiates in 360 degrees, as real sound does.  Embedding significant processing power in the space between human motion and sound represents an important stage in realizing the potential of digital signal processing.  While analog controllers have been around for years, the reconfigurable power of software in this instance completely changes the story.

I hope that I’ve demonstrated that the emergence of digital sound is really a watershed moment in the history of music.  It enables us to harness technology in the service of musical adventure in ways that were unimaginable only twenty years ago. The computer is the ultimate instrument of the imagination.  

Mild und Leise, whose painful creation I described at the outset is now, ironically, perhaps my most famous piece thanks to the English rock group Radiohead, who sampled part of it and used it as the harmonic backdrop for their song Idioteque, on their 2000 album Kid A.  The irony is increased by the fact that it arose in the digital domain, made its way to LP, was sampled from the LP undoubtedly using digital tools, and included in a composition whose sound world is strongly reminiscent of early analog synthesizers (and in fact uses one for the simulated drum track).  Here is the opening of my work.

Audio Example 10

http://www.paullansky.org/beingdigital/example10.mp3

And the opening of Idioteque:

[23]

Audio Example 11

(Kid A,  Idioteque track 8)

[23]

Kid A,  Capitol Records (2002)

Copyright, digital music, and "intellectual property"

Please read/watch the following:

• Copyright Wars and Higher Education (Cornell Event)
• The Download Debate (Cornell Event)
• Some Myths About Intellectual Property

Lecture one review materials

I wanted to follow-up on today's lecture on analog to digital conversion. My hope is both to clarify and provide a resource for further review.  See below and please be in touch with me or with one of your TA's if you have any questions.

Audacity the soundfile editor

Audacity is free, open source software for recording and editing sounds. It is available for Mac OS X, Microsoft Windows, GNU/Linux, and other operating systems.

http://audacity.sourceforge.net

Audacity is a simple yet powerful tool and is recommended for all users for their home systems.  Audacity is not a monolithic solution to every audio situation.  It is simply an audio editor and it performs in that role exceedingly well.  Other available soundfile editors include Peak (also available at Cornell), Cooledit (now Adobe Audition), Sweep, Wavesurfer, Soundforge, Wavelab...and a list of others whose further enumeration would deplete valuable documentation space.  Audacity fulfills the requirement of a powerful editor while being easy to use, light-weight, stable, and free (in both the sense of cost as of liberty...you can grab the sourcecode and change it to suit your needs).

You may also wish to paruse the various online tutorials.  The official Audacity site hosts it's own tutorials here:

http://audacity.sourceforge.net/manual-1.2

But there are several others to be found on the web.  For example here and here.  Of course there are plenty of others.

Beyond the material covered in Music 1421 directly, there are plenty of other novel ways to use Audacity.

Recording Techniques

Learning to create high-quality recordings is central to electroacoustic music.  These techniques also translate directly into recording studio environments, field recording, and almost any other situation which requires audio input.

The core principle is to maximize signal quality on the way in.  As a rule of thumb, this means recording the maximum amplitude without going over the limit while deferring effects like reverb, equalisation (EQ), and other environmental effects to later.  The last part of this is important to note: if one were to record sounds with reverb or EQ that, in the end, sounded unflattering, there is no way to get back the original signal. Think of it like taking a picture, if a shot you took turned out blurry (or the camera's cap was on!), all the sharpening or lighing effects in the world will never get back the original shot.  One could, however, easily manipulate a clear, high-quality shot--blurring or applying other effects--to achieve almost any look.

In seeking the highest quality signal there are a number of important concepts to understand.  Each of these will be discussed in detail in the following sections.

Cubase Docs

Reason by Propellerhead

Propellerhead Reason is a very popular MIDI sequencing, synthesis, and sampling application.  It uses a very old, tried-and-true modular concept, separating the sequencer and "devices".  Hard and soft copies of the official Reason documentation can be found within CEMC studios but more information can be found below.

• Reason User Manual
• Reason Getting Started Guide
• Reason 4 key commands (PDF)
• Video tutorials on Propellerhead
• Reason 4 demo version download for Mac (save/export disabled)
• Reason 4 demo version download for PC (save/export disabled)

 Other more detailed, class-specific tutorials are listed below.

 Class-Specific Tutorials:

Assignment #1, due Wednesday January 30th

IMPORTANT NOTE: All sounds for this assignment should be turned in as WAV or AIFF audio files. You will want to "Export" from Audacity. The ".aup" files that appear when you "Save" are not audio, they are simply Audacity's own "project files.".

This assignment is in two parts, both dedicated to basic recording/capture and editing. The main pursuit, however, is the search for interesting sounds, beginning the process of hearing the world itself as musical.

Part I: Record and edit together a small "library" of sounds using Audacity and either the dynamic (channel 1, shown in class) or condenser (channel 2) microphones in the studios. As shown in class, I recommend a "batch" editing technique, concentrating on capture and discovery followed by editing/isolating and cleanup (fade-it/fade-out, etc). I suggest a resulting 15-20 individual, short sounds, named and organized in whatever way you think appropriate. See my own "sflib" on the "Sound" disk of each studio computer for examples.

Part II: Check out a remote recorder from the Cox Music Library (ask at the reservation desk) and use it to seek out and capture sounds from your environment. Again, try to use this opportunity to listen in new ways to the world around you. Does the intention to record a sound change the way you listen to it? I suggest 3-5 sounds which might be longer events such as a train passing, the hum of a light, the sound of students in a cafateria, water, or whatever interests you.

In both cases, Parts I and II, work to maximize the signal quality as we began to do in class.

Please put everything into a folder named:

24210_assign1_netID

...where "netID" is your netID. ZIP up the folder as a "ZIP archive" and copy the result to the "Network Drive", linked on the Desktops of all studio computers. You will see a folder their for "Assignment_One". Check the site FAQ if you have problems with the hand-in.

Assignment #2, due Wednesday February 13th

NOTE: In an effort to solve the confusion and technical problems accessing the Network Drive to hand in finished assignments, please see this brief post or check the UPDATED site FAQ on handing in assignments.

http://digital.music.cornell.edu/cemc/content/sound-disk-and-network-drive

The goal of this assignment is to explore the editing/looping/slicing tools showcased in our lab session, aiming toward a "mashup" or remix of existing musical materials as we did with "The Jackson Six".  Where tempo or musical key matching is a consideration, please use the techniques we discussed and practiced in class.

Be creative, experiemental, and TRY SOMETHING NEW. I am inviting you to play, to stretch out, and to use some very powerful tools in the Live editor.

The result should be a stereo recording of a "performed" piece, exported as a WAV or AIFF audio file.  Map the clips and/or "scences" in Live via MIDI and/or the text keyboard to create a live performance, recorded, as we have done several times now, into the arrangment view.  You may find "scenes" useful as a way of moving through a musical form (into, verse, chorus, etc).  The result should be a short (1-2 minute) piece exported to WAV or AIFF format.

Please give me:

1. The Live project itself (it will be a Live folder with several subfolders and a .als "song" file)

 ---> I recommend using "Collect All and Save..." in the file menu to make sure all samples are copied/collected into this same root folder. Note: This is also a way to make Live projects portable between several computers.

2. The stereo WAV or AIFF audio file

The naming convention should also be retained:

2421-assign2-netID-title_if_any

If you plan to sample sources from video (online or otherwise), I recommend MPEGStreamclip (Beta version is recommmended) as a way to separate audio from video.

Finally, this assignment may freely include "commercial sources" as it is educational and will only be shared with me for the purposes of this assignment. You are not doing anything that has not been done for time immemorial, except you are doing it digitally!

Project #1, performances on February 25th and 27th

On February 25th and 27th, we will have the first of our in-class concerts.  Your performance should consist of a short (~3-5 minutes) piece of music in the style of your choosing, building upon the ideas and techniques discussed in class.  You are free to use your own resources in constructing the materials of the piece, but you must use Ableton Live for the live performance.  I will supply the machine, a laptop, along with a Kontrol49 keyboard and Novation Launchpad.  A microphone or microphones will also be available, and you may request addition items or supply them on your own (instruments, microphones, sensors, etc).  For this first project, please try to minumize your setup time, bundling your Ableton project using "File-->Collect All and Save..." and/or "Freeze effects..." to make your project portable.  We will discuss this strategy further in class.

As you imagine the design of your performance patch, I highly encourage you use this rule-of-thumb: don't touch the mouse.  This is, of course, somewhat artificial constraint but helps move the performance beyond the technological and into something physical and musical.

We will discuss scheduling, logistics, and performance order together in class.

Project #2, performances on April 8th and 10th (Week 12)

Project #2 is explicitely collaborative.  Student should seek out and form small groups of between 2 and 4 (max) to imagine and construct pieces utilizing techniques from the course thus far.  Because of the collaborative aspect of this project, you are free to develop something on a slightly larger scale then you might have on your own.

You are not required to use any particular piece of software/hardware (Live, PD, etc), I would encourage you to explore beyond the confines of what you already know and into the realm of experimentation.  If you have questions or need help, direct or advising, on any project idea please don't hesitate to ask.

Copyright, DRM, format wars, and more

Below are readings and articles related to the ongoing format wars, copyright debate, and digital signature technologies for music.

Shure Microphone Techniques

See attached, the PDF document I mentioned from class showing several techniques and strategies for microphone type selection and placement.

Assignment #1, Due Monday February 9th

Begin looking for video sources, potential short clips (1-2 minutes) to use as a source video for your first sound and music setting.  This is the video clip you will be using for the next couple of weeks so choose something of interest to you, something you think you like and think you might enjoy working with.

Here are several samples (each around 1-2 minutes, sound removed) for those who would rather have the source video supplied (right-click image and choose "Download as..." or similar):

a) Video from class (MTV-style sound removed)

Excerpted from "Stop" by Eoin Duffy on blender.org, 2007 Suzanne Awards WINNER of "Best designed short film"

b) Slow moving animated blob

Excerpted from "Meischeid" by Matray on blender.org

c) HD video (1080p) with characters (may take a long time to dowload!!)

Excerpted from the "Orange Open Movie project", Elephant's Dream

If you have any trouble viewing this or any other video source, download and use VLC as your default video player.

1. Using recording techniques discussed in class in combination with sounds from sflib (the CEMC soundfile library) or freesound, compile a library of sounds appropriate to your chosen video source.  You may wish to check out a hand-held recorder to make environmental or other recordings.  The result should be a minimum of 50 sounds sorted in a meaningful way with directories and subdirectories (or "folders" and "subfolders").  I would encourage you to make "families" of related sounds or variations of a single sound.

Please hand in the resulting folder using the network drive, on the CEMC desktop as "coursework-->MUSIC_3421".   See this FAQ for other suggestions about naming.

Assignment #2, Due Wednesday April 1st

Using Ableton Live, create a score for one of the Mars Rover video clips found on the "network drive --> coursework-->Music_3421-->Materials-->Class_3-25", the clips used in our tutorial session Wednesday afternoon.  To do this you should:

1. Load the video track into the Arrangment view (horizontal track view) so that it starts at the beginning of the "live set".

2. Using the "Session view" (verticle track view) and clips, perform a score along with the video.

3. When you are satisfied with your performance, record the result back into the Arrangment view by arming the master record and beginning to play.

If you have trouble getting started with Live, please see the built in Tutorials discussed in class.  Of course, you can always seek the help of myself, Chris, or Eric.

The result should be, as before, the short video clip with your score as the sound track.

Assignment #3, Due Monday April 6th

Create the following three short patches.  Refer to the attached "Sources" patch for the objects you will need.  You will not need any objects beyond what is shown there.  Words inside of brackets [  ] below are supposed to represent PD object names.

Patch #1:

Create two oscillators [osc~].  Wire them separately to [dac~] outputs 1 and 2 respectively.  Set their frequencies so that you hear a beating of 4 pulses per second.

For help see PD's "Help-->Browser" and in the folder "3.audio.examples" look for example "A08.beating.pd".

Patch #2:

As with patch #1, create two oscillators [osc~].   Using an audio multipler object [*~], multiply the two oscillators [osc~] and set their frequencies so that you hear a beating of 4 pulses per second.  You may need to recall the idea of "amplitude modulation" where one [osc~] is the "carrier" and the other is the "modulator". 
Connect the output of [*~] to [dac~] outputs 1 and 2.

Patch #3:

Build a patch that analyses the pitch of an incoming microphone signal [adc~] with [fiddle~].  Convert [fiddle~]'s MIDI pitch to frequency with [mtof] (MIDI to frequency) and use this number to set the fequency of an oscillator [osc~].  Connect the output of this oscillator to [dac~] outputs 1 and 2.

Hint: Use [fiddle~]'s first outlet, not the third!

REMINDERS:

1) When using PD, you must toggle between "Edit" mode where you can make new objects, move them around, wire them together, change their argumements/values and "Performance" mode where you can interact with the patch.

2) In order to hear sound through PD, you may have to check the box "Compute Audio" on PD's main window.  This check box stops and starts ALL audio processing in PD.

Assignment #4, Due Monday April 13th

This assignment has two parts, one audio and one video using PureData and Gem.  Each part comes with its own incremental tutorial (explained below), a set of patches that build piece by piece toward a larger concept.  The goal is to accumulate a set of basic skills and then from them, extrapolate to build something more interesting.  Each resulting patch should not take you much time to make, the key is to grok the concepts relayed in the tutorial in order apply it your work.

Part I: Audio

PD TUTORIAL: PD_Tutorial.zip

Download "PD_Tutorial.zip" above and uncompress it into a folder.  This folder contains a series of numbered patches, each incremental, building upon one another toward a larger idea.

Here we are building a bank of bandpass filters, similar to the example from class.  Patch #1 begins with one filter on a white noise signal [noise~].  Patch #2 uses 3 filters with difference center frequencies (sounding like a chord).  Patch #3 adds control to the center frequencies via send/receive pairs, thus allowing for 3 different "chords" (you might wish to try creating more than this).  Patch #4 adds the idea of "movement".  The new chord frequencies are not sent directly to [bp~]'s center frequency.  Instead they go a set of [line] (linear ramp) objects.  The center frequency therefore "moves" from one tone to the next (in this case over 5000 milliseconds, 5 seconds).  Note too that this last patch has amplitude/volume control for each [bp~] group (!)...simply an audio multiplier [*~].

Assignment: Build a patch that has half-a-dozen bandpass filters on a white noise signal.  You may wish to use subpatches [pd name] to accomplish this task and keep everything neat and organized.  Use the same [line] automation method to move amplitudes or each filter (you will use the audio multiplier [*~] object).

Part II: Video

GEM TUTORIAL: Gem_Tutorial.zip

Download "Gem_Tutorial.zip" above and uncompress it into a folder.  This folder contains a series of numbered patches, each incremental, building upon one another toward a larger idea.

MAKE SURE TO CLOSE ONE PATCH BEFORE OPENING ANOTHER SINCE ALL PATCHES WRITE TO THE SAME GEM WINDOW AND WILL OVERLAP ONE ANOTHER!

Here we will be building a video mixer (!!).  Patch #1 simply shows the use of [gemhead] to draw a square.  You have to create the Gem window first, click [create ( in the upper-left to so this.  Note that all cumulative additions to our video mixer patch will happen between [gemhead] and [square].  Patch #2 shows our first "drawing" on the square, chaning its color.  Patch #3 shows a second manipulation, this time an object to rotate the square [rotateXYZ]. Patch #4 is the same thing but with a second square.  Note the use of a second [gemhead].  Patch #5 shows shows how to add images into a shape...use one of the included Da Vinci "Last Supper" images as examples.  Patch #6 shows how to "mix" multiple images onto one single shape.  This time try using "da_vinci-norm" and "da_vinci_flipped" as the two images.  Move the image "crossfader" and you should see the two images mixed.  Patch #7 finally shows how to draw a movie/film onto a shape...essentially it is not different than an image.

Assignment: Create a patch that mixes two videos (or, using the included video clip, mixes one video with itself, perhaps with delay starts).  You will simply be combining Patch #6's mechanism for mixing images [pix_image] with Patch #7's mechanism for loading video. In other words, [pix_mix] doesn't care if it gets images or video.

Critique #1, Monday February 23rd

For our first Critique, please be prepared with your finished 1-3 minute film clip and score including music, sound effects (as required), dialogue, etc .  We will not see all of them together in class but will get to many.  The rest will be uploaded to the web and receive comments outside of class.  More information on that in Lecture.

Your clip should be synced with the original video (not the draft quality you may have used while working) and ready for us to evaluate together as a "finished" piece.

Project #1, due March 11th

Your first project should be a short, 3-5 minute musical/sound score of a "fixed media" selection.  For most students this will be a scence or clip from a longer film.  Some are producing the images/film themselves or in collaboration with others within and/or beyond class. Recall, too, that our class was provided with several short clips by Marilyn Rivchin in the film department.  Those two clips are available on the network drive under "Music_3421-->Materials".  They include some dialog and even ambient sounds but no music.  Both present interesting challenges for us.

If you are in need of a source beyond these, feel free to consult Professor Ernste or one of the TA's for suggestions or help.

We will present the resulting short films/scores in class on March the 11th as a "showcase", running the films one after the other.  We will discuss proper formats and other considerations for this showcase in class on Wednesday the 4th of March.

Puredata and Gem

Puredata and Gem

Assignment #1

PRACTICAL

As an initial foray into Unix, please get comfortable with the contents of the CEMC soundfile library.  To list the directories in sflib, run the command:

lsfl

(list soundfile library)

The command "lsfl choir" will list the soundfiles in the library directory "choir".  To play any file you find in the libary, simply type:

psfl NAME_OF_SOUND_TO_PLAY

So, to play the file "stockhausen_gesang.wav" (this is the file we listened to in class together, you are welcome to listen again), simply do:

psfl stockhausen_gesang.wav

The command psfl will search the soundfile library and find the file on it's own.

To search for files in the library by name (character string), use findsflib, for example to search for all of the sounds with the pitch C4, do:

findsflib c4

The findsflib command will allow you to play the soundfiles as they are found by adding the flag "-p" to the command.

findsflib -p drum

Remember that Ctl-C (Control - C) will stop any command in process, useful if you don't want to wait for sflib to find further sounds in the library.

READINGS AND LISTENING

Please read the following essays.  You may also wish to research concepts of musique concrète, computer music, and electronishe musik as it was understood on the early 1950's.

Karlheinz Stockhausen's Gesang der Jünglinge

History and Analysis (PDF)

Through the Sensory Looking Glass: The aesthetics and Serial Foundations of Gesang der Jünglinge (JSTOR link)

To listen to Gesang in the studio (quad version), use the psfl command shown above:

psfl stockhausen_gesang.wav

Pierre Schaeffer's Etude aux Chemins de Fer (Railroad study)

Pierre Schaeffer's Etude aux Chemins de Fer (Railroad study), youtube

Assignment #2

Software:

Using Score11 example "granflute" as a base, create your own granular "clouds".  You may wish to use your own sounds, documentation for mksffuncs (for creating Csound functional tables) is available here.  For those needing a more general reminder, documentation for Score11 including the original "quick start" guide I handed out in class is here.

Reading:

Chapters from Curtis Roads' book Microsound (e-cornell publication)

1. Time Scales of Music

3. Granular Synthesis

7. Microsound in Composition (optional, discussion of pieces using granular)

8. Aesthetics of Composing with Microsound (optional, good breadth)

Listening (see listening list for CD numbers):

Kontakte (with piano and percussion) - Karlheinz Stockhausen

Concrete PH - Iannis Xenakis

Vox 5 - Trevor Wishart

Idle Chatter; More Idle Chatter; Still More Idle Chatter; etc - Paul Lansky

timfeeney_homework.wav in /sflib/listening (psfl timfeeney_homework.wav)

Basic Unix Commands

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.

• Score11 Quickstart
• Score11 Manual (online version)
  

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 by room as follows:

b27.music.cornell.edu
b25b.music.cornell.edu
b25c.music.cornell.edu
b25d.music.cornell.edu
digital.music.cornell.edu (server system)

On CEMC systems, convenient command shortcuts are also available using a standard syntax:

sshb27 (same as ssh b27.music.cornell.edu)
sshb (same as ssh devel.music.cornell.edu)
sshb (same as ssh b25d.music.cornell.edu)
sshc (same as ssh b25c.music.cornell.edu)
sshd (same as ssh b25d.music.cornell.edu)
sshdig (same as ssh digital.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.

mksffuncs usage summary

MKSFFUNCS usage summary

mksffuncs – A  script that creates Csound gen1 function definitions for soundfiles in a format suitable for inclusion in SCORE11 input files.

Usage:

mksffuncs [-flag(s)] infile1 [infile2] [infileN] [> outputfile]

where valid flag options are

-f : the following argument(s) are ascii files containing
lists of soundfiles, rather than the names of soundfiles
-s : before creating the functions, sort the soundfiles by
pitch abbreviation (lowest to highest pitched, then unpitched)
-N : (must be in CAPS) the next argument gives the number for the first
(lowest numbered) function definition

Multiple flag option can be given one at a time or concatenated. Soundfile arguments are the names of soundfiles in your current working soundfile directory or in any of the 44.1 k or 96 k sflib directories.
To include soundfiles from one of your soundfile subdirectories, include the subdirectory name or the full path name.

Examples:

(1) mksffuncs irishwhist.short.a4.wav fl.c4.wav

Result: Function definitions are created for the 44.1k sflib soundfiles wind/irishwhist.short.a4.wav      and wind/fl.c4.wav:

* f1 0 262144 -1 "irishwhist.short.a4.wav" 0 0 0 ; < 3.473 sec
* f2 0 262144 -1 "fl.c4.wav" 0 0 0 ; < 3.473 sec

(2) mksffuncs -N 20   irishwhist.short.a4.wav fl.c4.wav

Result: same as above, but  function numbers begin with f20 rather than f1

* f20 0 262144 -1 "irishwhist.short.a4.wav" 0 0 0 ; < 3.473 sec
* f21 0 262144 -1 "fl.c4.wav" 0 0 0 ; < 3.473 sec

(3) mksffuncs -fs playlist1 playlist2
(or mksffuncs -s -f playlist1 playlist2)

Result: Functions are made for the soundfiles listed in ascii files "playlist1" and "playlist2" and        are sorted from lowest to highest pitched."

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

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.

Class patches and examples

Below are patches and examples from class.

PD docs and information

Below is an assemblage of resources for Miller Puckette's graphical programming enviroment, PureData or PD.  The list of items will grow as time goes by and as new items become available.  The PD community is, by philosophy, inclined to freely contribute to its development, offering their own insights back to the community of users.  Feel free to avail yourself of the rescources beyond documentation such as the mailing lists and "pd webring" pages and become a contributing community member yourself.