First, let’s do a quick review of abstract classes. An abstract class differs from a concrete class in that it can never be directly instantiated. A concrete class must extend the abstract class, and that concrete class may be instantiated. All concrete classes extending an abstract class inherit functionality from a single abstract class—multiple inheritance, or inheritance from more than one class at the same time, is not allowed. Abstract classes may contain both concrete methods and abstract method signatures. Concrete fields and methods are inherited by subclasses. Abstract method signatures define a contract which subclasses must fulfill. For example, if your abstract class contains the code abstract void move(); then all subclasses must define their own void move() method.

Interfaces are a way of defining this kind of contract, but without specifying any functionality along the way. An object which implements an interface is committing to respond in a predictable way to a set of methods. For example, this is how you might specify an interface for objects that can move, and an object that implements this interface:

interface Moves { void move(int dx, int dy); } class Creature implements Moves { int x, y; Creature(int initX, int initY) { x = initX; y = initY; } void move(int dx, int dy) { x += dx; y += dy; } }

Note that when declaring a method signature in an interface (as opposed to an abstract class), it is not necessary to prepend abstract, as Processing/Java will figure out what we’re up to and make the method abstract implicitly.

But why use interfaces at all? Why not just use an abstract class, call it MovingThing, and have Creature extend MovingThing? Because while classes can only extend one superclass, they may implement any number of interfaces. For example:

interface Moves { void move(int dx, int dy); } interface ChangesColor { void changeColor(int newColor); } class Creature implements Moves, ChangesColor { int x, y, c; Creature(int initX, int initY) { x = initX; y = initY; } void move(int dx, int dy) { x += dx; y += dy; } void changeColor(int newColor) { c = newColor; } }

This is a way to get something a little like multiple inheritance in Processing/Java. Objects implementing these interfaces may not all do the same thing, as they each have the right to their own implementation, but at least we can be sure that they’ll do something when called forth to serve.

An object of any class which implements a given interface guarantees it will implement the methods described in that interface. Because we can be sure that an object of a class which implements an interface will have a specific set of features, Processing/Java allows us to typecast objects to the directly to the interface type. For example, say we’re writing a space shooter game, and we have an ArrayList called listOfSpaceStuff which keeps track of all of our moving objects on the screen. The list will hold objects of types Asteroid, OurHero, and BadGuy. As long as Asteroid, OurHero, and BadGuy all implement the interface Moves, we can do the following:

for(int i = 0; i < listOfSpaceStuff.size(); i++) { Moves movingObject = (Moves)listOfSpaceStuff.get(i); movingObject.move(dx, dy); }

Note that because each of our classes has its own unique implementation of move(), they can all move around the screen in a different way. Also note that we could have created a superclass implementing moves, SpaceThing, made Asteroid, OurHero, and BadGuy subclasses of SpaceThing, and then cast the objects coming out of the list to SpaceThing.

Before the final example, a warning about interfaces. Because interfaces only contain abstract method signatures, they pass along the burden of definition to implementing classes. While changing an abstract class can painlessly enhance the functionality of all its subclasses, changing an interface will more likely break your program, because all of the classes which implement that interface will need to be modified so they fulfill the requirements of the new contract. It pays to do some thinking up-front about how your interfaces are going to work, and whether or not the functionality they describe is likely to change, before using them extensively. (The flip side of this is, of course, that using abstract classes can cause brittle code of an entirely different sort. Interested readers might look to Why extends is evil at JavaWorld for some discussion.)

Here’s an example which uses class inheritance as well as interface inheritance, and typecasts objects to interfaces. Notice that Wall and Chameleon both implement the interface ChangesColor, but in dramatically different ways.

Source code: interfaces

Prerequisite to understanding this tutorial is having a decent sense of object-oriented programming, specifically how to define and use classes. This tutorial at the Processing website is a good start.

Here’s a common problem for Processing programmers. We have a bunch of objects, lets call them creatures, which are similar in some fundamental ways, but have differences which are not simply superficial. All of the creatures have a shared vocabulary of properties and methods: they all have a width and a height, and they all can be drawn to the screen. However, each creature has one or two actions which are unique. For example, one type of creature might search the screen for food to eat, another might change colors when clicked, and a third might be capable of spontaneous asexual reproduction.

The breadth of difference in functionality might initially suggest coding each creature as a different class, like this:

class Monkey { int w, h; Monkey(initWidth, initHeight) { [...] } void draw() { [...] } void lookForFood() { [...] } } class Chameleon { int w, h; Chameleon(initWidth, initHeight) { [...] } void draw() { [...] } void changeColors() { [...] } } class Amoeba { int w, h; Amoeba(initWidth, initHeight) { [...] } void draw() { [...] } void reproduceAsexually() { [...] } }

This is bad for two reasons. First, as Good Programmers, it offends our sensibilities by violating a cardinal rule of our craft: Don’t Repeat Yourself. We are specifying the properties of width and height as well as the constructor and draw() functions three times with no structural variation, so this is two times too many. Second, we’d like to keep track of all our creatures in one big ArrayList. While we’re free to add Monkeys, Chameleons, and Amoebae to an ArrayList, things go wrong when we try to take them out. Processing and Java will require us to cast the object we are getting from the list to a specific type. For example, we might want to do something like this:

for(int i = 0; i < creatureList.size(); i++) { currentCreature = (Monkey) creatureList.get(i); currentCreature.draw(); }

But what if the current creature is not, in fact, a Monkey, but instead an Amoeba? Then we’ll get a type error. We could keep separate lists of Monkeys, Chameleons, and Amoebae—but then we’d be repeating ourselves. And what if we later wanted to add GiantSloths or Tardigrades? Our code would be difficult to modify and maintain. Fortunately, we have a few tools which can help us out. The tool we’ll talk about today is the abstract class, which allows use of something called inheritance.

We can specify an abstract class, called Creature, which defines the properties and methods common to every object deigning to call itself creature. We can then implement subclasses of Creature (e.g. Monkey, Chameleon, and Amoeba) which have additional functionality of their own.

abstract class Creature { int w, h; Creature(int initWidth, int initHeight) { w = initWidth; h = initHeight; } abstract void draw(); } class Monkey extends Creature { Monkey(int initWidth, int initHeight) { super(initWidth, initHeight); } void draw() { [Draw a monkey.] } } class Chameleon extends Creature { Chameleon(int initWidth, int initHeight) { super(initWidth, initHeight); } void draw() { [Draw a chameleon.] } }

An abstract class is like a partially filled-in template for subclasses. Members of an abstract class can never be directly instantiated (that is, created directly). Given the code above, for example, it would make no sense to write something like Creature aCreature = new Creature(2,3);. Instances of classes like Monkey and Chameleon can be Creatures, but there’s no such thing as an object which is just a Creature and nothing else. Every subclass of Creature inherits its methods and variables. In this case, that means that Monkeys and Chameleons have integers for storing their width and height.

Abstract classes also make demands of their subclasses. The code abstract void draw(); means that every subclass of Creature is required to implement a function of type void called draw(). If a subclass didn’t implement this draw() function, we’d get an error. This set of requirements is like a contract that each subclass must honor. I’m going to expand on this notion of contractual obligation in the next tutorial, which will include a section on another tool we could use for this purpose: interfaces.

Additionally, something funny is happening in those subclass constructors. Subclasses are allowed to call the constructor function of their superclass, in this case Creature(), by using the method super(). The Monkey() and Chameleon() constructors just pass along the initial width and height values to the superclass constructor which handles the value assignment. If a subclass has additional variables not common to the superclass, those should also be initialized in the constructor. For example, Chameleons might want to store their current color in a variable, and begin life with a color passed to the constructor. We’d modify the Chameleon subclass as follows:

class Chameleon extends Creature { int c; Chameleon(int initWidth, int initHeight, int initColor) { super(initWidth, initHeight); c = initColor; } void draw() { [Draw a chameleon.] } }

Now we can populate an ArrayList with Monkeys and Chameleons, then iterate through that list, casting each item to the type Creature. Because the Creature superclass requires all its subclasses implement the draw() method, we can safely call this method on any Creature we get from the ArrayList. Here’s how that looks:

ArrayList creatureList = new ArrayList(); Monkey hanuman = new Monkey(4,8); Chameleon lizzy = new Chameleon(7,3); creatureList.add(hanuman); creatureList.add(lizzy); for(int i = 0; i < creatureList.size(); i++) { currentCreature = (Creature) creatureList.get(i); currentCreature.draw(); }

Mighty convenient. Now if we add additional variables or methods to the creature class, all of its subclasses inherit that functionality while preserving their unique features. Below is a complete working demonstration of these principles in action, using Ellipsoids and Rectithings, creatures which are much easier to draw than apes and lizards.

Click on the sketch to give it focus, then press the spacebar to move all the creatures to the center of the screen.

Source code: abstractClasses

Here’s a transcription of an excellent talk by Benjamin H. Bratton at Postopolis LA. Though it doesn’t take music or cognitive science as its primary subject, it identifies some cultural currents important to the social and political positions of both fields.

And here’s coverage of some interesting but deeply problematic research regarding the universality of musical emotion. The researchers had subjects who claim never to have heard Western music classify the emotionality of songs by pointing at pictures of faces expressing one of three emotions: happiness, sadness, and fear. I have not yet read the paper, but the media coverage is characteristically enthusiastic and uncritical, using such misleading and awful headlines as Feel-Good Music Feels Good Around the World and Language Of Music Really Is Universal, Study Finds.

Update: Decent coverage of the Mafa music study at Cognitive Daily.

The song’s provenance is unclear. In The Singing Englishman, A.L. Lloyd dates it to the peasants’ revolt of 1381. The despair caused by plague and oppression from the upper classes gave the folk songs of the era a rather dark vibe. The wren may be a symbol for the barony or the king or the police, i.e. not a small bird but a person of significant means—which would explain why it’s so difficult to kill, carry, cook, slice, and distribute.

Also possible is a Celtic mythical/religious interpretation, with the wren as a symbolic human sacrifice, cooked in the cauldron of Kerridwen. According to this page, the cauldron of Kerridwen was “the source of immortality and divine wisdom”, and the wren represents the Celtic god Bran, “an oracular hero, a being who linked the outer world with the Underworld”.

The way these two interpretations rub up against each other is fascinating. It seems like the song originally had a ritual, religious function, but was transformed into political commentary after the plague and the poll tax. Minton’s modern, surreal, expressionist solo brings the song into our current political/economic context, turning it into a commentary on globalization, seemingly endless war, widespread voter suppression, the near-nationalization of AIG, the $700,000,000,000 bailout budget, and other economic policies weighted in favor of the super-rich. In this climate, the sacrifice of the cutty wren brings a bit of a tear to my eye.

Simulation theories of emotional understanding posit the recognition of emotion necessarily involves some kind of internal simulation of that emotion. However, these internal simulations don’t necessarily have the same phenomenology as feeling (you can’t see it, but right here I am making a hand gesture to buttress my point!) elicited in a more direct way. The musical examples from Viellard’s library are a good example; they are (deliberately, rightly) cliché, boring, stripped of their expressive qualities. For the most part, I find myself recognizing the emotion I believe the music attempts to convey (with some exceptions, but as a composer I’m not an ideal candidate for this sort of thing), but experiencing nothing like emotion at all. Provisionally, I think this is a good thing. Music which elicits emotion rather than referencing it is slippery, different for different people, dependent upon context, maybe impossible to isolate and bottle. It’s nice to have a collection of musical examples which have been empirically assessed as accurately conveying a basic set of emotions, evocative sterility notwithstanding.

One fact which leaves me a little unsettled, mostly because these clips don’t cause me to experience any emotion, is that subjects performed better on the emotion identification task when they were told to focus on emotional experience instead of recognition:

“A significant effect of Instruction [i.e. the instruction to focus on experience versus recognition], F(1,37)=4.97; p=.032; h=.118, was observed, with a higher rating for the intended emotion in the experience condition (from .82 to .91 across emotional categories) than in the recognition condition (from .76 to .84 across emotional categories).”

I find that result very strange.

Another issue, somewhat less troubling, but still a bit problematic: A forced choice paradigm was used for categorization of the stimuli. For each stimulus, subjects were told to apply as many of the labels “happy”, “sad”, “scary”, and “peaceful” as they wanted, and the best label of those four was determined. Each of the stimuli were composed with one of those labels in mind, and so the intention of the composer was validated by the categorization task, but in a pretty weak way. What if, for example, an additional label had been allowed: “angry”? Would the categorization task then have clustered the stimuli into five groups, despite the compositional intention of conveying one of four emotions? It’d be nice to see a freer labeling procedure, it would make the library much more powerful.

References:

• Vieillard, S., Peretz, I., Gosselin, N., Khalfa, S., Gagnon, L. & Bouchard, B. (2008) Happy, sad, scary and peaceful musical excerpts for research on emotions. Cognition and Emotion, Vol. 22, Issue 4. 720-752.

• “What I Call a Sound”: Anthony Braxton’s Synaesthetic Ideal and Notations for Improvisers, by Graham Lock
• Form-Building Transformations: An Approach to the Aural Analysis of Emergent Musical Forms, by Lasse Thoresen, who is really interesting and deserves more attention than this single link. Maybe after the term ends.
• Composing the Pacific: Interviews with Lou Harrison, by Maria Cizmic.
• Hermeneutics of Suspicion: Paranoia and the Technological Sublime in Drum and Bass Music, by Dale Chapman. Takes as its starting points the soundtrack to the film π and Photek’s Two Swords Technique, both of which are classics dear to my heart. I learned to play Two Swords Technique on drum set with Steve Wilkes at Berklee, this makes me want to bust it out and start practicing.