a giant floating human face in The Rocks..inspired by Janus, the Roman god with two faces, Barker and Haeusler’s installation is part of their ongoing research into complex and non-standard media facades.  Janus uses social media and new technologies to engage the public and influence its art. Photovoltaic cells are used to power the installation.

The concept for the project was for the face sculpture to act as a mirror to the emotions of the city, as measured using the social media of mms, email and blog updates.  Toms’ earlier research had lead him to explore notions of the nature of facial expressions, our abilities to read and emote via the expressive capabilities of our faces.  With this in mind, it was an interesting experiment – is it possible to measure, collect and respond to accumulated faces – can you determine how happy a city is by watching its’ inhabitants facial expressions?I was invited to join the project as the software design component of the project, as Tom had seen some snippets of my interaction design work, as well as the work of my students in the computational environments class.  Naturally my first thought was to ask Frank Maguire if he was interested in joining me on the project – having worked with Frank on the Filtration Fields installation, his industrial design skills and generally snappy logical mind made him the perfect partner in crime..

The main crux of the project production from our end was in coding the algorithms which would translate images of faces into emotional readings (happy, sad, surprised, angry, fearful, disgusted and neutral), using these readings to trigger pre-recorded videos and controlling the video output to a non-rectilinear array of 192 pixels.Having worked frequently with camera images, facial emotions I was confident in that component of the programming, as with the data munging and video triggers.  However, having never used more than 4 LEDs to output recorded/live video, I couldn’t be so sure I could guarantee the display robustness – but with such a challenge, how could I say no to the project!After a few initial tests using a standard Arduino board in a non-stanard manner, I had managed to get ~20 LEDs lighting up with varying PWM values and we were off and running.  It turned out that the technique I had tested was naughtily using the arduinos’ onboard resources and was not a sustainable way of outputting video – so we had to look elsewhere.Options included using a daisy-chain of chips to multiply the output of an arduino duemillanove board, an arduino Mega and the phidgetLED 64.

With project timelines fairly short, we opted for the output mode we felt would be simplest/most trusted/idiot proof, which our experience told us would be the phidgetLED 64.  The phidget range of interface kits are bread and butter for the interactivation studio, as well as my computational environments students, as well as being able to claim a dedicated output of 64 PWM leds per board – which meant that we could order 3 and end up with spare LED output pins.The face itself could then be split up into separate sections to be addressed individually by each Phidget board – the forehead, center and chin regions containing around ~60 pixels each.  This allowed us to divide up the phidget output coding into regions and simplify a bit of our output matrixing.  I’d spent some time earlier working with maxduino to get greyscale LED output from pixelated video (a matrix of 6 x 1 pixels!), and luckily I was able to put that patch to work with a little bit of scaling, upgrading to the required resolution.The first issue we came to was the phidget method of sending single line matrices to the phidgetLED64 from top-left pixel to bottom-right pixel.  Since we were not working with a rectangular screen, each row of pixel data had to be offset from the starting 0 point, yet still line up with the neighbouring rows.

See Also;http://vividsydney.com/ http://www.smartlightsydney.com/artists/barker-and-haeusler http://www.timeoutsydney.com.au/aroundtown/smart-light-sydney–vivid-sydney.aspx

The DAB gallery sits nestled under the canopy of one side in the DAB courtyard, standing as a window into another world, a place of existence in the imagined mind of another.  All of our experiences in the DAB Lab gallery were of surprise and delight, the little gallery had observed us and prepared something appropriate to show.My initial thoughts for the piece revolved around an image I had imagined of the DAB Lab gallery space existing as a small part of a sensory system extending the fabric of the whole building – the glass wall fronting onto the courtyard was in fact the glass lens of a large and ever curious eye.  The rear wall of the gallery would be the retina upon which the useful information would be refracted and transferred for processing elsewhere.  Other senses of the building were to be placed in the surrounding architecture outside, remote senses (microphones as ears, light/temp/hum/vibration as skin) of a much larger organism.  Each of the senses would be dislocated but connected, each informing the other regarding the goings-on of people in the courtyard.As the project took shape, it became clear that the focus of the exhibition should not only be the ‘eye’ of the DAB, but rather the effort to interpret the overlay of many eyes, ears and other senses into information, all representing the happenings in the courtyard.  The focus of the exhibition is not the DAB Lab itself, but the affect it could have on the lives of people moving through the space in-between.  Each of the glass wall panels would form opposing viewpoints on the courtyard, illustrating different relationships between the viewer/participant and the data they created.  The concept of the DAB as being a semi-conscious entity gave us the notion of eyes (an overload of information, all visual and uninterpreted for meaning) and brains (filtered information, abstracted for patterns of activity).

More to come..

First of all I’m struggling to figure out the simplest way to map hue changes to the jit.lcd object in the Pixeltag project, but we’ll come back to that because there are more fun things to discuss in the meantime!

In the midst of pondering the application of hue data to the colour of the oval object in the program, I realised I didn’t have a clean way of getting to the hue data from my input device in the first place! The wii nunchuk dishes out y,m data in the range of 0.0 – 1.0 ~ useful ~ but nowhere near the polar coordinates called for by jit.hue’s ‘hue_angle $1′ arguement.

That is – until I did a bit of research on the conversion between cartesian/polar coordinates and discovered that it’s as simple as the following procedure;

Point at (x, y)
Origin at (xo, yo)

Then let
dx=(x-xo)
dy=(y-yo)

then distance of (x, y) from (xo, yo) is r at an angle of theta, given by

r=sqrt(dx*dx+dy*dy)
theta=atan(dy, dx)*pi/180 (theta in degrees)

But of course~!

So first I tried to use some fudged expr object [expr atan($f1\,$f2)] but it wasn’t working and I threw my hands up in despair! I dug a little deeper in to the atan~ function in max/msp, and came across the cartopol~ object and it’s help file – which does exactly what I need it to, all wrapped up in a single object. Fantastic!

So now I can convert up/down x/y data input from the wii nunchuk joystick to polar degrees for a jit.hue object to use! awesome.

The point of this post is to express my gratitude to the rest of the community of thinkers who posted bits and pieces of the solutions we discover for our problems. Without such a rich resource to mine through (and it does take some digging) we would all need to know everything about everything before achieving something others have done before us. Why reinvent the wheel if a solution has been made already?

Thanks to the DAB Lab opening night schedule (which happily coincides with the weekly experimentation playtime in the interactivation studio), I’ve had the opportunity to demo the project to a widely varying audience.  Last week at the Convergence exhibition opening I was able to test the project with none other than Charles Rice, Desley Luscumbe, Adrian Lahoud and Sam Spurr as my hapless guinea pigs.  Many others were also subjected to my user testing and the feedback was generally positive.  I’m excited to see that a project in such baby steps can take on a life such as this, allowing fantastic possibilities such as collaboration and further refinement.I’ve been posting videos of the project in action to vimeo, but in case you’re in lock-down mode, I’ll be looking to embed content directly into my posts rather than linking to 3rd party software.  We’ll see how things go, watch this space.pixeltag 081106 ft. Tony Curran from Jason McDermott on Vimeo.

Below is the first effort at sending Max/MSP data to a Processing sketch for output. The MaxLink object has made the task *almost* as simple as using the jit.lcd object internally in Max. Clearly the data needs to be massaged into a managable, or otherwise different form but this looks to be much simpler than initially feared.

I will be experimenting with the other sketches and patches packaged with the free object lib generously provided by the guys at jklabs, so there will be plenty more to come.

Also of note;
The image below links to screencast-o-matic, a free web service which will create an exportable, taggable, uploadable desktop screen grab from within firefox! no download or installation is required, simply select the size and away you go. I’ve exported the screencast as a .mov, but the link seemed more in keeping with the logic of the app. Enjoy!