So there is quite a large gap between this post and the last in terms of work done. Whilst the technology I was developing the project with didn’t change too much, I spent a great deal of my time refining its response to the interaction of the dancers. A decision made in my concept, I didn’t want to inhibit the movement of the performers, but instead the technology should support their actions.
So where possible, I continued to map the movements of the dancers and look for clear data that I could use as a trigger. Watching the incoming values within OSCulator and Processing was helpful, even if a little bit overwhelming – the most difficult part was refining the information to block out unwanted noise.
Here are a few sequences during the mapping process (apologies for the poor quality)…
Although I wasn’t able to get all the dancers in one spot this week, I did have a chance to map some of the movements from one, with my updated mapping code.
Sadly, the room wasn’t large enough to capture every movement with the static video camera, but the following examples will give you an idea of how the data I’m getting looks. Each graph shows (from top to bottom): pitch, roll and yaw of the Wii remote. For these tests, I didn’t hook up the leg controller (although the above code will additionally take nunchuck data if you want it)…
During the break, I met with the performers, who will be helping me greatly with my project. I had really been sweating on meeting up with them, because it marks the beginning of work really getting under way.
The following is a short video of some of the footage I captured whilst we were seeing what gave a workable output from the Wii remotes. No, the dancers weren’t drunk, but we did discover that using another body to stabilise each other would give a less erratic data stream from the Wii remotes. Very helpful when trying not to accidentally trigger events…
Disparate ideas came together quickly in class this week. With the amazing assistance of a guest tutor (who’s name escapes me now – note to self: find out name and compliment guest tutor), it wasn’t long before we made quick work of the structure of OSC and had a prototype sketch up and running in Processing.
Processing (left) and OSCulator (right) speaking to each other via OSC
As you can see in the above image, both Processing and OSCulator use the surprisingly logical OSC syntax. In this example, I’m sending the pry (pitch, roll and yaw) information from Wii remote number 1 to Processing. Each of these can be isolated as individual variables and put to use. For the mockup lighting rig sketch I put together in Processing (you’ll need the oscP5 library for this one), pitch and roll of the Wii remote change the intensity of the six lights represented in my original Concept Pitch…
I was given some excellent assistance by my tutor this week, in the form of a Processing sketch that receives OSC data. Using the oscP5 library, this allows me to take information from the Wii remote to OSCulator via Bluetooth, which is then passed on to Processing in OSC format.
Wii remote > OSCulator > Processing
Whilst the output of this Processing sketch is a reasonably primitive change in RGB colour mixing (dependant on the XYZ movement of the Wii remote), I don’t imagine that it will take a great deal of work to change this into something I can use as a DMX control.
This basic framework will be the visual side of my project. The next step will be trying to separate distinct messages from multiple Wii remotes at the same time, so that multiple stage lights can be controlled.
My post-rate over the past week or so resembles the Global Financial Crisis
Life (work + uni + Concrete) has killed my Uni Journal for Week 3. Which is a shame, because it was looking like I could really overachieve well into Week 5, or even Week 6.
So instead of trying to cover everything from a week or so back, I’m posting an apology by way of a hastily downloaded image and a promise that I’ll get back on track in the next few days, with some Week 4 madness. Prepare yourselves, because it’s all unbelievably amazing stuff.
Getting my hands on a Wii remote (Wiimote) in the studio was a surprisingly inspiring experience. What was essentially a class of playing Wii games, gave me a taste of what this controller is capable of outputting. It is clearly more sensitive than I expected, with the ability to send parameters from subtle movements, through to sweeping gestures. With my earlier look into OSCulator for Sound Media, it wasn’t long before I stole one of the controllers away from the Wii console and connected it up to my MacBook.
OSCulator makes it obscenely simple to get data from the Wiimote. It’s just a few short steps from first connecting the MacBook and Wiimote via Bluetooth, to getting OSCulator to change the Wiimote data into MIDI and sending it on to Ableton. Whilst my setup is still clearly unrefined, it was just a matter of minutes before I was using the Wiimotes as drumsticks to trigger Ableton’s inbuilt drum machine, Impulse.
I decided sometime last year that interactive/installation work was something that I really want to pursue. For me, the term ‘interactivity’ has little to do with the internet and fares little better when it comes to gaming (so far). I hope to take my own practice in the direction of dynamic and temporal installation design. Sound and light are two worlds that interest me greatly and when they’re coupled with exploratory interaction, I think some really amazing experiences can occur.
So, I’m quite happy to continue using Processing after the first Multimedia Authoring subject during semester one this year. Unsurprisingly, some of the students in our very small new class of five (!) were expecting to find themselves in a Flash design workshop and so the conversation took the path of explaining why concept is more important than software package. I’m really tired of hearing the complaints of people wanting to come to university just to work through Adobe/Pro Tools/Final Cut and then expect to walk into a top-level job in an international company. I can’t imagine that those organisations got to where they are today without innovation and amazing conceptual work. Not by knowing a simple program inside out. But I digress, and even I’m getting tired of this digression. Onto the semester ahead…
Wii remotes are a pretty nifty piece of hardware. Well, at least they were when the Wii exploded onto the market a few years back. Now, it seems the technology inside a Wii remote is carried around inside the pocket of every iPhone bearing Apple fan-boy around the world. The information being generated by the movement of this device is what we’ll be using this semester for interactivity, rather than continuing on with the camera-based work of session one.
1 Comment »
