An article written for Electronic Musician Magazine, 1999.
MIDI has come to be the standard language that synthesizers speak to each other, but the designers of MIDI had a certain way of thinking about music that give it some built-in limitations. Most of the messages sent on a MIDI cable are based on the idea of someone playing a keyboard or other controller: keydowns, keyups, pressure, pitch bend, etc. And electrically MIDI is designed to have one source of information, again based on an extension of the idea of one player controlling a bank of equipment.
But MIDI can be bent and (mis)used to implement different notions of musical control. Since the early 80's I've been part of a musical group which has been using MIDI as a basis for a network of players' computers. We use MIDI in a way it was never intended to be used: as a medium of communication between electronic musicians.
The Hub is a computer network band based in the San Francisco Bay Area.
We are a group of six composer/performers who each have our own synthesizers,
controlled by our own computers, all interconnected through our central
"mailbox" computer, the Hub itself. (See Figure 1.) The whole point
of this exercise is to build music that arises out of the unpredictable
behavior of these interconnected systems.
Figure 1. Hub system topology.
Usually a piece is designed by one person, who comes up with a spec for what kind of data is interchanged between players in a particular piece. The players then program their own computers to have some behavior that follows that spec -- as long as their system follows the spec, which is usually pretty simple, they're free to do whatever they want. And in almost all pieces, we leave the actual sequence of music to the emergent behavior of the network; there are generally no preplanned figures or melodies. (Hey, it's experimental music!) Each player writes a computer program which make musical decisions in keeping with the character of the piece, in response to messages from the other computers in the network and control actions of the player himself.
The result is a kind of enhanced improvisation, wherein players and computers share the responsibility for the music's evolution, with no-one able to determine the exact outcome, but everyone having influence in setting the direction. The interesting thing about all this is that often the programs running in each machine are quite simple, and don't seem to be able to account for the larger structure that arises out of the communication of these machines. The Javanese think of their gamelan orchestras as being one musical instrument with many parts; this is probably also a good way to think of The Hub ensemble, with all its many computers and synthesizers interconnected to form one complex musical instrument. In essence, each piece is a reconfiguration of this network into a new instrument.
In this odd band, the work done by a player in a performance is a little
strange. Usually the pieces we set up are almost completely automatic,
no-one is playing anything on a musical keyboard, but the players
generally have some knobs and switches they use to fine tune the operation
of the algorithm running on their system. It's as if we really are
acting more like composers or conductors than performers while in
performance, just listening and making fine adjustments from time to time.
Originally, we all interconnected through a special computer (also called "the Hub") which we designed and built, and which formed a sort of electronic mailbox for players to send messages to each other. (Hear music based on this system on our first CD, The Hub, Artifact 1002.) This was a simple microcomputer board, with serial interfaces, that served as a common memory for all the players. Players' computers could write and read messages in this common area, and pieces were designed to take advantage of this capability.
Since that time, commercial electronic music had exploded, and MIDI
had matured. We now use a piece of commercial MIDI equipment (the
Opcode Studio V) for our hub, and the note-oriented nature of MIDI communication
has led to new pieces that somewhat reflect this bias.
MIDI was designed to allow one master — typically a keyboard
player or computer serving as a sequence player — to control a complex
orchestra of synthesizers, without any interaction with anyone else.
It takes some doing to fool MIDI into a medium for an internet-like system,
in which many message sources connect to many message receivers all over
the same network. Opcode's Studio V, a complex multiport 8x8
MIDI interface, has enough flexibility to do this work for us, and with
some fancy programming, serve as our message router.
We needed a general way for players to send messages to each other, with their source identifiable to the receiver. The Studio V allows great flexibility in rechannelizing and routing messages. For each of the eight available midi inputs to the device, a complex table of message routing and rechannelization can be set up, allowing messages to be filtered and routed and modified by message type and MIDI channel. Scot Gresham-Lancaster of the Hub came up with an elegant way to program the Studio V to serve as our router.
Each player is assigned a port on the Studio V and a characteristic MIDI channel 2 through 7. Since most of the hub musicians have single-port MIDI interfaces, channels 1 and 8-16 were allocated for each player to use to control his own synthesizer; the MIDI THRU output on each player's synth is connected to an input port (2-7) on the Studio V, and the same numbered Studio V output port is sent to the players' computer's MIDI input. This arrangement allows each player to work with only one midi chain: messages sent on channels 1 or 8-16 control his own synth, message on channels 2-7 go to other players. Studio V input ports are programmed to only pass messages on channels 2-7 on to other players. The Studio V uses the channel of the input messages to determine what output port (and therefore what player) to route a message to; in addition, the messages are rechannelized to tell the receiving player which player sent them.
Figure 2. Hub message topology.
Confused yet? The whole thing is much simpler in operation than it sounds when you describe it. Figure 2 shows how messages are routed and rechannelized between players. (This diagram doesn't show the real physical connection -- all players are really connected only to the Studio V, with two MIDI cables in and out.) Small numbers next to nodes represent the channel on which a message is received or sent. For example, if John wants to send a message to Scot, he sends it on channel 7. The Studio V routes all messages on channel 7, from any input port, to Scot, rechannelizing them depending on which port they came in on. In this case, the message is from John, who is connected to the Studio V on input port 2. This tells Scot that the message is from John, since channel 2 is John's channel. Likewise, Scot sends to John on channel 2, John receives the message on channel 7, telling him it is from Scot.
The Studio V couldn't store and forward messages like our old
Hub, so on top of this, we implemented another specification to allow us
to do pieces that relied on everyone having a hunk of common knowledge.
We set aside channel 16, and the poly pressure MIDI message, for writing
common memory messages. Poly pressure messages sent by anyone on
channel 16 are routed by the Studio V to everyone, and the two data bytes
of the poly pressure message are interpreted as an address byte and a data
byte to write in a common memory space. Each player has the responsibility
of keeping an image of this common memory in their own computer -- there
is no real common space anymore. But this gives us a virtual scratch
pad of 128 common memory locations to use in our piece designs.
So what kind of music do we make with this system? One of our early pieces, called "Is it Borrowing or Stealing?" , by Phil Stone, has a very simple specification: the Hub was used as a repository for melodic figures. The only requirement was that whenever a player played a melodic figure, he reported to the central Hub what he had played, and put a copy of the information specifying the figure up there. Anyone else could take it down, use it, modify it, and play what they want. It's a completely open specification for what each player does: it's just that the computers have information about what the other machines and/or players are doing.
If this starts to sound like it has something in common with jazz, perhaps it does: although the sound of the music is really nothing like jazz. It does come out of a similar social idea, though. We didn't really plan to be a band at first: we built the Hub to facilitate a style of playing among a group of musicians that was active in the Bay Area in the early '80s. We envisioned a new form of music making akin to a jazz scene, where people show up and play together. What was going on was a scene where people would show up, hook their computers together and start jamming.
This communal aspect is one of the most interesting aspects of the work with the Hub. It really is a social experiment, as much as a technical and aesthetic one, and many of the pieces we've done are really about exploring the social permutations in this new way of music making. I did a piece in the late 80's for the Hub called "The Minister of Pitch" where I looked into apportioning musical responsibility in an unusual way. Players were assigned areas of global responsibility based on different musical parameters: one player was in charge of the pitch relations of all the players, another in charge of everyone's timbral decisions, another in charge of rhythm.
Other pieces people have done have game structures, in others players vote or bid on the musical direction, which evolved over time. In this sense the Hub is something of a laboratory for new kinds of collaborative work. If the Hub is one collective instrument, it's one which radically changes its character from piece to piece and demands different modes of cooperation -- sometimes competition between players.
One example of these "social experiment" pieces in the eighties, was called "HUB Renga." (The name is based on the Japanese poetry form called renga, in which different people each write one line, each responding to the previous line written by someone else.) HubRenga was a live radio performance, in collaboration with the Well, a computer bulletin board and messaging system. The Hub was connected to The Well through a dialup line in the studios of KPFA radio in Berkeley. The public could dial up the Well from their home and type in lines of poetry which would be read aloud on the air; this stream of text also was fed directly into the Hub computers, which were programmed to respond to certain "power words" in the text with musical actions of each composer's choosing. In the weeks leading up to the performance The Well poetry community had collectively compiled this list of power words.
As I mentioned above, one of the most interesting things that happens with the Hub setup is that surprises arise, there are sometimes patterns happening in the music arising out of the interaction of all the computers, that no-one put in there! I wanted to do a piece that focused on making this phenomenon as clear as possible, so I wrote "Waxlips," my attempt to do a minimalist hub piece. The specification is quite simple. Each player is requested to make his program have the following simple behavior: he had to be able to receive requests to play one note. When the request was received he should play the note, and then send a request to someone else in the group to play one note. This outgoing request must be computed from the incoming one in such a way that the same request in always generates the same request out. For example, any time I asked John Bischoff to play a C#, that would always cause him to issue a request to Chris Brown, say, to play an Ab. The mapping must be deterministic, and static. Every now and then I would send out another special message that meant "change your mapping", along with a pitch set of allowable pitches to request. I would also start the process off, and jump start it again when necessary by spraying new notes into the network.
This piece always came out very different each time it was played: usually we would end the piece when it fell into a simple loop of some kind; sometimes, if one of the players wasn't working properly there would be a leak and all the notes would keep dribbling out.
A number of other Hub pieces have involved different system configurations and experiments in telecommunications and audience participation. In the eighties, before the wide availability of the Internet, we did several performances involving remote collaboration, connecting two Hubs over a modem line with players in two locations, making linked performances.
More recent pieces take advantage of newer technologies: Points of Presence, a 1997 piece performed in three US cities simultaneously, used the Internet to send software synthesizer control information between sites. Six Macintoshes at each performance site were connected to the net, and ran the software synthesis program Grainwave, as well as a custom patch in Opcode's MAX musical programming environment. Each Hub performer controlled three computers, one in each city. A software simulation in MAX of our Studio V message scheme described above allowed us to perform versions of many of our earlier compositions; the "ghost" machines under the control of a performer allowed the music at each site, issuing from six machines to be the same.
"Luv Connection," a piece performed at Georgia Tech in Atlanta in 1997,
used the capabilities of a high-tech concert hall which had ethernet
connections at every seat. Audience members brought their laptops to the
performance, and connected to a special on-stage hub web server, which
in turn was connected to a port of the Studio V Hub and passed to the Hub
players information about the audience choices. Through a video projection
display, the audience members saw a score, indicating the progress through
the piece; their votes through the website controlled various timbral aspects
of the music as well as the progression through 26 sections. The piece
ended when the audience decided it would end.
The Hub has always been a live band : there are never any preplanned or precomposed sequences in any of the pieces, and the recordings we have released have never been multitracked or mixed in post-production in the studio. That's a basic part of the aesthetic, that we inherited from our forbears in this musical tradition, John Cage and David Tudor, among others. The music is always focused on the actual living behavior of a system.We're interested in music that is situated somewhere particular: in a real, messy, and admittedly limited social (and technical) situation. We build a quirky complex instrument, which, like any good instrument, has a strong nature of its own; our work is to play it, and bring out its nature.
Marshall MacLuhan used to speak of the computer as an extension of the
human nervous system; today, it makes more sense to think of the computer
network as an extension of society. The electronic networks surrounding
us have a degree of complexity which prevents us from "controlling" them
any longer: we have to participate in a conversation with them. In a conversation,
one says things, not knowing what the next person will say, and therefore,
not knowing what oneself will say next either. In the Hub we want
to surprise and be surprised by each other, and, in playing together, to
also be surprised by our own odd computer network instrument.
For more information on The Hub, visit the website of their label, Artifact Recordings, at www.artifact.com.
< BIO TAG >
Tim Perkis is a musician, writer and engineer living in the San Francisco
Bay Area. His homepage is at www.artifact.com/perkis.