Terry Riley: “In C” (1968)
This is a piece for an indeterminate number and type of instruments. It’s at a moderate tempo and the dynamics are fairly constant throughout.
I like this work a lot. It’s mesmerizing. I’ve listened to it quite few times already, and am listening to it again, while I type these thoughts, but it’s hard, because the piece keeps drawing me in.
A weird thing about this piece is that it sounds like there are some improvised bits in the middle. Of course, there aren’t any improvised notes—the notes are written out, even though when to switch from pattern to pattern is improvised—but there is something that sounds like a recorder in the middle that seems to have made a break for it and gone over the wall. I wonder whether this sort of thing surprised Riley. Riley could have recorded this as a one-man band (by multitracking), but maybe this is the sort of (what to me sounds unexpected) thing that made him record it with other musicians.
This piece is really a sort of ‘cloud’ of possibilities that only ‘settles down’ or becomes well defined in a particular performance. It’s too bad that the CD captures just one realization of this piece. Even the same band, on the same afternoon, I’m sure, would have recorded a much different version of it. I wonder whether this (the fact that there is one ‘definitive’ version of this piece) disappoints Riley sometimes. The ideal ‘recording’ of this piece (in my opinion) would be a computer program that generates different interpretations.
In fact, Riley is sort of a computer programmer, as much as a composer, in the writing of this piece. . (IBM pays me good money, thank you, to write computer programs, so I hope (for IBM’s sake, at least) that I’m not being completely naïve in these observations.) In computer programming, you have to think carefully about every possible sequence of events (permitted by your program) that a user might come up with. This is not easy. The first thought that comes to mind when a programmer looks at many bugs is, “I never thought anyone would do that.†Now, what Riley is doing here is something much more complicated than your run-of-the-mill computer programming. What he is doing here is what is known in the industry as “multi-threaded programmingâ€. In multi-threaded programming, there are several paths of execution happening simultaneously. One thread might be responding to the user’s input through the graphical user interface (for example, dealing with button clicks and so on), while another thread might be doing some background processing (such as checking spelling in a document). And this only is a simple example. But, believe me, even simple multi-threaded programming can be hard. It can be very hard. One of the main difficulties is with conflicts between different threads (which I guess corresponds to dissonance or something in this perhaps tenuous analogy). “In C” is a multi-threaded program—each musician is an independent thread. However, Riley has managed to walk a very thin line in writing this multithreaded program. Not only do all the threads interact harmoniously (this would be easy—simply have each of the musicians play either a C, E, or G at their discretion), but also the music that results is interesting, not discordant. That is, it walks the fine line between homogeneity (or simple repetition) and chaos. (“It’s a fine line between chaos and creation,†as the Man said.)
Also, with this work, I would say that Riley pretty much invented the idea of loops. [I found out later that they were in use in the late ’40s and ’50s in classical electronic music.] The idea of tape loops had been around for a while. For example, the Beatles had used them as far back as 1966 in “Tomorrow Never Knowsâ€, and even they had gotten the idea from Stockhausen. But, the short musical phrases that make up “In C” are more like the loops used in musical software programs (such as Apple Computer’s GarageBand). That is, each is an atomic musical phrase, whereas tape loops tend to be a bit more free form and not necessarily atomic.