Computer Musician, Programmer, Hardware Hacker

So, the first thing you’ll want to do is create a folder for your project. In the folder, you’ll want a copy of the files in this .zip archive. m_pd.h is a header file which you will use in every external you write. It allows your external to use the functions defined for use by PD. The makefile will automate the compilation process. You’ll want to edit it (using a text editor) to make sure the path to your PD.app is correct.

The .zip also contains a file called randomwalk.c that I’ll be using as the example file for these tutorials. Open it in your text editor. Skipping over the comment at the top, you’ll notice that I’m #include-ing m_pd.h. You’ll have to do that for every external, assuming you want it to compile.

Skip down a bit to this chunk of code:

static t_class *randomwalk_class; // declares a pointer to the object

typedef struct _randomwalk
{
t_object x_obj; // the required t_object
t_float current; // the current value
t_float step; // step width
t_float lower, upper; // bounds
t_outlet *f_out; // outlet pointer
} t_randomwalk;

The first line declares a pointer to your object, which will allow PD to reference it. We’ll define it below.

This defines the variables that your object will have access to. Every object needs to have the t_object x_obj; line, this allows the object to store PD-specific information, which we don’t have to worry about right now. You’ll notice that the next three variables are all of t_float type. This is essentially the same as a float variable, but PD defines it’s own atomic types, which are used to facilitate portability cross-platform. Here, I’ve defined three variables for the random-walk procedure. Finally, the t_outlet *f_out; is a pointer to an outlet. The name f_out is just a convention so that we remember that this outlet is going to output float's.

In the next segment, I’ll talk about our setup function, found in the

void randomwalk_setup() function below.

I stumbled across an essay on using improvisation in composed works by the French composer Vinko Globokar. Here’s the link, from the IIMA. Globokar did a lot of work integrating improvisation/reactive situations into composed music. His piece Correspondences is a great example of this. I found this article just as I’ve been struggling with similar issues in my current work.

This first sentence is quite telling:

The interdependence between composer and performer has nowadays become one of the fundamental problems in our music.

He writes of the desire to engage and involve the performer more deeply in a given work, by allowing them more of the responsibility than is traditionally given, but warns that this can compromise the aesthetics of the piece. (I think this can be overcome in a few ways, maybe most importantly by knowing your performers, but also by playing your own music.)

Globokar suggests a few techniques he uses to allow ‘improvisation’ in his works, without risking changes to his pieces. He defines five ways in which musicians can ‘react’ in a musical situation:

1. Imitation
2. Integrate Oneself
3. Hesitate
4. Doing The Opposite
5. Doing Something Different

Imitation is the most obvious, and I think ‘hesitate’ is maybe the least. It implies a sort of ‘disintegration’ of material, in which a player gradually breaks away from and eventually stops playing a given idea.

I think it’s important to note that although he uses the term ‘improvised’, he’s really referring to music that is primarily pre-composed, containing some parameters that are improvised or (more accurately) reactionary. An example of this (he gives a few) is a situation in which one performer has a set of pitches, and the other performers have to follow her pitches using their own prescribed rhythm. This creates a very interesting web of interdependence, and strikes me as a way to encourage a very active way listening in the performers.

He also writes a bit about the differences in writing this music for musicians with whom you’re familiar and comfortable with, and writing for yet unknown musicians.

He also leaves us with some direction:

Almost unexplored are moreover the various aspects offered by the reaction between performers. Even the relation: performer-performer – in which, for example, a performer, having material at his disposal which we have prescribed him in an incomplete form “searches for” the absent elements (which are, however, necessary if he wants to play) within the playing of his neighbour – yields extremely tense and engaged results. Even more interesting are the situations which oblige the performer to react simultaneously to the playing of two of his neighbours, thus having to analyse two materials at the same time.

It seems important today for us to create relations between performers in order that they should be tied more closely together, that they should be interdependent, that they should have the possibility of influencing each other. Exactly if we succeed in creating a variety of relations between them, not just musical ones but also psychologically, we arrive at making them interested in participating.

Finally, there are some good score examples, with explanatory notes. Go check it out, if you haven’t already. I also encourage looking at some of his scores, they’re beautifully hand-notated and generally pretty clear.

Edit: There appear to be quite a few interesting articles on similar (?) topics here.

Fission is a new piece which I’ve just finished. It’s for 3 performers, using unspecified (though melody instruments would probably work best) instrumentation. I ask the performers to listen for specific sonic events before starting, continuing, or ending their material, making the piece a sort of chain reaction.

Click here for the piece’s page, including a link to the score packet and, soon, recordings.

From the score description:

All performers should start at approximately the same time, reading from left to right. Pitches and durations are given in a proportional format (with a reference line for pitch), and performers should interpret accordingly. There is no set time-scale, though experience proves that an upbeat performance will be more successful than one at a slower pace. At the beginning and distributed throughout the gestures are square boxes containing one or more circles. The location of the circle(s) indicates an event which the player should listen for before beginning their next gesture. The beginning of the next gesture should correspond as closely as possible with the ending of the previous, listened-for, gesture.

The thing I enjoy most about this piece, besides that it’s a hell of a lot of fun to play, is the way it ends. Due to the combination of the cueing system I’ve designed and the way that performers get out of sync, the piece comes grinding to a halt before the end of the page, with the players stuck on their last material. The players switch pages and start again. It’s quick, can be VERY short, and encourages a strategic approach to the material that (for me) rewards repeated performance.

One of the other UWM composers, Greg Kurka, posted these pictures on my Facebook wall:

From left to right: Adam Murphy, Chris Burns, Joel Matthys, Greg Surges, Brent Coughenour

Kevin Schlei, Steve Schlei, Jon Welstead, Steve Nelson-Raney

You know, since making the switch to Max/MSP from Pure Data, I’ve been quite pleased with what Max has to offer. One area that I think is generally overlooked by Max users is the ability to use Max as an algorithmic composition language for acoustic composition.

I’ve stumbled upon these abilities after playing around with a few different languages/environments that function as compositional tools. PWGL and Common Music are both nice, I’ve even taken a course in Common Music, but they’re both Lisp-based (which for me makes them awkward – C is my first language, and I still think in terms of nested loops and function calls).

PD doesn’t really have any built-in tools for anything, which is good and bad – it forces you to really think through a problem, thus ending up with a totally unique and personal solution, but it also takes forever to accomplish complex tasks.

I tried using straight C/C++ to build my own tools, but that was ridiculous. I am not interested in spending more time than I have to for coding.

Max has the [zl] object, which provides a bunch of list-processing functions, many similar to some of the methods found in SuperCollider. There are sorting and comparing functions, along with iteration and scrambling capabilities. I mean, try using PD to make a random tone row generator which assembles a random list containing no repeated elements. In Max, it’s literally like two objects. Simple.

Now, not to sound like a Cycling ’74 ad, because proprietary software still kinda sucks and makes a lot of things more difficult for us, and because the help browsing in Max 5 is broken in Snow Leopard, but I think this is a fruitful area to explore.

You might want to check this out, too: Karlheinz Essl’s: RTC-lib