Archive for October, 2009
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
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.
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.
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.
So, I’ve got a new job. I’m working as a programmer for Bruce Charlesworth, a video/installation artist who teaches in the Peck School of the Arts. You can check out his page here – the current project is going to be a multi-room installation, involving break-beam tracking of audience members, and interactive visuals/audio.
Most of the code base I’m working with is Java-based, with Max/MSP/Jitter serving as glue between an Arduino, Java, and the projector. It’s a good opportunity to use the Arduino, something I’ve been excited about for a while now.
So, you can see why I haven’t been posting as much lately… quite busy. I will continue to post on this as it develops, over the year.
The first is the setup function. In my example file, it’s called:
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
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.
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
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.
I’ve posted the text (EDIT: Removed until publication.) of a paper I’ve written, which will be published in the next issue of JournalSEAMUS, the Journal of the Society of Electro-acoustic Music in the United States.
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.