comment 0

Lumiere London: FIELD’s Spectra-3

The Lumiere light festival hit London this January, showcasing a whole host of installations across London ranging from flying fish to projections mapped on some of London’s most loved buildings. I was lucky enough to help out with FIELD’s installation, titled Spectra-3.

The third in the Spectra series of installations, it is described as: “an immersive audio-visual light experience: A physical-digital sculpture that tells three stories of communication, through a choreography of movement, animated lights and spatialised sound.”

Processed with VSCOcam with s2 preset

The result was hypnotising and beautiful to watch. The space was also filled with a score coming from a multi-channel setup that encompassed the sculpture, creating an absorbing atmosphere.

As well as helping FIELD install the sculpture I worked on the documentation shoot, assisting the lovely James Medcraft to photograph and film the installation. It was very chilly but we powered on through the night and early hours of the morning, and had a truly enjoyable time.

IMG_0225

Executive producer and FIELD co-founder Vera-Maria Glahn

Thank you to all of the team for including me on a great installation, and congratulations on the final result – here’s to Spectra-4!

More information about Spectra-3 can be found on FIELD’s website.

 

 

Advertisements
comment 0

Physical Computing [Lab 03.a]: Servos and LEDs and Motors, Oh My!

This week we started experimenting with a bunch of different components, from DC motors…

Week 3 Servo

…to servos…

Week 3 Servo

…and light dependent resistors!

Week 3 LDR

The above motor and servo experiments were created using code from the Arduino examples, and the automatic night light was built from this article.

After getting these components to work, we had a couple of tasks to complete. First of all, was to solder three LEDs and resistors to some perf board, then make them blink randomly. I busted the leftmost LED at some point, but can demonstrate that the circuit works by holding a fresh one to the back of the perf board.

Week 3 LED Random Flash

To make the LEDs blink randomly, I decided to use a random number generator. A random number between 0 and 299 was rolled; if it was between 0-99, the LED on pin 13 would flash; between 100-199 and pin 12 would flash; etc. Here it is in the code:

int rand = random(0,299);
int pin;
 
 if (rand >= 0 && rand <= 99){
   pin = 13;
 }

 else if (rand >= 100 && rand <= 199){
   pin = 12;
 }

 else if (rand >= 200 && rand <= 299){
   pin = 4; 
 }

digitalWrite(pin, HIGH);
delay(200); 
digitalWrite(pin, LOW); 
delay(200);

I’m not certain that this is the most elegant way of solving this problem (in fact I’m sure it’s not), but it works. And at this point, that’s all we can really hope for.

The final task for this week was to create a circuit by which a servo and LED could be controlled with one component. I chose to use the potentiometer, as I liked the direct relationship between the position of the servo and the pot; it seemed less gimmicky and more practical.

Week 3 Servo LED

Playing with this new toy, it suddenly struck me. As I turned the potentiometer, the servo began to point at me, and the LED lit up, almost like some kind of….human detector? So I decided to throw practicality to the wind and fully embrace gimmickry, and start building a fully-fledged human detector as my lab submission. See the results next time…

And, as always, you can see the code for this week on my GitHub.

comment 0

Physical Computing [Lab 02]: Noisy Video Synth

Welcome back for week 2! Let’s see how our little LED friend is getting on…

Week 2 LED Pot small

Hooked up to a potentiometer? Nice! That serial data looks great.

But could we perhaps use it for something a little more interesting? Something like…a noisy visual synth??

 

Of course we could!

So what’s going on here exactly? Well, we have a potentiometer hooked up to an Arduino Uno, which is sending values from 0-1023. This data is then sent to two places.

Firstly, the data is read by the Arduino and controls the tone coming from the surface transducer (basically a speaker without a cone – put it on something to hear it resonate!). I’m using the standard firmata example to grab the data and send it to openFrameworks, with some musical additions at the very bottom. I’ll paste them here for convenience:

 // MUSICAL ADDITIONS---------------------------------------------------------------

  int potValue = analogRead(A0);
  potValue = map(potValue, 0, 1023, 55, 110);
  int pause = 2 * 1.30;
  tone(8, potValue, 500);
  delay(pause);
  noTone(8);

So we’re reading the value from the potentiometer (on the analog pin 0) and mapping it to a range of 55-110Hz. This way you can get some nice clicking and buzzing, and even some phasing with the weird constant buzz that could either be coming from the surface transducer or the code. Who knows.

The data is sent to an openFrameworks project I adapted from a textbook, and have been using for live visual performances. I wanted to utilise what Hunt and Wanderly refer to as “one-to-many” mapping, with one component influencing multiple parameters. Using some code from the standard firmata example in openFrameworks, I was able to take the data from the pot and mapped it to eRad (the radius that the particles are constrained within), bornRate (how often new particles are created) and rotate (the direction and speed of rotation). Here’s the relevant code:

//--------------------------------------------------------------
void ofApp::analogPinChanged(const int & pinNum) {

    // analog pin event handler, called whenever an analog pin value has changed
    
    // do something with the analog input. here we're simply going to print the pin 
    // number and value to the screen each time it changes
    
    potValue = ard.getAnalog(pinNum);
    
    param.eRad = ofMap(potValue, 0, 1024, 0, 650);
    
    bornRate = ofMap(potValue, 0, 1024, 0, 3000);
    
    param.rotate = ofMap(potValue, 0., 1024, -300, 300);
    
    
    cout << "eRad: " << param.eRad << "   " << "bornRate: " << bornRate << "   " <<  
         "rotate: " << param.rotate << endl;
}

As always, the full code is available on my GitHub.

See you next week!

comment 0

Physical Computing [Lab 01]: Blink

For this term’s Physical Computing module (the final module of my MA 😥 ) I’ll be keeping a log of the work that we do in class, and the lab assignments. Hopefully it’ll be interesting to see the development from learning the basics all the way through to the final result!

For the first week we completed the “Hello World” of the physical computing arena: the LED blink. When I made my first LED blink back in undergrad, I remember it feeling absolutely magical. This code that I had written on the computer was making something happen in real life!! CRAZY! (And don’t even get me started on my first servo…)

So, to spice things up a bit (and because I had a raucous headache) I decided to make a little SOS beacon.

Week 1 SOS Blink

The code can be downloaded from my GitHub, or copied below.

First I create a boolean called ‘sign’, which controls whether the light should signal a dot (0) or a dash (1). I then have an array, called ‘pattern’, in which I store the various dots and dashes to signal S.O.S. A for loop iterates through the array, calling the respective dot() and dash() methods as appropriate. Simple!

See you next week!

/*
  SOS Blink
 Repeatedly flashes SOS in morse code.
 
 Based on the Arduino Blink code by Scott Fitzgerald.
 */

boolean sign; // 0 = dot, 1 = dash
int pattern[9]; // pattern of dots and dashes


void setup() {
  // initialize digital pin 13 as an output.
  pinMode(13, OUTPUT);
  
  sign = 0;
  
  pattern[0] = 0;
  pattern[1] = 0;
  pattern[2] = 0;
  pattern[3] = 1;
  pattern[4] = 1; 
  pattern[5] = 1;
  pattern[6] = 0;
  pattern[7] = 0;
  pattern[8] = 0;  
}

// the loop function runs over and over again forever
void loop() {
 
  for (int i = 0; i<9; i++){
   
    sign = pattern[i];
    
    if (sign){dash();}
    if (!sign){dot();}
  }
  
  delay(1000);              // wait for a second

}

void dot() {
 
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(100);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(100);              // wait for a second
}

void dash() {
   
  digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(400);              // wait for a second
  digitalWrite(13, LOW);    // turn the LED off by making the voltage LOW
  delay(100);              // wait for a second
}

 

comment 0

Bell Ringing and the Obsessive Compulsive Drummer

After going down to London Music Hackspace to take part in Dom Aversano’s Algorhythm Workshop: Hacking Church Bell Patterns, I decided to follow his footsteps and apply what I’d learnt about bells and change ringing to generative music: specifically, drum patterns.

Change ringing and how it relates to algorithms are well-covered over on Dom’s blog in the post, “Open source computer music in the ancient world”:

“Here is an example of a pattern generated by an algorithm for a three bell tower:

123
132
312
321
231
213
123

Each number above represents one of the bells, which are rung in the order that the numbers appear. In the above code every possible combination of three bells is rung, until the bells return to the order in which they started (i.e., the top and bottom rows, which are bold). The algorithm for computing this is relatively simple:

First switch the order of the last two bells (e.g., 123 → 132), then switch the order of the first two bells (e.g., 132 → 312), then repeat these instructions until you return to 123.”

(If you want to see how complex these ringing patterns can get check out the ‘Double Helix Differential Major’, which sounds like this).

And if you learn better by watching videos, this video spells it out quite clearly:

Dom highlighted how these patterns can be used to generate rhythms: for example, playing on the number 1, but not 2 or 3. He then went on to talk about how, as a percussionist, he had replaced each bell with a drum, using these change ringing patterns to explore (in a self-admittedly slightly obsessive manner) every possible permutation of a drum beat, given the kit in front of him. As a person with mild OCD and more than a few years behind the kit myself, this idea struck a chord with me.

Dom also told us that bell ringers used to have a pretty wild, rockstar reputation. I’d like to believe it true.

So I set out to create something. I can’t yet say what the final form will be — a sequencer, a plug-in, a drum-playing robot installation — or whether this idea will follow so many  of its half-baked brethren before it and dissolve into the ether. But for now I’ve started, and that’s great.

Its working title is “Obsessive Compulsive Drummer” (or OCD for short). I’ve been coding a program using Maximilian and openFrameworks which generates rhythms based on these change ringing patterns. At the moment I’m using drum samples because I like drums. Also, I like the link between the drum kit, as a divider of time and cue-er of musical events, and the bell tower, used to split the day into different segments (work, prayer, etc), paving the way for the mechanical clock.

Currently, I’ve got a 3-bell and 4-bell pattern (mostly) working. How it develops from here, we’ll just have to see.

comment 0

InC++ @ EXCEPT/0N 2015

InC++ was featured at Goldsmith’s MA Computational Arts summer exhibition this September. Thanks to all who turned out! For those who couldn’t make it, here’s what it looked like:

06
01

04

03

05

02

If you want to watch/listen to a stereo mixdown of the installation, it’s available here:

Or you can just listen to it on Soundcloud!