aparrish@itp

Satellite photo of the Great Salt Lake in 2003. The line in the lake that divides blue water from reddish water is not a photographic artifact, but reflects a real difference in the chemical composition of the water in different arms of the lake. Details below.

The Great Salt Lake is a terminal lake located in northern Utah. It is the remnants of Lake Bonneville, a much larger lake that covered most of Utah (and parts of Idaho and Nevada) during the Pleistocene era. Its surface area and depth varies dramatically according to the amount of water that makes it into the lake. Its maximum depth can be anywhere from fourteen to thirty-three feet; its surface area can be as little as 1,000 square miles, or as much as 3,000. Much of Utah's wetland habitat is located where the lake's tributaries flow into the lake; these wetlands are an important habitat for migratory birds.

The lake is endorheic, meaning that it has no outlet. Water flows into the lake from several rivers and streams, but escapes only by evaporation. Like other endorheic lakes, the Great Salt Lake is highly sensitive to human involvement. The volume of the lake has been can be—and has been—significantly affected by any of the following factors:

• diversion of incoming rivers for agricultural and recreational use
• partitioning and pumping of water for industry and mining
• pumping water into the salt flats to alleviate flooding

An aerial view of MagCorp's magnesium mining facility on the shores of the Great Salt Lake. Click the image to go to this location on Google Maps.

But not only the volume of the lake is affected: its chemical composition is affected as well. The most dramatic example of this is the Lucin Cutoff, a causeway built across the length of the lake in 1959 for railroad use. The causeway effectively divides the lake into two separate bodies of water, a northern arm and a southern arm, joined only by a 300-foot culvert halfway along the length of the causeway. Because all of the lake's fresh water tributaries run into the southern arm, the northern arm has become progressively saltier than the southern arm. In 1999, the southern arm was 9% salt by weight, while the northern arm was 25%.

Southern Pacific Railroad claims that the Lucin Causeway helped defeat the Japanese in WWII. Click for full size image.

This partitioning of the lake is almost identical to the process of mining salt in evaporation ponds, except on a much larger scale. What makes this difference in salinity interesting is that it affects which types of algae and bacteria grow in the lake. This, in turn, affects the color of the water. In low salinity, the water is greenish; in high salinity, the water is red.

Salt evaporation ponds on the Great Salt Lake. Click to see the original image by Andrew Coulter Enright on Flickr.

A photograph of the Lucin Causeway in 1986. The south side of the lake is on the left, and the northern part is on the right. Click to see the image on the USGS web page.

Project description after the jump.

Engineering projects undertaken by both industry and government have unintentionally used the lake as a canvas, creating sometimes spectacular colors and shapes that virtually define the visual aspect of the lake when viewed from above. The ecology of the lake has rarely been taken into account when planning these engineering projects; the aesthetics of the lake are taken into account even more rarely.

My project idea for the lake is to take advantage of its unusual properties—its shallowness, its biology, and the fact that public policy makers virtually ignore its fragile ecosystem—to create an aquatic, geographical display. This display would take the form of a ten-by-ten grid of artificial evaporation pools, constructed along the shores of the lake (or along the already existing Lucin Cutoff causeway). These evaporation pools would be individually connected to the lake by means of a sluice gate. This sluice gate could be adjusted to either trap water inside the pool for evaporation, or let water in from the surrounding lake.

Together, these evaporation pools would form a pixel-based display, although with an enormously slow refresh rate—a matter of months, maybe, or however long it takes for the water to evaporate and for the microorganisms in the water to adjust to the salinity levels. The display could be used to show arbitrary images or data. A mock-up of how this display might look from a satellite view is below (click here if the embedded applet below doesn't work). The satellite imagery is from 2003, and the data being displayed is a monthly record of the lake's levels from 1966 to the present.

To view this content, you need to install Java from java.com

Posted by Adam Parrish at 01:13 AM | Permalink | Comments (0)

This week's Max/MSP patch. Click on the image for a larger screenshot. I'll post the patch itself later.

Computers are algorithmic machines. So, by definition, they can't generate true random numbers. There are, however, various ways of generating numbers that appear random—pseudorandom numbers. The Nintendo Entertainment System (NES), like a number of its contemporary computer systems, used a very simple device called a linear feedback shift register. In pursuit of an exploration of the expressive potential of pseudorandom noise, I implemented such a system in Max/MSP for my assignment this week.

Here's how it works: A shift register with some number of bits is initialized to a value, and shifted to the left. The values of two of the bits (stored before the shift) are XORed together and put in the slot left empty by the shift. One or more bits are then fed into a buffer (in order to generate bytes or words) or directly into a DAC. The process repeats indefinitely. An example (from my Max/MSP patch) is below.

Study #1 - 32kbit from buffer: Basic noise generated by a 15-bit linear feedback shift register. (Download)

Linear feedback shift registers are easy to implement (especially in hardware) and give numbers impressively similar to real randomness. They're not truly random, however, as they eventually produce repeating sequences. The number of bits before a sequence repeats is determined by the number of bits in the register and the precise bits XORed back into the register. The NES, for example, has two modes: one to produce a sequence that repeats every 32,767 bits, and another to produce a sequence that repeats every 93 bits.

The 93 bit mode, as you can imagine, produces a tone when played back at full speed. Example below.

Study #2 - 93 bit from buffer: Bits fed back into the shift register produce a repeating pattern of 93 bytes. (Download)

More after the jump, including my quick attempt to make a NES-like song.

The noise generation circuit in the NES was generally used for sound effects and percussion. Different timbres are achieved by changing the noise's playback frequency. (The NES limited noise frequencies to 16 different values.) In the following two examples, the noise from the linear feedback shift register is played through an envelope to create various percussive effects.

Study #3 - 32k noise: Percussive noises from the noise that repeats every 32k bits. (Download)

Study #4 - 93 bit noise: Percussive noises from the noise that repeats every 93 bits. Note how these are generally indistinguishable from the sounds in the 32kbit example above until you get into the higher frequencies. (Download)

Once I had the ability to make fairly authentic NES noise, I decided to try it out "in context." So I sampled the noises at various frequencies and with varying decay rates and sequenced a song. (The song also makes use of two square wave channels and a triangle wave channel—the only other voices that the NES supports.)

Study #5 - Quick song: Just a little demonstration of my NES noises, sampled from Max/MSP and sequenced in Schism Tracker. (Download)

Study #6 - SID noise: The Commodore 64 used a linear feedback shift register as well. According to these guys, it used a 23-bit shift register and sampled its output directly from eight bits in the register. I wrote a Perl script that simulates this kind of shift register, using the C code in the page linked above as a reference. This is an excerpt from the output of that Perl script. It's interesting to compare this to the NES noise in Study #1. (Download)

Study #7 - Audible randomness: I used my assignment from last week to make audible representations of some of the data in the examples above. The first segment in the clip is generated from the 93 bit repetition NES data; the second segment from the 32,767 bit repetition NES data; and the last segment is random values (generated in Perl). The repeating pattern of the 93 bit data is readily apparent. I don't know if the second two are all that distinguishable, however. (Download)

Part 2: Using regular expressions on audio files!

Peter suggested that we try editing sound files in text editors. I decided to be a little more programmatic and use regular expressions instead.

Study #8 - Oceans Abracadabra: This is a clip from an AIFF file of "Oceans," a song by Flying Saucer Attack. The original audiofile has been modified by a regular expression which replaced all occurences of the ASCII value 'a' with the string 'abracadabra.' A kind of interesting scratchy distortion results. (Download)

Here's the same clip from the original audio file, for reference. (Download)

References: Everything I need to know I learned from Brad Taylor.

Posted by Adam Parrish at 01:10 AM | Permalink | Comments (0)

Many Aldas. Click on thumbnail for larger version.

For GLArt this week, I created a piece entitled Aldapalooza—a meditation on texture and celebrity. Source code and image here. (Requires LWJGL and Mark Napier's Vector3D, GLMaterial and GLImage libraries.) Press up and down to control the Y position of the camera.

Aldapalooza uses the Perlin noise mesh generating/normalizing code that was in my assignment from last week. Three grids are drawn, one atop another, textured with an image of early M*A*S*H era Alan Alda. The texture's size in relation to the grid is constantly oscillating, which, in combination with OpenGL's texture tiling, gives the impression of vertical movement (even when the camera is not moving at all).

View from above. Click on thumbnail for larger version.

The three layers each have slightly different materials. The top layer has high shininess and ambient lighting; the bottom layer is more dull and has less ambient lighting. The middle layer is somewhere in between. I think this helps establish some depth cues which help distinguish the layers from all camera positions.

More screenshots after the jump.

Click on any of the thumbnails below to see a larger version (800x600).

Hawkeye, woven.

I am Hawkeye, of Borg. Resistance is futile.

View from beneath the middle layer. The top layer doesn't show up because OpenGL doesn't take transparency into account when calculating Z-depth.

One Alda on each layer.

Posted by Adam Parrish at 10:58 AM | Permalink | Comments (0)

The assignment for this week was to create an instrument in Max/MSP that can be controlled with the keyboard, applying the principles we learned so far in class. My first experiment was with a keyboard-controlled vowel synthesizer (see later in the entry for more information). The screenshot above is a spectrogram that came from audio generated by the second patch I did this week, which I call the BYTE ORGAN. (Okay, Mega Man wasn't in the original spectrogram.)

Click the image above for a larger screenshot of the patch, or here for the patch itself.

The Byte Organ is an additive synthesis instrument. It takes incoming binary data, breaks it up into bytes, and toggles on and off oscillators tuned to multiples of a fundamental frequency, based on the bits set in the byte.

For example, take the byte with the decimal value 97 (ASCII a). That byte has bits 0, 5, and 6 set (2⁰ = 1; 2⁵ = 32; 2⁶ = 64; 1 + 32 + 64 = 97). Given this input, the byte organ would create three sine waves: one at the fundamental frequency, one at the fifth overtone, and one at the sixth overtone.

When fed a series of bytes in succession (either from the keyboard or from a file), this instrument has the potential to make audible the structure of the underlying data. I've put a few examples below, along with spectrograms of some of the sounds.

Study #1 - Alphabet: This is just me using the instrument's keyboard input to type out the alphabet (in a vague approximation of the regular alphabet song). The spectrogram above is made from this audio. (Download)

Study #2 - Madness: Yours truly at the keyboard again, this time typing the first few sentences from H. P. Lovecraft's At the Mountains of Madness. Added delay makes it kind of spooky. (Download)

More madness after the cut.

Study #3 - Syllabus (excerpt): This time the patch is fed a file, which it reads in byte-by-byte. In this particular instance, the file in question is the Audio Art syllabus. The excerpt here covers only the first two or three hundred bytes of the file, and the spectrogram above depicts an even smaller section of the audio. (Download)

Then I got the idea to put in some truly binary data, something not textual at all—like a NES ROM! The following three excerpts come from a sound file that I generated from the first ten kilobytes or so of the Mega Man 2 ROM (probably the finest video game ever made).

Study #4 - Mega Man Excerpt #1: The very beginning of the file. (Download)

Study #5 - Mega Man Excerpt #2: As you can see from the spectrogram above, in this segment of the file there's a discernable, repeatable sequence. The result is a kind of bumpy rhythm. (Download)

Study #6 - Mega Man Excerpt #3: I think at this point in the ROM we're beginning to see actual graphical data (probably used to draw sprites). The graphical data is kind of discernable in the spectrogram, and makes for interesting listening. (Download)

The Byte Organ results from experiments that I did earlier in the week with vowel synthesis. After trying to remember and apply my long-lost knowledge from Linguistics 110 (Phonetics and Phonology) for awhile, I realized that my vowels were pretty crummy and more than anything I just liked looking at the spectrogram, so I ditched that patch and started working on the Byte Organ instead. But I'm including some of my experiments below anyway, just for fun.

Here's a screenshot of the patch and a link to the patch itself.

My synthesis technique consists of using frequency modulation to modulate two sine waves around the vowel's F1 and F2 areas with a modulation frequency at the same rate as the fundamental frequency (thus ensuring evenly spaced harmonics). Above is a spectrogram of my synthesized vowels; compare with actual spoken vowels below. (Here's a good overview of the acoustic characteristics of vowels.)

Study #7 - Front to back: The five cardinal vowels are played in sequence from front to back (/i/, /e/, /a/, /o/, /u/). Read along: ee, ay, ah, oh, oooh. (Download)

Compare the above to a recording of me saying the same vowels: (Download)

Study #8 - Vowel sounds: Just some random vowel sounds in sequence. Read along: Eee, ee, ee, ee, ay, ay, ay, ay, ah, ah, ah, ah, oh. (Download)

Posted by Adam Parrish at 11:18 PM | Permalink | Comments (0)

My midterm project for the Nature of Code is an experiment in algorithmic cut-up techniques. The text is reimagined as a number of massive objects—words—in one-dimensional space, subject to gravitational forces. As time passes, these objects attract one another. Some find stable orbits, others get flung helplessly into the void. The text is then reconstituted, using the position of the objects in space to determine the order of the words. Click the image above or here to try out the "rough draft" of the applet.

I've been trying to think of ways to apply the concepts from the first half of the Nature of Code to text. We tend to conceive of "force" as something that operates in two or three dimensions. As a result, the textual experiments with these techniques that first come to mind are really more about the language of layout than anything else (words in two-dimensional space).

However, I wanted to do something that dealt with syntax, not layout, and syntax is a one-dimensional affair. So the applet above uses the standard mathematics of velocity, acceleration, and gravitation, but it only applies them in one-dimension. Only the X coordinate counts; the Y and Z coordinates are always set to zero. (As a way of providing feedback about a word's mass, more massive words are drawn lower. This is just a visual convenience, and doesn't affect gravitation.)

Problems and ideas for improvement:

• The "mass" of a word is currently assigned using its width (as determined by textWidth()). I don't like this and I'd like to find a better alternative. It might be interesting to use a the word's frequency in English, for example, or some kind of measure of the word's polysemy. Perhaps the user and/or programmer could assign masses on a word-by-word basis. Maybe something that exploits the different meanings of the word heavy ("massive" and "of great importance").
• The source text is currently a soliloquy from Hamlet. I don't like this either. Ideally, new source texts could be swapped in at will, or perhaps even specifically composed to make use of the program's mechanics.
• Some way to save the current reordered text. I implemented a function that copies the current text to the clipboard, but this doesn't seem to work when the applet is running in a web browser.

Credit goes to Christian Croft, whose (really awesome) assignment from last week got me thinking about all of this.

Posted by Adam Parrish at 02:02 AM | Permalink | Comments (0)

Shiny, smooth, noisy grids. Click for full-size screenshot

This week's assignment for GLArt covers lighting and materials. The program draws a terrain-like triangle mesh using two different materials and either triangle normals or averaged normals. Java source code available here (requires LWJGL and Mark Napier's Vector3D and GLMaterial libraries). Use the arrow keys to move around the scene and press the space bar to re-generate the grid.

More screenshots after the jump.

View from above. Click for full-size screenshot

The mysterious underbelly (only scene ambient lighting). Click for full-size screenshot

Posted by Adam Parrish at 03:00 AM | Permalink | Comments (0)

I combined this week's assignment for Audio Art and the Nature of Code. I took one of Daniel's attraction examples, modified it slightly, and hooked it up to some sound synthesis patches in Max/MSP.

Click screen shot above to see the applet. All of the sound stuff was done in Max/MSP, so the applet on its own isn't very interesting.

The idea was to make the motion audible. Processing sends the X and Y coordinates of each circle to Max/MSP. Max/MSP then uses these values to generate tones. I tried a number of different patches, each of which used an oscillator at the frequency of the Y coordinate to modulate an oscillator at the frequency of the X coordinate. Some clips from these experiments are presented below. You can download the Max/MSP patches used for clips #6-#10 here (requires MaxLink).

Motion Study #1 - Amplitude Modulation (Download)

Motion Study #2 - Frequency Modulation (Download)

More samples after the jump.

The next two samples are from a patch which assigned the X and Y coordinates of each circle to a separate oscillator (six oscillators total).

Motion Study #3 - Sines Clumped: All oscillators around the same frequency. (Download)

Motion Study #4 - Sines Spread: Oscillators at varied frequencies. (Download)

Motion Study #5 - Ring: Three ring modulators, in which an oscillator at the frequency of the Y coordinate of the circle modulates an oscillator at the frequency of the X coordinate. (Download)

Studies #6 and #7 come from a patch that modulated a carrier frequency (supplied via MIDI) by all six X and Y coordinates of the circles in parallel.

Motion Study #6 - Parallel FM: A single note that varies modulation over time. (Download)

Motion Study #7 - Parallel FM Tune: "Michael Row Your Boat Ashore" played using the same instrument in the previous clip. (Download)

The final three clips are taken from a patch that used additive synthesis. The X coordinate of each circle assigns a harmonic and the Y coordinate determines the amplitude of the harmonic.

To assign the harmonic, the pixel space was divided up into tenths and the harmonic assigned according to which tenth of the space the current X coordinate falls into. For example, assuming the pixel field is 1000 pixels wide, an X position between 0 and 100 would assign the second harmonic (fundamental frequency times two); an X position between 500 and 600 would assign the seventh harmonic (fundamental frequency times seven).

The Y coordinate of the circle determines the amplitude of the harmonic, ranging linearly from 0 (Y = 0) to 1 (Y = height of pixel field).

Motion Study #8 - Additive Plain: A sustained note using the additive synthesis technique described above. (Download)

Motion Study #9 - Additive Tremolo: Another clip from the above instrument, this time with a bit of tremolo. (Download)

Motion Study #10 - Additive Tremolo Tune: Another stirring rendition of "Michael Row Your Boat Ashore" using the additive synthesis instrument. (Download)

Posted by Adam Parrish at 12:15 AM | Permalink | Comments (0)

This week's theme is transportation.

I spend about eighty minutes a day on Metro North's New Haven line. I took my minidisc recorder with me one morning earlier this week and recorded an entire one-way trip.

Collage #1 "Announce": I cut out the station announcements from the track and pasted them together next to one another. This makes the commute seem a lot shorter than it actually is. :) (Download)

Collage #2 "Doors": This consists of the sound of the doors closing and opening at each stop, along with the warning bell that rings just before the door closes. (Usually the doors are open for about fifteen to twenty seconds before the warning bell rings; I've cut out the audio for that duration.) (Download)

See below the jump for more, including the amazing MetroCard symphony.

My ride on Metro North ends at Grand Central Terminal. The picture above gives you the impression that it's a very busy place, which it is; however, I've always been struck by how quiet it is, even when hundreds and hundreds of people are rushing through it. I made a five minute recording while standing a few feet away from the information booth in the center of the station. Afterwards, I extracted just the audible footfalls and the audible speech. Surprisingly, neither of these total more than twenty seconds.

Collage #3: "Speech" - Audible speech collected from a recording of Grand Central Terminal at rush hour. (Download)

Collage #4: "Footfalls" - Audible footfalls collected from the same recording. I suppose most people wear quiet shoes. (Download)

Collage #5: "More Footfalls" - I layered and looped the sounds from "Footfalls" to make it sound like how it looks like it should sound: lots of people moving around. (Download)

The entrance to the 4-5-6 line from Grand Central is always busy, so the turnstiles are constantly making that high-pitched beeping noise. If you stand in the right spot, they sometimes make a continuous tone. I recorded that, then layered the recording and changed the pitch to see what it would sound like if you could make the turnstiles sing.

Collage #6 "Metrochord": The MTA turnstiles play a major chord. (Download)

I enjoyed playing around with the Max/MSP patch that Peter sent out earlier in the week, so I adapted it to get the random seek location using the Perlin Noise function from Processing, instead of the random object in Max. The result is that it will consistently seek to the same part of the audio file, moving smoothly toward the beginning or end of the file. The following two collages were made with the resulting patch.

Collage #7: "Perlin Stutter Conversation" - My girlfriend has bronchitis and is trying to quit smoking. This is a conversation we had last night, finely diced and julienned. (Download)

Collage #8: "Perlin Stutter Train" - An excerpt from my recording of a ride on Metro North, similarly prepared. (Download)

Posted by Adam Parrish at 09:05 PM | Permalink | Comments (0)