The Cornell Electroacoutic Music Center host courses for both graduate and undergraduate students from a variety of musical backgrounds.
Music 1421 is a composition-based introduction to computer hardware and software for digital sound and digital media. Ability to read music may be helpful but is not required. The course focuses on fundamentals of digital sound, MIDI sequencing, and other techniques for producing electroacoustic music. Each student will create several short compositions throughout the semester.
Below are the assignments for Music 120. New assignments will be added as they are given. Note that some assignments include reading, usually online, so please read carefully for links to external pages.
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.
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":
(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:
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.
University of Iowa Electronic Music Studios (musical instrument samples)
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!)
You may wish to remind yourself of the Subtractor's basic configuration:
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.
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!
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.
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
Below are assigned readings for Music 1421.
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
. 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.
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
. 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
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.
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
. 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
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.
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.
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.
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/100th 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.
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.
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.
In this example the frequencies of an arrangement of the Brahms Lullaby are mapped onto the timbres of a vocal work by Perotin.
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
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
, 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.
the same parameters are mapped onto piano sounds
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
in 1984, use randomness as a generator of foreground detail.
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.
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
. the reverberant characteristics of the speech change harmonically from utterance to utterance.
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
, in which flutes of various sizes combine.
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
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 11
(Kid A, Idioteque track 8)
Eric W. Rothenbuhler and John Durham Peters, “Defining Phonography: An Experiment in Theory”, Musical Quarterly, Vol. 81/2, (1997) 242-264.
In recent years ‘plug-ins’ for digital-audio editing programs have been created to simulate the sounds and artifacts of LP’s and analog devices. Perhaps this is an attempt to reinsert the voice of another individual in the chain from the creator to the listener.
While it is too soon to assess the longevity of digital storage media, the fact that data can be copied with perfect accuracy further separates digital from analog media. Anyone who has tried to play a twenty-five year old tape (there are some that have to be baked in an oven before they can be played only once), or revive an old LP is well aware of the extreme fragility of these storage formats.
James Lastra, Sound Technology and the American Cinema (New York, Columbia University Press) 2000.
Jazz, in many of its manifestations, may be the exception. The role of individual virtuosity in jazz performance would clearly be violated by overdubbing and too much editing.
Kenneth Steiglitz and Paul Lansky, “Synthesis of Timbral Families by Warped Linear Prediction”, Computer Music Journal, vol. 5/3, pp. 45-49, (1981).
All audio examples can be accessed from a single page at http://www.paullansky.org/beingdigital.html
Corey Cheng’s thesis at Dartmouth www.eecs.umich.edu/~coreyc/thesis/thesis_html/title.html#titlepage and a paper by Tzanetakis, Essel and Cook at Princeton
soundlab.cs.princeton.edu/publications/2001_amta_aadwt.pdf) provide a good introduction to the musical applications of Wavelet Transforms.
www.music.princeton.edu/~dan and www.cs.princeton.edu/~prc
Kid A, Capitol Records (2002)
Please read/watch the following:
All documentation below can be accessed in hard copy within Studios B, C, and D. Online documentation often contains additional resources such as video demonstrations and tutorials. Feel free to supplement this existing information with a Google search, particularily when the question relates to unfamiliar terminologies or technical details. Or post your question directly to the forums where other students are probably lurking and wondering the same thing.
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.
The conversion of a raw audio signal into a digital representation is known as quanitization. The continuous, real-world audio signal, representable as a smooth waveform with positive and negative pressure levels, is recorded in a series of snapshots known as "samples". Each sample is, like a frame of video, a picture of the signal at that moment. Specifically, it is a picture of its amplitude. That, in the end, is all the recording system cares about: "what is the amplitude?". The succession of these amplitude measurements ("samples", shown below as dotted lines) results in a digital approximation of the original audio signal. The frequencies and notes we hear are the result of these changing amplitudes over time.
For every digital sample, our analog to digital converter asks "what is the amplitude?". The question that remains is, how is this amplitude represented? The answer is "bit depth" which determines both how many different amplitude levels/steps are possible and what the overall capacity of the system is...how loud of a signal it can tolerate.
For CD-quality sound, 16 bits are used. This means we will have 2^16 ("two to the 16th power") different amplitude values available to us, or 65,536 steps. Since the number of steps is divided between positive and negative values (our crests and troughs from before) this means it is divided into 32,767 positive (plus zero) and 32,768 negative values. For each sample taken, the actual amplitude must be "rounded" to the nearest available level...producing another "error" relative to the original audio signal. The signal is "quantized". This "quantization error" produces as small amount of "quantization noise", noise inherent to digital recording. A digital system is totally noise-less on its own, but as soon as it is recording a signal, it makes these errors and ends up with this small amount of noise.
The amount of inherent noise versus the system's capacity for the desired signal is called the signal-to-noise ratio, a concept I will illustrate in the next installment. The signal-to-noise determines both how loud and how soft a signal can be cleanly recorded. It determines the recording's "dynamic range".
The overall amplitude capacity of an digital system can be theoretically approximated as 6 decibels per bit. For our 16-bit CD-quality signal, this means our system can tolerate 96 dB.
So, is 16-bits enough? The threshold of hearing or the threshold of pain varies among individuals, but is often cited as 120 or 130 dB. So it may be that--unlike the CD-quality sampling rate and its accommodation for the range of human hearing--our 16-bit system is not enough. If one is not careful when recording, a signal can easily exceed the maximum amplitude, producing "clipping". In clipping, the waveform hits its amplitude ceiling resulting is a cropped waveform.
The changing peaks above the maximum amplitude end up flattened. The naturally fluctuation amplitude levels are just chopped off and the resulting sound is jarring and distorted. Increasing the bit depth will provide more amplitude "headroom" for these louder signals. 24 bits, for example provide 2^24 (over 16 million!) amplitude steps and 144 dB of theoretical overall capacity (24 x 6 dB). So, a higher bit depth has a higher tolerance for ampltude, up to and beyond our "threshold of pain".
As an added benefit, this higher bit depth also results in less inherent noise (!!). Our signal-to-noise, therefore gets a two-fold benefit: more capacity for our signal and less inherent noise.
The long and short of this is, if you have a higher- bit depth system available to you, absolutely use it. Of the two possible changes one can make to a digital conversion system, sampling rate and bit depth, the increase in bit depth will have the most profound impact on audio quality. You will also help increase the signal-to-noise ratio, avoid clipping, as the system can tolerate higher amplitudes before going over.
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.
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:
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.
One of the first and most important concept to understand for recording is signal-to-noise ratio. In analog systems, this refers to the available bandwidth for the signal relative to the noise inherent in its physical system (circuits, recording medium).
In the digital realm there is no inherent physical noise (except where it interfaces with the analog realm) except during the process of quantization. Our goal in the digital world is to maximize the signal relative to this quantization noise, a value determined by the number of bits the recording system is using. We want to excite as many of these available bits as possible, filling them with signal to overcome the quantization noise. To do so is a matter of signal resolution, not of volume.
A "gain stage" is any point in the signal path where a gain boost or attenuation is available. In other words, it's any place in the chain where you have amplitude control, such as the output knob on an electric guitar, or the input level on an amplifier, etc.
Let's use the hypothetical guitar/amplifier signal-path scenario to illustrate the importance of gain staging. Say our guitar player turns the volume/output knob on his instrument almost all the way down, while turning the amplifier input all the way up. In this case, the amplifier is being taxed to compensate for the guitar's weak signal. The result will be a very thin sound for the guitar as well as an unpleasant amplification of circuit noise inherent in the amplifier. We are not maximizing our signal at all...and may in fact be harming our amplifier.
Now let's reverse the scenario, the guitar level is "cranked" while the amplifier input is almost to nothing. Here again the problems are both timbral/aural and physical. The amplifier is not taking advantage of the incoming signal, acting as a barrier to the guitar rather than a support. Regardless, the overfed guitar signal might be overloading the amplifier input, causing physical damage.
The above is a simple case. Yours will be more complex including 3 and 4 gain stages. You will need to understand your signal path fully in order to get the best results.
Again to repeat a rule of thumb: the shorter the path, fewer signal traps along the way. You will have gain stages where the signal must be raised or lowered while the ideal of many gain stages is to be transparent, to simply pass along the signal without impacting it, without boosting or attenuating.
Recording with a microphone
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.
Other more detailed, class-specific tutorials are listed below.
The Subtractor is Reason's virtual synthesizer which combines several synthesis types into a whole. It features wavetable synthesis (the actual sound generators, the waveforms), subtractive synthesis, and several levels of modulation (pitch, amplitude, filter frequency, phase, etc). Understanding the signal path within this network of sound producing and sound modifying modules will help you grasp just what the Subtractor can do.
First, the two available oscillators (VCO, Voltage Controlled Oscillator) constitute the sound source. There are classical oscillators such as the sine wave, triangle wav, square wave, sawtooth wave, etc. But Reason has it's own family of waveforms, some imitating the timbre of acoustic sounds. A complete description of each availabel waveform along with playable soundfiles can be found here. You will find this page useful as a reference.
Second, the new waveform passes into the filter-section (VCF, Voltage Controlled Filter) where various filter types (high-pass, low-pass, band-pass, notch) alter the spectrum of the original oscillator. This is the "subtractive" portion of the Subtractor and where a lot of the magic happens. Filters can give life to otherwise static timbres.
The third step is allows you to control the waveform's amplitude envelope (Voltage Controlled Amplitude). Here the standard ADSR envelope is used.
There are four parts to the envelope, one for each of A-D-S-R:
They all are sequentially setting in, a key is pressed.
-Attack controls how fast a signal goes from zero to maximum level.
-Decay determines the amount of time it takes for a signal to decay to the Sustain level.
-Sustain is important for the level which is held until a note ends.
-Release, finally, how fast the envelope fades to zero, to be precise, how long a note keeps on sounding after the MIDI key is released.
Subtractor's section four allows one to apply an ADSR envelope to the modulator and the filter. These are time-varying envelopes just as with amplitude. As with the amplitude envelope, this shape gives the note a dynamic character, this time affecting it's timbre.
Finally in stage five the signal is modulated by an LFO (Low Frequency Oscillator). This LFO can modulate any one of several parameters of the sound. Toggling through the various modes you will hear how this impacts the timbre. LFO's are slow-moving waveforms which are used to modulate some aspect of the original "carrier" signal, creating motion within the sound, giving it richness and life. Notice that LFO 2 has something that LFO 1 does not: a delay. This allows the modulator to be activated at some time later than the initial attack.
You might wish to see the video tutorial for the Reason vocoder on the Propellerhead site.
Here is some other readng background on vocoding, more historical details will be discussed in lecture.
Music 1421: Introduction to Computer Music, Fall 2011
Kevin Ernste, Professor
Office: 108 and B27 Lincoln Hall
Taylan Cihan, firstname.lastname@example.org
—> Office hours: Tuesday-Thursday 12 -1PM
Yuan Peiying, email@example.com
—> Office hours: Monday 3:30-5pm, Friday 10-11:30am, Library Lab
Music 1421 is an exploration of classical and state-of-the-art techniques for making music with computers. As such, a substantial portion of our time will be spent working with software directly, although “learning software” is not our explicit goal. As computer software has developed, several design metaphors have emerged: the soundfile editor, the multi-track mixer, the synthesizer, the sequencer, the modular programming environment, the audio patchbay/mixer, and several others focused on live performance. In this course we will examine a number of these, working toward developing our own toolkits for creative work.
In addition to commercially available software, students will be introduced to a number of excellent free software tools, many with unique designs and functionality. These tools will be made available for download on this website. Further details will be forthcoming.
Course requirements include three composition projects, one for each of the three parts of the course (see the semester schedule below). The last of these will be presented at the Sound Art Forum concert at the semester's end. In addition, there will be weekly or bi-weekly assignments to be carried out on the student's own time. Studios are available for this purpose and students may sign up for individual time slots. Visit the course website and follow the “studios” link to sign up online.
Grading for the semester is broken down as follows:
10% Class participation (make yourself heard in class and online)
10% Oral examination
20% Weekly/bi-weekly assignments
30% Two mid-semester projects (15% each)
30% Final project and performance
All work must be turned in on time. Late work will be given one letter grade lower, beyond one week it will not be accepted. The final performance is mandatory and non-participation results in automatic failure (participation and final project grade percentages lost).
Assignments should be turned in online in the studio network drive linked on the studio Desktops. Within the directory “music_1421” you will see a directory with your NetID.
Facilities: Studios B25B, B25C, and B25D will be our primary studios with additional workstations in the Music Library Computer Lab. Beyond Lincoln Hall, some of the software used in Music 1421 is available for use at the Uris Library CL3 (Creation Station) facility. You are encouraged, of course, to use your own systems where appropriate.
Optionally, web space is available as a relay for your work to and from the studios. Studio web traffic is closely monitored so use this benefit only if you plan to use it appropriately. I also highly encourage regular backups of your ongoing work. Unfortunately we still cannot depend on computer hardware particularly hard drives as the last critical devices with moving parts.
Tuesday meetings are lecture and discussion periods, exploring conceptual and compositional/musical ideas. Thursdays will be practical, lab sessions devoted to developing skills with software and class concepts. Thursday sessions will meet in the library teaching lab unless otherwise noted.
Tuesday meetings are lecture and discussion periods, exploring conceptual and compositional/musical ideas. Thursdays will be practical, lab sessions devoted to developing skills with software and class concepts. Thursday sessions will meet in the library teaching lab unless otherwise noted.
PART I: Digital Audio
< Week 0 — August 25th
Course Introduction and Discussion
< Week 1 — August 30th and September 1st
Digital Audio Fundamentals, Audio Recording Techniques
< Week 2 — September 6th and 8th
Audio Editing, Sample Preparation, and Sound file Libraries
Oral Examination, Thursday September 8th: individual times to be set
< Week 3 — September 13th and 15th
Principles of Multi-track Mixing and Mastering
< Week 4 — September 20th and 22nd
Signal Processing (effects, filters, resampling, dither) Techniques
PART II: Synthesizers, Samplers, and Sequencing
< Week 5 — September 27th and September 29th
Introduction to MIDI
Project 1 due Thursday September 30th; project listening/discussion
< Week 6 — October 4th and 6th
Synthesizers (hardware and software)
< Week 7 — Fall Break and October 14th
Synthesizers and Sequencing, MIDI key mapping
< Week 8 — October 18th and 20th
Advanced MIDI; Inter-application Connectivity
< Week 9 — October 25th and 27th
Hardware controllers, DIY Music, Modularity
PART III: Composition and Performance
< Week 10 — November 1st and 3rd
Live Performance Techniques, Loops, and Real-time Processing
Project 2 due Thursday November 3rd; Thursday project listening/discussion
< Week 11 — November 8th and 10th
Loops, Real-time Processing
< Week 12 — November 15th and 17th
Modular Programming and Interactivity
< Week 13 — November 22nd (and Thanksgiving Break)
Formats, Distribution, Production, and Musical Propriety in the Digital Age
< Week 14 — November 29th and December 1st
Final thoughts, Concert Preparations; Final Project due at Sound Art Forum performance
Final Concert: Sound Art Forum, Saturday December 3rd, 3pm, Lincoln Hall B20
Music 2421 is an exploration of techniques for live performance with computers. We will explore several performance metaphors: DJ, interactive, multimedia, installation, and others, engaging with a broad array of software and hardware combinations with a focus on their actual and potential creative uses.
All weekly assignments for Music 2421 are listed below. Many contain links to external resources.
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:
...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.
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.
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:
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!
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 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.
Below are assigned readings of interest to students of Music 2421. Some are offered as assignments, but most are listed to stimulate thought and, when desired, discussion.
Below are readings and articles related to the ongoing format wars, copyright debate, and digital signature technologies for music.
"For more than a decade, we’ve been waging a war on our kids in the name of the 20th Century’s model of “copyright law.” In this, the last of his books about copyright, Lawrence Lessig maps both a way back to the 19th century, and to the promise of the 21st. Our past teaches us about the value in “remix.” We need to relearn the lesson. The present teaches us about the potential in a new “hybrid economy” — one where commercial entities leverage value from sharing economies. That future will benefit both commerce and community. If the lawyers could get out of the way, it could be a future we could celebrate." - Lawrence Lessig
Original URL: http://news.bbc.co.uk/2/hi/technology/4675280.stm
By Ian Youngs
Libraries have warned that the rise of digital publishing may make it harder or even impossible to access items in their collections in the future.
Many publishers put restrictions on how digital books and journals can be used.
Such digital rights management (DRM) controls may block some legitimate uses, the British Library has said.
And there are fears that restricted works may not be safe for future generations if people can no longer unlock them when technology evolves.
The British Library spends £2m of its £16m annual acquisitions budget on digital material, mainly reference books and journals.
This is going to be one of the significant challenges for us over the next few years Dr Clive Field, British Library
Libraries are allowed to give access to, copy and distribute items through "fair dealing" and "library privilege" clauses in copyright law.
But as publishers attempt to stop the public illegally sharing books and articles, the DRM they employ may not cater for libraries' legal uses.
"We have genuinely tried to maintain that balance between the public interest and respecting rights holders," Dr Clive Field, the British Library's director of scholarships and collections told the BBC News website.
"We are genuinely concerned that technology inadvertently may be disturbing that balance, and that would be unhelpful ultimately to the national interest."
We have grave concerns about the potential use of DRMs by rightholders to override existing copyright exceptions.
In written evidence, the Libraries and Archives Copyright Alliance (Laca) said there were "widespread concerns in the library, archive and information community" about the potentially harmful effects of DRMs.
"We have grave concerns about the potential use of DRMs by rightholders to override existing copyright exceptions," its statement said.
In the long term, the restrictions would not expire when a work went out of copyright, it said, and it may be impossible to trace the rights holders by that time.
"It is probable that no key would still exist to unlock the DRMs," Laca said. "For libraries this is serious.
"As custodians of human memory, a number would keep digital works in perpetuity and may need to be able to transfer them to other formats in order to preserve them and make the content fully accessible and usable once out of copyright."
In its written submission to the group, the British Library said DRM must not "exert excessive control on access to information".
"This will fundamentally threaten the longstanding and accepted concepts of fair dealing and library privilege and undermine, or even prevent, legitimate public good access."
Fair dealing and library privilege must be "re-interpreted and sustained for the digital age", it added.
Dr Field said: "This is going to be one of the significant challenges for us over the next few years."
Posted by kdawson on Tuesday February 06, @03:42PM
- from the not-my-fault dept.
Another anonymous reader tips an essay by Steve Jobs on the Apple site about DRM, iTunes, and the iPod. Perhaps it was prompted by the uncomfortable pressure the EU has been putting on Apple to open up the iPod. Jobs places the blame for the existence and continuing reliance on DRM squarely on the music companies. Quoting:
"Much of the concern over DRM systems has arisen in European countries. Perhaps those unhappy with the current situation should redirect their energies towards persuading the music companies to sell their music DRM-free. For Europeans, two and a half of the big four music companies are located right in their backyard. The largest, Universal, is 100% owned by Vivendi, a French company. EMI is a British company, and Sony BMG is 50% owned by Bertelsmann, a German company. Convincing them to license their music to Apple and others DRM-free will create a truly interoperable music marketplace. Apple will embrace this wholeheartedly."
Continued discussion here:
February 6, 2007
With the stunning global success of Apple’s iPod music player and iTunes online music store, some have called for Apple to “open” the digital rights management (DRM) system that Apple uses to protect its music against theft, so that music purchased from iTunes can be played on digital devices purchased from other companies, and protected music purchased from other online music stores can play on iPods. Let’s examine the current situation and how we got here, then look at three possible alternatives for the future.
To begin, it is useful to remember that all iPods play music that is free of any DRM and encoded in “open” licensable formats such as MP3 and AAC. iPod users can and do acquire their music from many sources, including CDs they own. Music on CDs can be easily imported into the freely-downloadable iTunes jukebox software which runs on both Macs and Windows PCs, and is automatically encoded into the open AAC or MP3 formats without any DRM. This music can be played on iPods or any other music players that play these open formats.
The rub comes from the music Apple sells on its online iTunes Store. Since Apple does not own or control any music itself, it must license the rights to distribute music from others, primarily the “big four” music companies: Universal, Sony BMG, Warner and EMI. These four companies control the distribution of over 70% of the world’s music. When Apple approached these companies to license their music to distribute legally over the Internet, they were extremely cautious and required Apple to protect their music from being illegally copied. The solution was to create a DRM system, which envelopes each song purchased from the iTunes store in special and secret software so that it cannot be played on unauthorized devices.
Apple was able to negotiate landmark usage rights at the time, which include allowing users to play their DRM protected music on up to 5 computers and on an unlimited number of iPods. Obtaining such rights from the music companies was unprecedented at the time, and even today is unmatched by most other digital music services. However, a key provision of our agreements with the music companies is that if our DRM system is compromised and their music becomes playable on unauthorized devices, we have only a small number of weeks to fix the problem or they can withdraw their entire music catalog from our iTunes store.
To prevent illegal copies, DRM systems must allow only authorized devices to play the protected music. If a copy of a DRM protected song is posted on the Internet, it should not be able to play on a downloader’s computer or portable music device. To achieve this, a DRM system employs secrets. There is no theory of protecting content other than keeping secrets. In other words, even if one uses the most sophisticated cryptographic locks to protect the actual music, one must still “hide” the keys which unlock the music on the user’s computer or portable music player. No one has ever implemented a DRM system that does not depend on such secrets for its operation.
The problem, of course, is that there are many smart people in the world, some with a lot of time on their hands, who love to discover such secrets and publish a way for everyone to get free (and stolen) music. They are often successful in doing just that, so any company trying to protect content using a DRM must frequently update it with new and harder to discover secrets. It is a cat-and-mouse game. Apple’s DRM system is called FairPlay. While we have had a few breaches in FairPlay, we have been able to successfully repair them through updating the iTunes store software, the iTunes jukebox software and software in the iPods themselves. So far we have met our commitments to the music companies to protect their music, and we have given users the most liberal usage rights available in the industry for legally downloaded music.
With this background, let’s now explore three different alternatives for the future.
The first alternative is to continue on the current course, with each manufacturer competing freely with their own “top to bottom” proprietary systems for selling, playing and protecting music. It is a very competitive market, with major global companies making large investments to develop new music players and online music stores. Apple, Microsoft and Sony all compete with proprietary systems. Music purchased from Microsoft’s Zune store will only play on Zune players; music purchased from Sony’s Connect store will only play on Sony’s players; and music purchased from Apple’s iTunes store will only play on iPods. This is the current state of affairs in the industry, and customers are being well served with a continuing stream of innovative products and a wide variety of choices.
Some have argued that once a consumer purchases a body of music from one of the proprietary music stores, they are forever locked into only using music players from that one company. Or, if they buy a specific player, they are locked into buying music only from that company’s music store. Is this true? Let’s look at the data for iPods and the iTunes store – they are the industry’s most popular products and we have accurate data for them. Through the end of 2006, customers purchased a total of 90 million iPods and 2 billion songs from the iTunes store. On average, that’s 22 songs purchased from the iTunes store for each iPod ever sold.
Today’s most popular iPod holds 1000 songs, and research tells us that the average iPod is nearly full. This means that only 22 out of 1000 songs, or under 3% of the music on the average iPod, is purchased from the iTunes store and protected with a DRM. The remaining 97% of the music is unprotected and playable on any player that can play the open formats. Its hard to believe that just 3% of the music on the average iPod is enough to lock users into buying only iPods in the future. And since 97% of the music on the average iPod was not purchased from the iTunes store, iPod users are clearly not locked into the iTunes store to acquire their music.
The second alternative is for Apple to license its FairPlay DRM technology to current and future competitors with the goal of achieving interoperability between different company’s players and music stores. On the surface, this seems like a good idea since it might offer customers increased choice now and in the future. And Apple might benefit by charging a small licensing fee for its FairPlay DRM. However, when we look a bit deeper, problems begin to emerge. The most serious problem is that licensing a DRM involves disclosing some of its secrets to many people in many companies, and history tells us that inevitably these secrets will leak. The Internet has made such leaks far more damaging, since a single leak can be spread worldwide in less than a minute. Such leaks can rapidly result in software programs available as free downloads on the Internet which will disable the DRM protection so that formerly protected songs can be played on unauthorized players.
An equally serious problem is how to quickly repair the damage caused by such a leak. A successful repair will likely involve enhancing the music store software, the music jukebox software, and the software in the players with new secrets, then transferring this updated software into the tens (or hundreds) of millions of Macs, Windows PCs and players already in use. This must all be done quickly and in a very coordinated way. Such an undertaking is very difficult when just one company controls all of the pieces. It is near impossible if multiple companies control separate pieces of the puzzle, and all of them must quickly act in concert to repair the damage from a leak.
Apple has concluded that if it licenses FairPlay to others, it can no longer guarantee to protect the music it licenses from the big four music companies. Perhaps this same conclusion contributed to Microsoft’s recent decision to switch their emphasis from an “open” model of licensing their DRM to others to a “closed” model of offering a proprietary music store, proprietary jukebox software and proprietary players.
The third alternative is to abolish DRMs entirely. Imagine a world where every online store sells DRM-free music encoded in open licensable formats. In such a world, any player can play music purchased from any store, and any store can sell music which is playable on all players. This is clearly the best alternative for consumers, and Apple would embrace it in a heartbeat. If the big four music companies would license Apple their music without the requirement that it be protected with a DRM, we would switch to selling only DRM-free music on our iTunes store. Every iPod ever made will play this DRM-free music.
Why would the big four music companies agree to let Apple and others distribute their music without using DRM systems to protect it? The simplest answer is because DRMs haven’t worked, and may never work, to halt music piracy. Though the big four music companies require that all their music sold online be protected with DRMs, these same music companies continue to sell billions of CDs a year which contain completely unprotected music. That’s right! No DRM system was ever developed for the CD, so all the music distributed on CDs can be easily uploaded to the Internet, then (illegally) downloaded and played on any computer or player.
In 2006, under 2 billion DRM-protected songs were sold worldwide by online stores, while over 20 billion songs were sold completely DRM-free and unprotected on CDs by the music companies themselves. The music companies sell the vast majority of their music DRM-free, and show no signs of changing this behavior, since the overwhelming majority of their revenues depend on selling CDs which must play in CD players that support no DRM system.
So if the music companies are selling over 90 percent of their music DRM-free, what benefits do they get from selling the remaining small percentage of their music encumbered with a DRM system? There appear to be none. If anything, the technical expertise and overhead required to create, operate and update a DRM system has limited the number of participants selling DRM protected music. If such requirements were removed, the music industry might experience an influx of new companies willing to invest in innovative new stores and players. This can only be seen as a positive by the music companies.
Much of the concern over DRM systems has arisen in European countries. Perhaps those unhappy with the current situation should redirect their energies towards persuading the music companies to sell their music DRM-free. For Europeans, two and a half of the big four music companies are located right in their backyard. The largest, Universal, is 100% owned by Vivendi, a French company. EMI is a British company, and Sony BMG is 50% owned by Bertelsmann, a German company. Convincing them to license their music to Apple and others DRM-free will create a truly interoperable music marketplace. Apple will embrace this wholeheartedly.
Original URL: http://www.apple.com/hotnews/thoughtsonmusic
See attached, the PDF document I mentioned from class showing several techniques and strategies for microphone type selection and placement.
|Syllabus_2421 - spring13.pdf||73.95 KB|
Scoring the moving image is a course in creating sound and music to enhance, accompany, and/or engage with images and movement. While we will address many traditional multimedia forms throughout the semester (narrative film, documentary, television, music for the theater, music for dance) no single mode of expression will be our focus. We will be exploring new ways of joining sound and image, of connecting or relating the visual and the aural. The course is divided into to large sections, “Music for fixed Media” and “Music for live or dynamic media”.
See semester assignments below.
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.
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.
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.
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".
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.
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!
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.
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
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
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.
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.
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.
Documentation and Links
Puredata and Gem
[expr] and [expr~] object manual (mathematics via C-like expressions)
A Gem Primer (PDF), beginning level tutorial for shapes and movement
Object list for PD, Gem, and PD extended: http://en.flossmanuals.net
Gem object list: http://gem.iem.at/documentation
Pure Data Mailing List (Search): http://lists.puredata.info/pipermail/pd-list/
Pure Data Mailing List (Subscribe): http://lists.puredata.info/listinfo/pd-list
Pure Data Forum: http://puredata.hurleur.com
Pd Downloads: http://www.puredata.info/downloads
Pure Data CVS: http://www.puredata.info/dev/cvs
Pd Extended Installers: http://at.or.at/hans/pd/installers.html
Miller S. Puckette's Pd page: http://www-crca.ucsd.edu/~msp/software.html
Pd Downloads: http://www.puredata.info/downloads
Pure Data CVS: http://www.puredata.info/dev/cvs
Unauthorized Pd: http://ydegoyon.free.fr/software.html
FLOSS Manual and tutorial set: http://en.flossmanuals.net/PureData/
Pd community patches: http://www.puredata.org/community/patches
Pure Data Documentation Project: http://www.davesabine.com/eMedia/PureData/tabid/145/Default.aspx
Theory and Techniques of Electronic Music by Miller Puckette: http://www.crca.ucsd.edu/~msp/techniques.htm
Music making tutorials: http://www.obiwannabe.co.uk/html/music/musictuts.html
Practical synthetic sound design in Pd: http://www.obiwannabe.co.uk/html/sound-design/sound-design-all.html
Pd Repertory Project: http://crca.ucsd.edu/~msp/pdrp/latest/doc/
Pure Dyne: http://puredyne.goto10.org/
Ubuntu Studio: http://ubuntustudio.org/
Pd Gentoo Overlay: http://pd-overlay.sourceforge.net/
FLOSS Manual audio tutorials (various topics, primarily analog synthesizer concepts)
Music making tutorials: http://www.obiwannabe.co.uk/html/music/musictuts.html
Below are patches, examples, and sound/video created using PD. This list will grow over time as there is a nearly constant accumulation of material available online.
Patches and examples from puredata.info (various artists, various types both audio and video)
Music made with PD from puredata.info (various artists)
There are many resources on the web for Gem including formal documentation, tutorials, patches, and video demonstrations. Below are some links to these resources.
FLOSS Manual Video tutorials (images, video, shapes, camera input, and basic algorithms)
-- This tutorial is "under construction" but it already extremely useful to both new and experienced users
Music 3421: Scoring the Moving Image, Spring 2009
Professor Kevin Ernste
Office: B27 and 108 Lincoln Hall
Office Hours: Wednesday 11 – 2
Course website: http://digital.music.cornell.edu
- please visit the website and register a username
Scoring the moving image is a course in creating sound and music to enhance, accompany, and/or engage with images and movement. While we will address many traditional multimedia forms throughout the semester (narrative film, documentary, television, music for the theater, music for dance) no single mode of expression will be our focus. We will be exploring new ways of joining sound and image, of connecting or relating the visual and the aural. The course is divided into to large sections, “Music for fixed Media” and “Music for live or dynamic media”.
In addition to commercially available software, students will also be introduced to a number of
excellent free software tools, many with unique designs and functionality. All tools are
available for download on the website (see “free tools”), giving students a chance to begin
building an individual musical toolkit.
Course requirements include two composition projects, one for each of the two large parts of the
course (see the semester schedule below). The last of these will be presented at the Sound Art
Forum concert at the semester's end. In addition, there will be weekly or bi-weekly
assignments to be carried out on the student's own time. Studios are available for this purpose
and students may sign up for individual times online. Visit the course website and follow the
link to “studio signup”.
Grading for the semester is broken down as follows:
10% Class participation (in-class and online)
40% Weekly/bi- weekly assignments
50% Two semester projects (25% each)
All work must be turned in on time. Late work will be graded one letter grade lower and work
turned in more than two weeks later will not be accepted. The final performance is mandatory
and non-participation results in automatic failure (participation and final project grade lost).
Facilities: Studios B25B, C, and D will be our primary studios with two more stations available
in the new music library lab located on the 2nd floor of Lincoln. In addition, some of the
software used in Music 220 is available for use in the Uris Library CL3 (Creation Station) lab
where there are 11 Windows machines as well as some hardware which you will come to
know (Korg KONTROL49 keyboard, SM58 microphone, etc).
There is also a network storage drive available. This is where you will hand in all assignments
and project and where you can backup or relay data from one studio/system.
PART I: Music for fixed media
< Week 1 January 19thand 21st
Course introduction and logistics; website information and access review; studio fundamentals
< Week 2 January 26th and January 28th
Audio and video formats, studio and remote recording techniques; microphones and sound sources
< Week 3 February 2nd and 4th
Introduction to audio/video; video recording and audio synchronization fundamentals
< Week 4 February 9th and 11th
Music for film, television, and animation; cues, sequences, and mockup development
< Week 5 February 16th and 18th
Music for film, television, and animation continued; spotting and scoring;
< Week 6 February 23rd and February 25
— Critique #1 (Monday)
Live and improvisatory scoring techniques; Ableton Live and rewire
< Week 7 March 2nd and 4th
Music for games and for the web
< Week 8 March 9th and 11th
— Performance/showcase #1
< Week 9 SPRING BREAK
PART II: Music for live or dynamic media
< Week 10 March 23rd and 25th
Music for the stage; dynamic scoring techniques
< Week 11 March 30th and April 1st
Introduction to graphical programming with PureData (PD) and Gem
< Week 12 April 6th and 8th
PD and Gem continued; Max/MSP and Jitter
< Week 13 April 13th and 15th
— Critique #2 (Monday the 13th)
Interactivity: music and image and vice-versa; sound installations
< Week 14 April 20th and 22nd
Live video and audio processing; sound spatialization and localization
< Week 15 April 27th and 29th
— Performance/showcase #2
Optional: Orchestral reading with score for film or dance
Intended principally for doctoral students in music composition but open to others by permission. The course presents a practical overview of both classical and state-of-the-art techniques for computer music including digital synthesis, signal processing and sound manipulation, analysis and resynthesis, spatialization, and real-time and/or interactive applications. Students will produce several short studio projects as well as one larger piece to be presented in a final concert.
Below is a listing of assignments for Music 6420.
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:
(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:
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:
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:
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
To listen to Gesang in the studio (quad version), use the psfl command shown above:
Pierre Schaeffer's Etude aux Chemins de Fer (Railroad study)
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.
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)
All documentation below can be accessed in hard copy within Studios A and B (B27 amd B35B). Online documentation often contains additional resources such as video demonstrations and tutorials. Feel free to supplement this existing information with a Google search, particularily when the question relates to unfamiliar terminologies or technical details. Or post your question directly to the forums where other students are probably lurking and wondering the same thing.
Note: All unix commands take the basic form:
command file (where “file” is the file to execute “command” upon)
Or more generically:
command argument1 argument2 [argument3]
ls lists current directory contents
ls -l long listing (owner, permissions, size, etc) – add “-h” for human readable sizes
ls -a list all, including those files that start with a dot (.).
pwd print working directory
mkdir [directory name] create a subdirectory
cd change working directory
- cd [directory name]
- cd .. moves up 1 directory level
- cd - toggles back to previous directory
cp copy a file
- cp [filename1] [filename2] (-R does recursive copy of all subdirectiries)
mv move (or rename) a file
- mv [filename1] [filename2]
less view a file one page at a time, advance pages with SPACE
less [filename] or less [filename]
rm remove (delete) a file (Note: there is no “undo”)
- rm [filename] (-r does recursive removal...useful, but be CAREFUL)
rmdir [directory name] note: the directory has to be empty
cat view the contents of a file (or better, “output” its contents), concatinate
> redirect output to a new file
cat [file1] [file2] > [newfile]
>> adds or “appends” to an existing file
cat [file1] [file2] [file3] >> temp_file
| Pipe, allows you to pass the results (stdout) of a command to another command
- ls | more
history shown a list of previously executed commands (-h for no command numbers)
!! run previous command in history (also “up-arrow”) number in history
!# run command from “history” where “#” is the command number
* wild card used to stand for “all”
- ls *.txt list all files with the extension .txt
Soundfile directory commands (SFDIR)
lsf lists current soundfile directory contents
lsf -l long listing (owner, permissions, size, etc)s
pwdsf print working directory
mkdirsf [directory name] create a subdirectory
cdsf change working directory
- cdsf [directory name]
- cdsf .. moves up 1 directory level (or “../../” for up two, etc)
- cdsf - toggles to previous directory (like “Back” in a browser)
cpsf copy a file
cpsf [filename1] [filename2] (-R does recursive copy of all subdirectiries)
mvsf move (and/or rename) a file
- mvsf [filename1] [filename2]
rmsf remove (erase) a file
- rmsf [filename] (-r does recursive removal...useful, but be CAREFUL)
rmdirsf [directory name] note: the directory has to be empty
play (p) play a soundfile or soundfiles in your current working directory
- p soundfile1.wav [soundfile-n.wav]
sfinfo view information about a soundfile in your current directory
- sfinfo soundfile1.wav [soundfile-n.wav]
playsflib(psfl) play a soundfile from the soundfile directories
- psfl fl.c4.wav
findsflib search the soundfile directory by character string
- findsflib character_string
findsflib -p search the soundfile directory by character string and play them as they are found
- findsflib -p character_string
CEMC specific commands (more to come)
lsex list available tutorial examples
getex obtain a copy of a tutorial example
- getex tutorial1 > mytutorial1
lstp list available templates (blank examples)
gettp obtain a copy of a template (blank examples)
cemchelp view available help files and read file designated by argument
cs shortcut to “csound”
- cs orc sout (compile files “orc” and “sout” with Csound
ssgdig shortcut for ssh access to "digital.music.cornell.edu"
ssgdev shortcut for ssh access to "devel.music.cornell.edu"
by Barry Vercoe, Massachusetts Institute of Technology
The Orchestra File
Csound runs from two basic files: an orchestra file and a score file. The orchestra file is a set of instruments that tell the computer how to synthesize sound; the score file tells the computer when. An instrument is a collection of modular statements which either generate or modify a signal; signals are represented by symbols, which can be "patched" from one module to another. For example, the following two statements will generate a 440 Hz sine tone and send it to an output channel:
asig oscil 10000, 440, 1
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:
asig oscil 10000, 440, 1
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).
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
will convert the pitch A (above middle C) to its cps equivalent (440 Hz). Likewise, the expression
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
amp line 0, p3, 10000
asig oscil amp, cpspch(p5), 1
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):
kamp line 0, p3, 10000
asig oscil kamp, cpspch(p5), 1
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
kctrl line 0, p3, 10000 ; amplitude envelope
asig oscil kctrl, cpspch(p5), 1 ; audio oscillator
out asig ; send signal to channel 1
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
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
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:
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
kamp line 0, p3, 10000
kvib oscil 2.75, cpspch(p5)/50, 1
a1 oscil kamp, cpspch(p5)+kvib, 1
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
ioct = octpch(p5)
kamp line 0, p3, 10000
kvib oscil 1/120, cpspch(p5)/50, 1
asig oscil kamp, cpsoct(ioct+kvib), 1
This instrument is seen to use a third type of orchestra variable, an i-rate variable. The variable ioct receives its value at an initialization pass through the instrument, and does not change during the lifespan of this note. There may be many such init time calculations in an instrument. As each note in a score is encountered, the event space is allocated and the instrument is initialized by a special pre-performance pass. i-rate variables receive their values at this time, and any other expressions involving just constants and i-rate variables are evaluated. At this time also, modules such as line will set up their target values (such as beginning and end points of the line), and units such as oscil will do phase setup and other bookkeeping in preparation for performance. A full description of init-time and performance-time activities, however, must be deferred to a general consideration of the orchestra syntax.
SCORE-11 (Brinkman, 1981 & 1990) is a note-list preprocessor for the CSOUND compiler, 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.
 SCORE-11 was originally designed for Vercoe's MUSIC11 system. MUSIC11, which was written in PDP-11 assembly language, was replaced in 1986 by CSOUND, a version of the program written in the programming language C, and which runs on many different computer systems. SCORE-11 works well with either version of Vercoe's program, which will be referred to as CSOUND in this manual except where the distinction is important.
Command Line SSH
Secure Shell Access
Command line access via a Unix terminal/shell is the most reliable, powerful method of accessing the Digital Music Studios. With it users can login and use the functionality and processing power of the CDMS computers remotely.
To login, open a terminal shell (on Mac, Applications --> Terminal; on Windows use Cygwin; on Linux or other Unix just open a standard xterm). Then at the command prompt type:
...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 :
CEMC systems are named by room as follows:
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 – A script that creates Csound gen1 function definitions for soundfiles in a format suitable for inclusion in SCORE11 input files.
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.
(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."
Introduction to the Eastman Csound Library
(This section last updated August 2004, Allan Schindler)
The Eastman Csound Library, the topic of this extract from the Eastman Computer Music Center Users’ Guide, is a collection of front-end programs, "instrument" algorithms, score file preparation programs and assorted utilities designed to simplify ECMC/CEMC users’ introduction to, and use of, the Csound music compiler. Csound is a widely used software audio synthesis and signal processing package, available at no cost under the LGPL (Lesser General Public License) from the Csound Home Page web site (http://csounds.com) inversions Linux (and other flavors of Unix), Macintosh and Windows.Csound initially was developed on Unix systems during the 1980s by a team led by Barry Vercoe at the Massachusetts Institute of Technology and employed a commands issued from shell windows. During the 1990s the Csound programs were ported to Macintosh, Windows and other platforms. Today, cross-platform development of the "canonical" (official) Csound source code continues by a world-wide group of Csound users, coordinated by John Ffitch, who update "canonical" (officially supported) versions of the language.
Like other software music compilers (such as Cmix and cmusic) that have been written at academic computer music centers, Csound has its roots in the very first music compilers, called Music I through Music V, written by Max Mathews at Bell Labs beginning around 1957. In most of these compilers, the fundamental means of creating or modifying sounds is a user-defined synthesis or signal processing algorithm, called an instrument inCsound. The algorithm consists of a step-by-step sequence of mathematical and logical operations, coded in the Csound compiler language, and then executed by the CPU. Often, these operations are very similar to the types of operations that takeplace within the electrical circuits of hardware synthesizers, amplifiers, mixing consoles and other types of audio gear. Aparticular instrument algorithm, which generates a particular type of audio signal or timbre, might be likened to a particular "patch" available on a hardware synthesizer or sampler. Alternatively, analgorithm might add reverberation, or echos, to a previously created soundfile, or to the audio signals being generated simultaneously by some other instrument within the same compile job.
Read more in the attached PDF.
Documentation and discussion of the examples found with "lsex sc" on CEMC computers can be found here, Allan Schndler's famous Eastman Csound Tutorial:
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:
(you sill see the example listed)
cs -d orc sout
You will now have a wave audio file, as usual, called "test.wav that contains the example's audio result.
The following is the Music 6420 listening list for Spring 2009. Recordings are available in the Cornell Music Library or in the sflib "listening" directory on CEMC systems. Students are encouraged to review these items for further study.
The purpose of this list is to familiarize students with important works of electronic music.
Antheil — Ballet mécanique (CD 10130) and video on http://www.antheil.org
Babbitt — Philomel (CD 5102)
Berio — A-ronne ( Rec 1586 B502 A7)
Berio — Thema (Omaggio a Joyce)
Berio — Visage (Rec 175 E4 E31)
Boulez — Répons --M1045.B76 R4 2001 Folio (CD 8509)
Cage — Imaginary landscape no. 1 (CD 4355)
Cage — William's mix (CD3670)
Carlos — Beethoven's 9th Symphony, Mvt. 4 (in sflib)
Carlos — Timesteps (in sflib)
Davidovsky — Synchonisms #6 (CD 1312)
Dodge — Any Resemblance Is Purely Coincidental (CD 2605)
Dodge — Earth’s magnetic field (CD 6713)
Eno — Music for Airports (Rec 3 .1 E6)
Harvey — Mortuos plango, vivos voco (Rec 5 I65)
Harvey — Bhakti -- M947.H34 B5 1989 (CD 12107)
Hiller/Cage — HPSCHD (Rec 175 E4 C13 H2)
Kagel — Transicion I (Rec 175 E4 E31)
Lansky — Idle Chatter, Just-more-idle-chatter, Notjustmoreidlechatter (CD 7313)
Lansky — Six Fantasies on a Poem by Thomas Campion (CD 3691)
Ligeti — Artikulation (CD5601) -- M1473.L72 A8 1994
Lucier — Music on a Long Thin Wire -- Rec 1473 L93 M8
Lucier — I am siiting in a room (CD 5317)
Marshall — Fog Tropes (in sflib)
Matthews, Max — Bicycle Built for Two. (CD 8717)
Mel Powell — Strand settings: darker (CD 9615 v.8)
Oliveros — Sound Patterns (http://ubu.artmob.ca/sound/extended_voices/Extended-Voices_1_Pauline-Oliveros.mp3)
Reich — Come out (CD 1613)
Reich — Pendulum music (CD 9026)
Risset — 'L'Autre Face (CD 5101)
Risset — Sud (CD 6649)
Risset — Songes (CD 14870)
Saariaho — NoaNoa, flute (CD 9010, CD 9035)
Saariaho — Près (CD 9035)
Schaeffer/Henri — Symphonie Pour Un Homme Seul (Symphony for a Man Alone) -- CD 2588
Schaeffer — Études aux chemins de fer
Subotnick — Silver Apples on the Moon (Rec 175 E4 S94 S5)
Subotnick — The last dream of the beast ( Rec 1497 L112)
Stockhausen — Hymnen (Rec 1473 S86 H9)
Stockhausen — Kontakte with piano and perc -- M342.S86 K8 Folio (Rec 1473 S86 K8)
Stockhausen — Gesang der Jünglinge (in sflib)
Stockhausen — Mantra (CD 5856)
Varèse — Déserts (CD 7232)
Varèse — Poèm Électronique(CD 7232)
Wishart — Vox, no. 5 (CD 8717)
Wourinen — Time's Encomium (CD 5693)
Xenakis — Concrete PH (Rec 1473 X51 E3)
Xenakis — Mycenae Alpha -- UPIC score online (CD 5102)
Music 6420: Electroacoustic Techniques, Fall 2007
Kevin Ernste, Professor
Office: B27 and 108 Lincoln Hall
Office Hours: Friday. 10 – 1, others by appointment
Course website: http://digital.music.cornell.edu
- please visit the website and register a username
Music 6420 is an exploration of classical and state-of-the-art tools for making music with computers. A substantial portion of our time will be spent working with software directly, although “learning software” is not our explicit goal. Instead we will engage several software metaphors – generalized categories of functionality – working toward developing individualized composer toolkits suitable for creative work. In developing our facility with basic techniques, we will examine a body of pieces from the classical repertoire.
In addition to commercially available software, students will be exposed to a number of excellent free software tools, many with unique designs and functionality. All tools are available for download on the course website.
Course requirements include: two one-on-one oral tests, one in-class presentation on a composer or piece of your choosing, one mid-semester piece/study, and a larger final composition to be presented in a semester's end concert. In addition, there will be weekly or bi-weekly assignments to be carried out on the student's own time.
Grading for the semester is as follows:
20% Class participation
15% Listening examination
20% Mid-semester project
15% Public lecture/presentation
30% Final project and concert participation
Facilities: B27 will be our primary studio. In addition, there is a mobile rig usable for performances and remote recording. To inquire about availability, consult studio faculty or staff.
Selected Listening List (see the formal listening list online):
Reich, Come Out
Schindler, Breath of Life
Varese, Poem Electronique
Lansky, Idle Chatter
Subotnick, Silver Apples on the Moon
Mel Powell, Strand settings: darker
Davidovsky, Synchonisms #6
Cage, Imaginary landscape no. 1
< Week 1 August 31st
Course introduction, Unix fundamentals, remote access
< Week 2 September 7th
Fundamentals of digital audio, basic recording techniques
< Week 3 September 14th
Audio editing, mixing, soundfile libraries
< Week 4 September 21st
Introduction to Csound and the Score11 event preprocessor
< Week 5 September 28th
Csound/Score11 continued, sampling and granular synthesis
< Week 6 October 5th
Advanced Score11, Csound Orchestras, Cecilia
< Week 7 October 12th
Test 1; (test and mid-semester project discussion)
Introduction to PD and Max
< Week 8 October 19th
PD/Max continued, subpatches, externals, abstractions;
< Week 9 October 26th
Advanced PD/Max topics: "best practices" in engine and interface design
< Week 10 November 2nd
Advanced PD/Max topics: interactivity, networks and OSC
Mid-semester projects due 11/2, Concert TBA, Midday Music
< Week 11 November 9th
Analysis and re-synthesis techniques, FFT, Phase vocoder, spectral modeling and editing
< Week 12 November 16th
Concert Performance, Midday Music
< Week 13 November 23rd
Supercollider and JACK
< Week 14 November 30th
Final talks; final projects due
Music 6421 is a seminar in composition focused on the techniques, repertoire, and history of electroacoustic and computer generated music. We we follow several threads together, the most important of which will be the composition of three short study pieces: the first for a soloist, the second for a small ensemble (usually of 4 -10 players), and the last for orchestra or chorus.
All weekly assignments for Music 6421 are listed below. Each includes an attached printable PDF version. Many contain links to external rescources, including link to networked library resources.
Below are patches and examples from class.
The following examples were discussed with respect to building simple graphical interfaces for your class pieces.
In addition to those discussed, I have included the patch to my recent guitar piece, "Roses Don't Need Perfume" including all sounds. You should be able to simply open it and start advancing through events.
The only patch found below that is not mine is called "mondrian.pd" for which documentation can be found here:
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.
PD contains its own documentation in the form of dozens of help examples. Below is a rough categorization of the patches found in PD proper. See the "Help" menu to access the actual patches.
Oscilators, tables, phasors
A01.sinewave.pd : sine wave oscillator
A02.amplitude.pd : time varying amplitude control of sine wave
A06.frequency.pd : frequency to pitch conversion; controlling oscillator pitch
B01.wavetables.pd : arbitrary audio waveforms with tabosc4~ and table10
B02.two-wavetables.pd : time-varying pitch: one oscillator controls the pitch of another
B03.tabread4.pd : control of oscillator phase with tabread3~
B04.tabread4.interpolation.pd : finer oscillator phase control with interpolation
B06.table.switching.pd : switching between wave tables
C01.nyquist.pd : foldover example
C02.sawtooth-foldover.pd : another foldover example
K04.even.odd.pd : separating odd and even harmonics of a source waveform
K05.bandlimited.pd : limiting the bandwidth of sawtooth waves
Envelopes and Control signals
A03.line.pd : the line~ object used for simple amplitude envelopes
A02.amplitude.pd : graphicaldisplay of amplitude envelopes
A05.output.subpatch.pd : a subwindow is used to control and mute amplitude
C03.zipper.noise.pd : line object controls amplitude
C04.control.to.signal.pd : vline~ controls amplitude with greater precision
C08.analog.sequencer.pd : emulation of analog sequencer and envelope generator
D01.envelope.gen.pd : envelope generator for overlapping sounds
D02.adsr.pd : adsr (attack-decay-sustain-release) envelope generator
D03.envelope.dB.pd : logarithmic envelope generator
D04.envelope.quartic.pd : comparison of linear & quartic amplitude envelopes
D05.envelope.pitch.pd : creation of pitch envelopes
D06.envelope.portamento.pd : pitch glissandi
J03.qlist.pd : additive synthesis oscillator bank instrument controlled by a qlist
J04.more.adsr.pd : logarithmic (quartic) ADSR amplitude envelope
J05.vibrato.pd : vibrato and pitch envelope example
J06.adsr.sequenced.pd : qlist text file used to provide sequences of pitches
E01.spectrum.pd : graphing frequency spectra of audio signals
C06.signal.to.control.pd : converting between audio and control signals
C09.sample.hold.pd : pitch control with a sample-and-hold object
A07.frequency.mod.pd : classical Chowning frequency modulation algorithm
B05.tabread.FM.pd : frequency modulation by means of a wavetable
E02.ring.modulation.pd : ring modulator for synthetic signals
E03.octave.divider.pd : ring modulator shifts pitch down an octave
E04.difference.tone.pd : waveshaping to create difference tones between sinusoids
E05.chebychev.pd : waveshaping with Chebychev polynomials
E06.exponential.pd : waveshaping with exponential functions
E07.evenodd.pd : step sequencer controls a waveshaping instrument
E08.phase.mod.pd : classical phase modulation (similar to FM)
E10.complex.FM.pd : frequency modulation with 2 modulating oscillators
F05.ring.modulation.pd : ring modulating pulse trains
F10.sweepable.FM.pd : two cosines applied to FM synthesis
F11.anharmonic.FM.pd : fairly complex 2 cosine FM example
F12.paf.pd : 2 cosines used as ring modulators
H07.ssb.modulation.pd : frequency shifter (single sideband balanced modualtion)
B07.sampler.pd : tabread4~ reads in samples from a soundfile
B08.sampler.loop.pd : a simple (probably TOO simple) looping sampler algorithma
B09.sampler.loop.smooth.pd : patch for smooth looping of samples
B10.sampler.scratch.pd : sampler with variable loop points
B11.sampler.nodoppler.pd : more sophisticated implementation of B10
B12.sampler.transpose.pd : pitch transposition of audio samples
B13.sampler.overlap.pd: overlapping sampling of synthetic signal
B14.sampler.rockafella.pd : time compression/expansion of samples
C05.sampler.oneshot.pd : avoiding clicks when reading in audio samples
Pulse train waveforms and random number generators
F01.pulse.pd : pulse train oscillator
F03.pulse.spectrum.pd : graphing the spectrum of pulse trains
F06.packets.pd : windowing functions synthesize enveloped sinusoids (complex example)
F08.two.cosines.pd : summing cosines to create controllable complex spectra
H05.filter.noise.pd : white noise generator
K01.pulse.width.mod.pd : pulse width modulation
K02.stereo.pd : stereo pulse width modulation example
Filters, envelope followers
C07.envelope.follower.pd : an amplitude envelope follower algorithm
H01.intro.filters.pd : high-pass, low-pass and band-pass filters
H02.bandpass.pd : 2 bandpass filters used to accentuate selected partial frequencies
H03.filter.sweep.pd : bandpass filer with time-varying center frequency
H04.filter.floyd.pd : another filter sweep example a
Delay lines, reverberators
G01.delays.pd : delay of oscillator signal with simple delay line
G02.delay.loop.pd : delay line with feedback tocreate resonant frequency
G03.delay.variable.pd : variable delay time
G04.delay.pitchshift.pd : pitch shifting with 2 delay lines
G05.delay.reverb.pd : multiple delay lines used for reverberation
J07.execution.order.pd : controlling execution order in delay read/write pairs
J08.control.blocksize.pd: feeback of a delay line is controlled in a subpatch
Complete instruments :
C10.monophonic.synth.pd : MIDI-controlled monophonic synth
D07.additive.pd : additive synthesis instrument (Risset bell)
D08.table.spectrum.pd : frequency spectra controlled graphically
D09.shepard.tone.pd : shepard tone example
D10.sampler.notes.pd : sampler with pitch,duration, amplitude control
D11.sampler.poly.pd : 8 voice polyphonic version of D10
D12.sampler.bis.pd : MIDI controlled polyphonic sampler
J10.waveshaping.pd : emulation of an analog step sequencer
K03.envelope.mod.pd : enveloping a sampler loop point to protect against clicks
Miller's own Theory and Techniques of Electronic Music is available online. This is book is both a general overview of electronic music techniques and an extended manual for PD. In it Puckette refers directly to PD and uses many of the example patches to illustrate phenomena.