Networks collapse space by transmitting data in (nearly) real time. Telegraph messages reach their destinations faster than postal letters, telephone calls enable live, two-way communication, and current IM applications facilitate real-time audio, video, and text chat and even screen sharing. Networked art has long taken advantage of these tools. Cahill’s Teleharmonium (1897) transmitted live audio signals over telephone lines. Max Neuhaus’ Public Supply (1966) mixed sounds from callers for a live radio broadcast. Multi-location, multimedia performances such as The Technophobe and the Madman (2001) transmitted audio, video, and data streams between simultaneous performances in different cities.
Equally important, networks collapse time by storing data. When a telephone call is left unanswered, an answering machine or voicemail system records a message for later retrieval. When a server receives an e-mail message, it stores it in a user’s mailbox. Cloud computing services, social networks, and user-generated content sites create massive databases of content and commentary that users browse and contribute to. The sender and recipient need not be simultaneously connected to the network in order to communicate. The real-time connectivity is between a user and a database. The paradigm is more of a whiteboard than a conference call.
In this chapter, I will explore these complementary network functions and their role in networked art — collapsing space or collapsing time; transmitting data or storing data; facilitating real-time or non-real-time communication; creating environments for collaborative performance or for collaborative creation; and serving as mediums for teleprescence or for shared memory.
Through a comparative analysis of related works that differentially emphasize these functions, I hope to reveal how the focus of networked art works relative to these dichotomies is affected by technical network infrastructures, and how it affects the nature of collaborative creativity and the relationship of process to product.
Below are brief summaries of two categories of works I plan to discuss in the chapter.
The RS-232 HUB and the MIDI Hub
In 1990, the Hub — a San Francisco band of musicians performing on networked computers — decided it was time to change the technical architecture of their communications. They discarded their custom-built RS232 network, managed by a central computer, in favor of using a multi-channel MIDI interface and patchbay. Their move to off-the-shelf hardware and a standard communications protocol undoubtedly made their system more robust and their software easier to develop.
But they also gave something up: “The MIDI-Hub worked as a switchboard, not as common memory” (http://crossfade.walkerart.org/brownbischoff/hub_texts/MIDI-Hub.html). Real-time communication among players was simplified over the previous system. But there was no longer a central, shared repository of data that players could manipulate and from which they could draw.
This architectural change, favoring real-time communication over shared memory, transformed the music the group wrote and performed, as exemplified by the differences between Mark Trayle’s Simple Degradation (1989), in which waveforms are stored in shared memory and used for amplitude modulation; and Tim Perkis’ Waxlips (1991), in which MIDI messages are received, performed, transformed, and immediately sent back over the network.
Webdrum and SpliceMusic
No communication over the Internet takes place in actual real time. Beyond theoretical limitations such as the speed of light and practical limitations such as switches and relays, continuous media streams must also often be buffered to avoid dropouts from lost packets. For network musicians, even a latency of 20 ms can transform the experience of performing at a distance, as rhythmic cues continually arrive late and the tempo gradually slows down (http://ccrma-www.stanford.edu/~cc/shtml/ensDelay.shtml). Network musicians have developed a variety of strategies to cope with these effects, including performance in styles where rhythmic synchronization is not essential (http://www.academy.rpi.edu/projects/technophobe/) and artificial increases to latency to maintain beat, but not measure, synchronization (http://ninjam.com/).
Shared network memory provides an alternative approach to addressing network latency. Musicians manipulate a shared data structure to collaboratively compose music, rather than individually contributing audio towards a collaborative performance. Collaborative text editors such as SubEthaEdit (http://www.codingmonkeys.de/subethaedit/ ) or Google Docs (http://docs.google.com) serve as a useful comparison.
In Phil Burk’s WebDrum (http://www.transjam.com/webdrum/), users collaboratively manipulate a step-sequencer drum machine, creating rhythmic motives and configuring the instruments that play them, all while the multi-track arrangement of patterns loops again and again. A real-time text chat among participants sits beside the drum machine interface. The project is built upon Burk’s TransJam chat server, which includes features for storing and manipulating objects in shared memory. But though real-time communication is not integral to the collaborative creative process, simultaneous participation is: drum patterns cannot be saved or retrieved. The emphasis remains on collaborative, live performance, but with protections against effects of latency.
More recently, SpliceMusic (http://www.splicemusic.com), among other commercial endeavors, has extended this paradigm further out of real time. Participants use a Flash-based multi-track audio editor to create and remix music to post on the site. Besides commenting and voting on user-generated content, users can also remix songs to creative derivative works, and they can also use the source sound files in new musical works. On SpliceMusic, all of the collaboration takes place out of real time: the site makes no attempt to inform users when others are online. The emphasis is on composition: finished products, collaboration through a tree of remixes, and community mechanisms surrounding the core functionality.
Additional Examples
I also intend to discuss collaborative drawing tools (e.g. Scriblink, Swarmsketch, and iScribble); participatory radio works (e.g. Public Supply, Radio Net); and location-based works (e.g. ActionQuest, Yellow Arrow), among others. I am also eager to see what additional examples will be added as people edit and comment upon the chapter.