Nick Didkovsky and Phil Burk
Photo courtesy of Nick Didkovsky
Part I: Nick Didkovsky and Hell Cafe
While most of us are happy enough to use computers to send email, surf the web, and write documents, there are people out there who use these machines for far more. These innovative programmers see computers and the Internet not as things with fixed limits, but as loose templates that can be stretched to their specific needs. And, interestingly enough, this group of people includes not only scientists and mathematicians, but also visual artists, actors, and yes, even composers.
One composer for whom computer programming forms an integral part of his work is Nick Didkovsky. The New York-based Didkovsky has written for many groups, not the least of which is the “avant-rock” septet he founded, Doctor Nerve. He also teaches computer music composition at New York University.
February 2001 found Didkovsky participating in a forty-minute experimental music theater work entitled The Technophobe and the Madman. The piece, which was commissioned by Harvestworks with funds from the New York State Council on the Arts, was a joint project of New York University and Rensselaer Polytechnic Institute. The commission specified that the work incorporate Internet2 technology – technology that allowed the musicians to be separated by 160 miles during the actual performance.
During the song “Jack Knife Society,” Didkovsky accompanied singer/lyricist Tyrone Henderson (the Madman of the title) on his laptop. Didkovsky crafted the music to sound like “techno” music appropriate to the setting, a fictional cyber café by the name of “Club Hell.” Didkovsky pointed and clicked; Henderson sang; Drew Waters played bass, all at NYU’s Loewe Theater; Dean Sharp played drums at RPI in Troy.
Behind apparent ease of Didkovsky’s improvisatory performance was an elegant, complex piece of software he crafted in JMSL, short for Java Music Specification Language. JMSL was developed by Didkovsky from an earlier version, Hierarchical Music Specification Language, or HMSL, which was designed and programmed, using Forth code, at the Mills College Center for Contemporary Music by Phil Burk, Larry Polansky, and David Rosenboom.
Both HMSL and JMSL are Application User Interfaces (APIs). APIs occupy the middle ground between source code and software. Most of us buy software; with software, everything written in an actual computer language – Java, C++, Python – is hidden behind a nice, user-friendly GUI (graphic user interface). You use it, and you can’t mess with it. With an API, you don’t have access to the source code itself, but you’re not exactly “pointing and clicking,” either.”
“An API is like a toolbox,” Didkovsky explained. “You follow some rules about how to access the code, and then it just magically works for you. For example, if the API says “to draw a line from point (x1, y1) to point (x2, y2) make a call to the method drawline(x1, y1, x2, y2)” then you can be assured that doing so will draw the line you want. You don’t need to know, or care to know, about the source behind drawLine().”
HMSL was designed to allow composers to experiment with computers in composition and performance in a completely unbiased way. Composers who wanted to write music using HMSL could write programs that exactly suited their needs with only an afternoon of study. Didkovsky began writing his own music using HMSL in the 1980s.
In 1997, however, Didkovsky began porting selected ideas from HMSL to Java. The switch was prompted by the death of the Commodore Amiga, which Didkovsky had been using for his HMSL work. Like Apple computers, the Amiga ran its own unique operating system. Didkovsky replaced hid old machine with a PC in order to use San Andreas Press’s SCORE music typography software, but found that the Forth-based HMSL was incompatible with Windows, necessitating the purchase of a third computer, a Mac, in order to continue to run HMSL. “I didn’t want a third platform, so I didn’t buy a Mac,” Didkovsky explained, and besides, he felt that “HMSL wasn’t going anywhere – Phil Burk had pretty much stopped development on it.”
Photo courtesy of Nick Didkovsky
“It seems I backed the right horse by jumping to Java,” Didkovsky commented. Java was appealing because it was not platform specific, thus reducing the chances that the “Amiga problem” might repeat itself sometime in the future. Another benefit to using Java was Phil Burk’s concurrent development of JSyn, a Java audio plug-in, allowing for real-time audio synthesis in JMSL. The first piece Didkovsky wrote using JMSL was Deconstructing Schubert, for CRI’s “Alternative Schubertiade” in 1997 .
In The Technophobe and the Madman, Didkovsky was able to make much fuller use of the possibilities of JMSL and JSyn. Of course, during the four years since Schubert, Didkovsky and Burk have also expanded those possibilities. Have musical ideas inspired the technological innovations, or vice-versa? It’s this kind of “chicken or the egg” interaction between programming and composition that makes Didkovsky’s work so exciting.
There are other fascinating esthetic and ethical issues surrounding Didkovsky’s work. First of all, you can perform Hell Cafe online. But are you performing it – or are you actually composing it? You are far more involved in musical decision making than the word “perform” might imply. This then raises the question of who “owns” the piece. Is it “by” Didkovsky, or is it “by” whomever happens to be playing it at the moment?
An examination of Didkovsky’s software will probably leave you feeling that Hell Cafe is very much “his,” at the very least in the sense that the light bulb is Thomas Edison‘s and the Apple I is Steve Wozniak‘s. Compositionally speaking, it appears that Hell Cafe is also “his” somewhat in the same sense that Cage‘s works were “his.” Like Cage, Didkovsky went to a great deal of trouble to make the piece open-ended, even down to small details. For instance, the composer/performer can type in a number that will alter the “density probability” for any given sound. That number reflects an average number of subdivisions of the pulse that will be “filled in” with sound. The precise timing of these subdivisions and the number of them in row that will sound, however, is left up to random number generators.
Taking things one step further, some might argue that not just Hell Cafe, but all of JMSL is very much Didkovsky’s — that the whole API, in fact, is naturally “biased” towards the kind of music he writes. JMSL does appear to be most naturally suited to music based on repetitive algorithms (mathematical patterns) -but all music is based on algorithms, even if they repeat only once or not at all. “Algorithms don’t think in terms of musical style,” Didkovsky stated. Didkovsky has preserved the original intent of HMSL in JMSL: composers of music in any style should be able to write a piece of software in that will be helpful.
Didkovsky is certainly aware of “bias;” it was frustration with the innate bias of some commercial notation programs, in fact, that led him to incorporate a music notation editor, JScore, into the JMSL package. Like conventional music notation programs (Finale, Sibelius, et al), JScore allows users to enter and edit notes by hand. But because JScore is an API, users also have the freedom to design custom “transformation classes.” An example of a simple “unary” transformation would be the retrograde of a single line of notes; a “binary” transformation could be the “average” of the pitches and rhythms of two groups of notes.
Using JScore, composer/programmers can generate notes using mathematical algorithms and notate them automatically, thus drastically cutting down on the “lag time” that normally exists between the birth of a musical concept and its appearance on paper. Especially with complex patterns, composers can spend hours trying to figure out how to notate complex rhythmic and melodic patterns and then inputting the actual notes. JScore answers to this problem. Naturally, for composers who are not programmers, making JScore work efficiently may require forming a partnership with a computer-savvy friend – something Didkovsky also sees as positive.
At the moment, the only major drawback to JScore is that it doesn’t print directly, except as a “screenshot.” For professional-quality printing, it is necessary to export JScore files to SCORE, which runs around $600. Didkovsky is currently working on creating a version of JScore that will let users export files to Guido, which is free.
Didkovsky explained in an interview that he is looking for a way to “gently license” JMSL in the near future. “I wrote JMSL for personal reasons,” he commented, but recently, responding to “the needs of the community” he has built some features into JScore, for example, that he doesn’t routinely use in his own music – things like grand staff braces. For this kind of work, he would understandably like to be compensated.
Didkovsky is thinking about modeling his licensing procedure on the one currently being used by Phil Burk for JSyn. JSyn can be downloaded as a plug-in for free; a “lite” version of the SDK (Software Development Kit) can also be downloaded for free; the “full” version of the SDK is $90 ($45), and comes with a graphical sound editor called Wire, access to a password-protected website, free technical help and other goodies.
Information on JMSL is spread out on the web as follows: information on JMSL and HMSL, the JMSL SDK and a very readable JMSL tutorial, can be found at www.algomusic.com. Programming in JMSL also requires the Java Runtime Environment, which can be downloaded for free at http://java.sun.com/j2se/1.3/jre/; and quite likely you will also want to install Burk’s JSyn plug-in from http://www.softsynth.com/jsyn/plugins/. More specific information on Didkovsky’s interactive computer music, including but not limited to Hell Cafe, can be found at www.punosmusic.com. Demo applets for both JMSL (http://www.algomusic.com/jmsl/examples/index.html/) and JSyn (http://www.softsynth.com/jsyn/examples/) are loads of fun, and require only a Java-enabled browser and the JSyn plug-in.