Computer Musician, Programmer, Hardware Hacker

Over the summer, I released two albums of my work with two European netlabels. Solid State, a collection of tape music, live electro-acoustic music, and acoustic chamber music, was released on Petcord, while Untitled, 2006 – 2009, a selection of recordings made with my custom software instruments, was released on Digitalbiotope.

I’ve had almost 1,500 downloads of “Solid State” alone, according to Archive.org. (Who knows, that number may be higher in reality… these are both Creative Commons licensed works, so copying and sharing is encourage.) I cannot think of a better way for a young, independent composer to gain a bit of exposure. Petcord also run a streaming internet radio station, Leftob, so anything they release (or anything else they find and enjoy) is given some play on the station. It’s a great way to get your music out to some new listeners, who might be tuning in because of another artists work that they enjoy.

It can be difficult, but it’s important to find a netlabel who has released similar music to yours. Petcord’s previous releases were not necessarily focused on the same things as mine, but Olliver, one of the operators, was quite interested and totally positive about putting my music out.

As you can see in some posts below, my releases have literally gotten global attention, from Hungary, to Estonia, and Duke University.

I’m thinking next about some netlabel-specific music releases, possibly consisting of a piece of software rather than a recording. More here when that happens.

In this section of the tutorial, I’m going to write about the randomwalk_new() function.

As you can see (in the code available here), the function takes three arguments. These are generic arguments, used in the *_new() function of every external you’ll write. The arguments are as follows:

t_symbol *s – a pointer to the symbolic representation of the objects name. You don’t have to worry about this, it’s for PD.

int argc – the number of arguments the user has entered, following the name of the object.

t_atom *argv – a pointer to the first of these arguments.

You’ll use argc to tell you how many arguments to read, starting from the argv pointer. This allows you to create an object that uses default values if a user doesn’t enter all of the required arguments.

In randomwalk.c, I’m using a switch statement to check the number of arguments provided, and then read the user-provided arguments into their proper variables. The atom_getfloat() function simply takes one of the arguments (of the PD type atom) and returns a C/C++ float, which can be assigned to a variable.

Below that, I reuse the argc count to determine which variables have to be assigned to defaults. Finally, I do some error checking to make sure that the highbound is actually a higher number than the lowbound, and swap if needed. This kind of error checking is very important to avoid crashes when actually using the object.

Finally, we have to assign inlets and outlets. The three calls to floatinlet_new() assign inlets which allow direct assignment of the lower, upper, and step variables from PD. There should probably be some error checking here too, because what would happen if a user input a list or a symbol instead? We also define f_out to be an outlet, using outlet_new() which takes two arguments, a reference to the object itself, and the type of value that will be output.

The return statement simply returns the initialized object to PD, ready for use.

Wow, I’m pleased and proud that my recent release Solid State – on Petcord – has been downloaded over 1,400 times!

If you haven’t heard it yet, it’s a free download, so check it out and tell your friends! The rest of the Petcord releases are good too, so there’s a lot to enjoy.

In this part of the tutorial (Part 1, Part 2), I’m going to talk about the first of two functions that PD calls when you ask it to create an instance of your object.

The first is the setup function. In my example file, it’s called:

void randomwalk_setup()

Here, you can see I’m finally defining the randomwalk_class that was declared above. The class_new function provides PD with some important information about the object. The interface is as follows:

t_class *class_new(t_symbol *name,
t_newmethod newmethod, t_method freemethod,
size_t size, int flags,
t_atomtype arg1, ...);

Obviously, I’m defining the name of the object here, with the gensym("randomwalk") code.

Below that, we allocate some memory with sizeof(t_randomwalk) (this returns the size in memory of our struct from above). You’ll probably never have to worry about the int flags argument, it’s mainly for the GUI representation of the object.

Finally, the t_atomtype arg1 stuff lets you define what kinds of arguments the object should expect. Here, the A_GIMME lets you provide a list of atoms of arbitrary length and types. You can check out Johannes’ tutorial for the full list of possible arguments here.

The last thing in the randomwalk_setup() function is class_addbang(randomwalk_class, randomwalk_bang);

This is where you declare the function your object will call when it receives a particular type of message in it’s inlet. The first argument should be the name of your class, and the second should be the name of a function which will be called.

In the next part, I’ll talk about the *randomwalk_new() function, which handles all of the arguments to your object.

So, in-between hearing undergrad drop-in exams (all white-key intervals), I’ve been working on the form for my current piece.

Everyone’s favorite scholarly source, Wikipedia, defines a Markov Chain as follows:

…A Markov chain, named after Andrey Markov, is a random process where all information about the future is contained in the present state (i.e. one does not need to examine the past to determine the future).

I think it’s best represented (and explained) using a probability chart, a chart which indicates the probability of a given next state, given the current state. I’m planning on using this to control the progression of form from phrase to phrase. Instead of putting the “criteria” or “decision parameter” (or whatever) at the beginning of a phrase, here I’m putting it at the end. So, it becomes an “if-then-else” procedure. If the criteria is met, the performer chooses the next phrase from one selection, else the performer chooses from a separate selection. I think this will work well, because it avoids the possibility of the piece getting “stuck” (a feature in “Fission“, but not here). It’s also interesting to me because it allows the formation of a dynamic yet consistent logic of phrase progressions. Phrase F will tend to be followed by Phrase D, etc.

The question then becomes, “How does this piece/section/part end?” This is something I’m still grappling with at this point. I’m leaning towards a sort of higher-level “Between 1:30 and 2:15, a performer can move to new material, which signals the other performer that a sectional change is occuring.” Rather than a sharp change, this would make a more gradual transition from one type of material to another. I think it could work. I’ll post some images soon, to demonstrate what I’m talking about.