Digital Studio – Week 07

I had a moment (or twelve) of hesitation about the direction of my project this week. After speaking to one of the lecturers at uni, I received my first piece of constructive criticism around my approach to this project. I’d like to think that I encourage critique on my work and ultimately this was a positive development, although it did leave me a little concerned about how to move forward for rest of this year.

In previous posts, I have mentioned that I wanted to keep in mind that this work will act as a portfolio for myself. That whilst this is quite an abstract work in the scheme of my course, I would like it to also showcase some of the commercial skills I possess. Of course, this means using all those industry standard software packages that I seem to love and hate in equal measure on this blog.

It was suggested to me that with the research focus of this project, I’m approaching this year more akin to an honours course – not a final undergraduate year. The outcome (and therefore marking focus) of our final year is a portfolio and everything that goes along with that: professional output, quality process, clear themes/goals etc. With my project being so intensely concept and research based, it’s unlikely that I could find the time to also mould this work into something that can be marked as a final year portfolio.

At this stage, I did what any other student suddenly without direction would do: I went to the pub. Pretty instinctively, I started sketching out a mind-map (above), fueled by beers and more than a small portion of fear. It was more general than those I carried out as a part of the early process of this project, but whilst simple, it has been very worthwhile. It’s re-focused me for the year’s work – without walking away from everything I have already done.

Importantly, I realised that I need to be documenting my work in a way that can form a portfolio, come year’s end. Much of what I do is time-based and difficult to present in hard copy. Unlike a photograph, or digital artwork, the type of work I’m interested in needs to be experienced, not simply seen or heard. And so, how do I get this idea across to someone who is potentially a future client or employer? I need to create a visual style for my documentation. I need to make what is essentially a design decision about how I will film, photograph and capture all that I do, so that when I put it all together, it creates something that is greater than the sum of its parts – it’s an experience of my ideas.

This all sounds a little ethereal and not necessarily related to my project, but I think it will be a hugely important step forward. If I am to be represented by my work and hired on the basis of it, the work needs to show I have a sense of style and self. When a company wants someone to create a 6 story interactive projection to promote their latest carcinogenic energy drink for 4 year olds, they need to know they can hire me, because my visual style compliments theirs.

And to that end, I need to know my tools. Extremely well. At this stage, it’s not important to show that I can use particular software packages, but instead to be able to create a watertight concept and see it through to a polished and professional final product – whatever that may be.

So I’ve chosen my software path, and I’m (hopefully) going to stick to it…

Max/MSP (MaxForLive) and Quartz Composer are really the main focus in the above diagram. I’ve been using Ableton Live for almost as long as I can remember, so that’s safe, and the input (motion tracking and/or sensors) and output (audio and projections) will be something I take a look at next semester. Max and Quartz will split the processing of data manipulation and generating of visuals respectively. This is where both programs really shine, so it feels as though this setup will be a good fit. And as I’ve mentioned before, I can split these programs up across 2 computers, allowing me to share the processing workload.

So now I can get down to the business of creating some serious output. I think the research will continue, but it will mostly be in the form of feedback from small-scale projects, rather than trying to quantify and understand what it is that engages an audience. This will get tucked away for honours, next year.

Something I have been working on (aside from this epic rant) has been a MaxForLive lighting rig for the Finders Keepers markets on May 7th and 8th. I book music artists and run the stage at these events and something that has always been missing is controllable stage lighting. We use the CarriageWorks foyer for the markets and the lighting is pretty basic. When I began using DMX with Live last year, I had in the markets in the back of my mind. However, it wasn’t until getting MaxForLive that it became a far more manageable proposition.

The excellent DMaX has provided a core for what will be my own lighting modules: one controller-based and one sound-responsive. One of the best discoveries I’ve made about Max/MSP, is it’s ability to send data between patches. This means that I don’t have to dig through lines of code to find each element – they can be separated and still communicate information between themselves. In the instance of my lighting setup, this means I can decide which lights I want to respond to an incoming audio signal and which lights I want to be controlled independently – keeping each in their own Live tracks…

%CODE1%

Something that I’ve been thinking about this week which is a new development, is the ability of the audience to capture the work. I would like to be able to give those who experience the project something tangible to keep. Particularly because this work is about a community creating something that wouldn’t exist without them, it seems only fitting that they could take away a screenshot of the imagery as they saw it.

My first instinct is to look into using the ubiquitous mobile phone as a means of triggering data capture. Creating and distributing an app for a highly transitory audience isn’t a workable solution, so that leaves me with the option of using Bluetooth or SMS. The immediate issue with the latter is cost (I have no idea how to setup a server for SMS receipt), whilst the former can be a little unreliable at times – as I’ve found from my own experience. Depending on the setup of the hardware in this project, it may require something like an Arduino Bluetooth module to handle the data.

After what I’ve just posted, it’s probably best that this idea stays on the drawing board for now. Something else to take a look at next semester.