It’s been a while coming, but we’re now ready to announce the musical line-up for the Spring/Summer 09 Finders Keepers markets in Sydney. With the exception of two artists, everyone performing will be on their Finders Keepers debut, making for a fresh and diverse music stage once again.
I’m currently putting the finishing touches on the music line-up for The Finders Keepers markets in December. I’ve been looking after the stage at the markets for a while now, and slowly we’re trying to make music a larger part of the event.
One of the ways I’ve tried to make the music more interesting is to take the same approach that the organisers have with designer applications: keep it fresh, different and interesting. I’ll put out the music line-up once I get confirmations from all the artists, but I am quite excited about this one: there are a lot of artists that will be new to the markets.
Also new for these markets is a set designer. Michelle McCosker is super-talented and will be putting together some larger-than-life set pieces for us. I’d better not go into too much detail about this just yet either. However, the addition of set design has also given me the prospect of adding some live visuals to the stage, which I can talk about…
There are plenty of excellent programs out there which handle live visuals. However, I decided to try my hand at putting something very simple together in Processing, just to see what I could come up with. I will put the code up as I progress, for any suggestions or advice you have – feel free to put it to use if you like.
For this project, I’m using the excellent GSVideo and GLGraphics libraries, which already seem to give Processing some much needed grunt in the visual department. I’m still quite new to the world of OpenGL, but it seems to be heading in the right direction for those of you interested in getting your hands dirty.
I just arrived home from stopping by the local to check out a (friend of a) friends’ band. They weren’t bad, but we did find ourselves making note of the bass guitarists dance moves – something akin to a chicken, pecking at seed. Which started the discussion: are bass guitarists a little bit wrong in the head? They seem to be lost somewhere between the show-pony lead guitarist and the awesomeness of smacking the hell out of a drum kit. Without the ability to play more strings than fingers, nor ambidextrous enough to flail around like a muppet, they’re left with a sad and dark little corner of the stage, propping up something patronisingly titled ‘the rhythm section’.
Care to tell me that I’m wrong and I’m also a jerk? Please do in the comments. When I return from our mojito-fueled Mexican party on Friday night, I shall promptly respond in a clear and concise manner, with more drunken thinkings.
To say there is a lot of buzz around the launch of Max for Live is something of an understatement. It’s done nothing short of send Live-loving music geeks into a frenzy around the potential for new ways of processing audio and connecting technologies. This last point is what I’m interested in, and seeing as I’m doing a lot of chatter around OSC for my Sound Media 2 / Advanced Multimedia Authoring project, I thought I should take a quick look at what Max for Live means for anyone else dealing with OSC.
MaxMSP and its (less attractive, but nonetheless charming) open source cousin PureData both allow for custom routing of not just audio signals, but a wider range of protocols. MIDI has been hanging around for a long time now, and it’s ability to communicate a large amount of data is pretty poor. This is why we’re now looking to protocols like OSC to deal with higher bandwidth inputs.
When I began working on my data[origin] project, I did take a look at the ability to tap into the LiveAPI via Python script, but pretty quickly I realised that with my limited knowledge of code, I was going to spend more time trying to understand it than moving forward. In the end I converted OSC to MIDI, which has it’s own set of problems but was a little bit more entry-level friendly. The addition of Max for Live will basically make OSC natively available within the Ableton environment.
In addition to the routing power of Max, there will also be live visual capabilities in the form of MaxMSP’s sister software, Jitter. This makes the package more exciting to me, because it will mean that much more can be done directly out of the single Ableton environment. It also makes the US$299 price tag (for owners of Live 8 – more confusing if you’re not an owner) a little more palatable.
Of course, if you’re just a music producer, Max may not offer you enough to justify the high price tag. I think it’s a more interesting prospect for those looking to extend live performance from the laptop to allow inputs from weird and wonderful controllers and output to screens, lighting, or really anywhere that your imagination takes you. If you’re a Live 8 user, you can download the public beta of Max for Live. I’m doing just that and will report back with my experience over the next couple of weeks.
Moving toward the final sound piece for this project was a case of refining what was already present and intertwining it within the performers’ movements. The bulk of the composition actually changed very little since Week 06, mainly because we needed to continue working with a set structure for the dance.
The resulting interaction was a combination of: performers triggering composed events; performers responding to the composition; and the performers creating the composition themselves.
The areas of performer control within Ableton Live.
What I’m showing in the image above is where and when the dancers could control the sound (this is just a section of the Ableton set, not the entire piece). The Scenes (horizontal rows) marked in yellow would not trigger until a predefined movement by the performers was completed. The Clips (individual cells) marked in red could only be triggered by the performers, and only within a certain period of time – marked by the red arrows. This mixture of effect and response seemed to work quite well. When I set out with this project, I didn’t want the technology to be the focus, but instead a supporting element to the performance itself.
Bang those pots and pans. A food protest in Mexico.
I caught the end of an excellent documentary on SBS today, called The Growing Anger of Hunger. It looked at the painfully disparate relationship between developed nations and the 3rd world countries being quite literally farmed out of existence. Of course, this story is nothing new. Pointing out the well known neo-colonial power plays at work is probably something best left to those who understand the politics better. Though, seeing this program did remind me of an interesting article I read in the September/October issue of Adbusters.
The ‘rostrum camera’ project was the most testing for me in Digital Video 2. If you’re not familiar with the concept of a rostrum camera, it is used often in documentaries or other films where there may not be access to moving image – a documentary about the First Fleet landing in Australia in 1788 would be a good example. To add some dynamism to the images, the camera will pan or zoom across the surface of the image. One of the best known examples of this – and one which was offered to us in class – is Chris Marker’s excellent La Jetée from 1962. This film was the inspiration for Terry Gilliam’s (also brilliant) 12 Monkeys…
For the most part, I really enjoyed working with After Effects this semester, but as I’m a novice with the moving image, there are more than a few caveats which I stumbled across in my enthusiasm. Being the trouble child in class, I didn’t want to go down the route of using only 2-dimensional images. After Effects actually has some excellent tools for working in 2.5D (the difference between 2.5D and 3D is generally fairly academic here, but if you want to know more, Wikipedia is your friend), so I wanted to put them to use, whilst still exploiting the visual effect of flat surfaces.