ds1935’s blog

Two performers sit facing each other, each at their own computer. One performer begins by typing (with gusto!) a message into his or her computer. The other performer does not see this message, but when the first performer is finished typing, the second performer types a response into his or her computer based on visual and auditory cues (or whatever they choose to reply based on). Then the first performer replies, etc. This continues back and forth for five minutes.

Meanwhile, each performer is in fact typing in a message to a chat window that is being sent to a third party. The third party can project both halves of the conversation as it unfolds. The performers can be prevented from seeing the larger screen simply by placing a physical barrier between them and the projection screen.

“Incidental Choreograpy” is a game/performance that occurs on two levels. Players play a game using an interface that requires full-body movement. Playing the game moves the player through movement sequences that are distinct from the intended goals of the game and are intelligible to outside viewers as a choreographed performance.

This game/performance is an exploration of:

• ways that interacting with technology affects how we move our bodies
• intended movement and incidental/artefactual movement
• privacy of a game and publicity of a performance
• how two different types of intention (a engaging game and an engaging performance that is not just the game) might be coordinate to be successful at the same time

Further discussion on some underlying ideas and working plans can be found on Adam’s blog.

Things I am thinking about:

1. DDR, Guitar Hero, Wii, Donkey Kong bongos – games with larger-body movements, possibly disjoint mappings, and potentially interesting choreographies
2. Contort. Interaction driving body movement
3. XBee puppet show. Abstracting movement to data and then interpreting that data into other movement
4. The video photo booth. Public/private, use of interaction for purposes outside the interaction
5. Viewpoints for thinking about choreograpy.
6. William Forsythe for thinking about choreograpy.

Overview:

**Describe project

video of puppet show and screens showing it:

http://www.youtube.com/watch?v=0FoiqxTMU_o

video of the screen itself. a bit blurry! i’ll do a proper screen shot some before i dismantle the apparatus:

http://www.youtube.com/watch?v=PWnPmwgT_mM

(more…)

For the XBee midterm, Sarah, Shilya, Shin-Yi and I developed a screen animation in which ‘juvenile’ sprites of different species are conveyed across the screen, which contains four different terrains:

New sprites are generated on the beat transmitted by an XBee broadcast, and they move across the screen on a conveyor belt at a constant pace.

Each type of terrain is associated with an input from an FSR. When the FSR is stepped on/kicked, then all sprites in that terrain are kicked off the conveyor belt and into the terrain. Depending on the terrain and the species of sprite, a different ‘grown’ form develops.

Specifically, there are three kinds of sprites: plants (acorns), animals (eggs), and humans (babies). There are four kinds of terrain: city, desert, plains, and river. In the city, acorns grow into flowers, babies grow into people in suits, and eggs die. In the desert, acorns grow into cacti, babies die, and eggs grow into camels. In the plains, acorns grow into trees, babies grow into cavemen, and eggs grow into dinosaurs. In the river, acorns die, babies grow into swimmers, and eggs grow into turtles.

Initially we wanted the force of the kick to determine the length that the sprite traveled before landing, but we didn’t work out the physical form that would give us a good signal range before the assignment was due, so currently the FSRs are simply functioning as switches. (This is obviously not an optimal match between sensor and function.)

We also encountered a problem with missing beats. Currently, the FSRs are feeding into the same Arduino board that is reading data from the XBee. The Arduino collects data from both and sends out serial data–but on the same serial port, which is causing collisions. The solution should be a quick rewrite so that the Arduino sends out the collation of data as software serial, on different pins, rather than over the same serial port.

(more…)

Download Program

Dear ITP,
We here at BigBrother.15.4 would like to demonstrate the important educational and moral functions that the 802.15.4 protocol can serve when put to proper ends. To illustrate just one minor aspect of this protocol’s powerful scope, we will be providing a brief instructional film tomorrow at 4 pm, that all are encouraged to view.

You can participate in this landmark event by doing the following:
1. download the Processing program located at http://itp.nyu.edu/~ds1935/XBeePuppetShow.zip
2. set your XBee radio to PanID 3333 and connect it to a USB-to-serial converter.
3. shortly before 4 pm, place yourself within broadcast range of the lounge (the lounge, nearby classrooms. not too far.)
4. run the Processing program and wait for the film to begin.

If you do not have an XBee, please find a friend that does or watch the program on someone else’s screen. After all, the small broadcast range of the XBee radio equals togetherness.

If you would like to participate in developing further XBee radio broadcasts, please send project ideas to BigBrother at fifteenfour dot gov, and we will get back to you if we deem the moral content of your proposals to be appropriate.

Thank You,
The Management

I’ve been working with XBee radios this semester. One of the interesting things from Tianna’s talk last class was the idea of reconfiguring broadcasts to be a centripetal rather than a centrifugal force. –i.e., making a broadcast that brings people into a small area, rather than one that lets people hear it no matter how dispersed they are.

To that end, I want to broadcast a data performance over an XBee, where the data provides the information that can make the performance intelligible, and give audience members the code they need to listen in.

***

An invisible puppet show for XBees

–make invisible puppets (some springs, string, and pots as pulleys should do it)

–perform an invisible puppet show.

–take the data into an XBee and send it out on a broadcast channel

–‘audience’ can be anyone with an XBee and an arduino. Send them the arduino and processing code to make sense of the performance.

We’ll see how far I get by tomorrow evening.

I’m trying to detect my heart rate and develop some external response to variations–probably one response when i am particularly tachycardic, and one response when i am particularly relaxed.

As of Monday night, if I sit still, I can get a decent waveform and do slightly reliable beat detection (these are among the best results i’ve gotten. the first one is me, and the second is mike dory):

As of Tuesday night, I was able to have a self-contained (sensor, arduino, battery) module that detected my heart rate, identified beats, and activated a vibrating motor when a beat was sensed. Thus, a basic externalization of an internal sense.

This didn’t turn into any specific performance, but it’s part of a sensing system that I want to expand to include GSR, make wearable, and incorporate into a couple other projects.

The plan was to create a subliminal flash-mob, in which participants would arrive in Washington Square Park at 5:30 on Wednesday and received a phone call. Participants would then be asked to repeat a few phrases and then answer a simple question. Ideally, this would create a moment in which people in the park would heard a bunch of people having the same phone conversation at the same time. Among other things, we were trying to create a recognizable phrase which we will continue to exploit over the course of the next month, assemble participants who didn’t know the performance ahead of time and coordinate their actions in an externally coherent fashion, and create a moment that emphasized the performance of public cell phone conversations.

We recruited about 15 people, mostly  fom ITP and partially via craigslist, by sending them to a website to enter their phone numbers.

***

In practice, what happened was that we all assembled in the park and due to some obscure technical glitches, the phone calls never happened.

On the one hand, it felt like a failure of trust, as well as a failure of the project to happen as planned. It was also a reminder that we really should have had tech support (aka Adam) at a place with reliable internet access, logged into the Asterisk server, in the event of a failure.

It was, however, also an interesting moment to be in the park. While we knew some of our participants, recruiting via craigslist meant that there might have been people there who we couldn’t identify as participants. (Also made it a bit more frustrating in the end–the ITP people we could at least console with cake; any craigslist people got neither a phone call nor cake.) We arrived at the park a bit early, and there was something to sitting in the park, watching the people wandering around, filming the crowd, thinking that a performance was imminent, knowing the nature of the performance, but not knowing who was going to be performing. –and then having a failure of follow-through. A lot of people wandering around the park look just a little bit suspicious, like they are there for another reason.

I am not in favor of failing to follow through, but I did like that sense of feeling very aware of and reevaluating everybody’s purpose in a way I usually don’t.

Actually, using technology to radically reshape the body is one of the few combinations of performance and technology for which both are meaningfully and integrally connected. Sort of.  Barring an insistence that all life and interaction with other beings is performance, it is possible to reshape one’s body without performative intent. But it impossible to performatively reshape one’s body without the technology used to do so being an inextricable part of that performance.

This is much more satisfying to me than  the converse–performances in which  technology may or may not be necessary, but in which the technology that is used is given meaning predominantly through the context of the performance…

So perhaps what I am interested in is figuring out ways that technologies create or drive performances and performative spaces and modes of interaction. What sort of performance spaces are facilitated or created by technologies, particularly those that are directly connected to our bodies? How does that reflect back to our understanding of those technologies and their impacts?

In the a similar way to how you can argue that all life is performance, you could argue that all technologies create modes of performance. You can’t see a play in a playhouse without the technology to build that space, and you can certainly argue that the available materials and methods shape the shape of the building shape the possibilities of what that play can look like.

So maybe my question is what interesting or unexpected technologies drive modes of performance in interesting or  unexpected ways. What performances cannot exist (or cannot be adapted into intelligibility) without the technologies that created them?

I’m interested in seeing how my mood correlates with whether or not I am on my feet and when and how I am moving. I haven’t done that yet, but I have a feet-eye view of my life.

I hooked up 2 FSRs to each of my feet, one at the heel and one at the front. I used an old pair of Converse whose insoles are slowly falling apart, so I was able to prise the insole up and place the FSRs between the sole and the insole. I ran the flexible connector through rips in the fabric near the sole and connected the wires to long ribbon wires which run up my leg.

((photo))

((circuit diagram))

Currently, data from both shoes is feeding into the ADC ports of the Sparkfun datalogger and being recorded (at 10 Hz) as an array of bytes on an SD card. I added a potentiometer so I can (actively) indicate my mood.

I’m feeding this data into Processing (someone, please, give me a kick in the pants to move over to Eclipse!), parsing out the five pieces of information, and displaying it as follows:

The left strip is the front (left) and back of the left foot over time (the top is time 0, and the bottom is the end of the recording), and the right strip is the same data for the right foot. The colors are used to indicate my stated mood. There are some primitive zooming and scrolling options to allow a closer look:

Thus far, I have basically been able to visually identify when I am walking, and to a lesser degree when i am standing or sitting. I am particularly interested in when I am fidgeting, but I’m not as clear what that looks like.

The code needs a lot of work (I need to use objects a lot more heavily than I currently am), and I’d like to display this in three ways: as that larger graph (with an indicator of where in the graph one is looking), as a simultaneous closeup of a smaller section of the graph, and as an actual representation of feet with alpha as an indication of pressure, which can be seen changing over time.

Technically, I’m not convinced that the 5 inputs into the datalogger are entirely independent (the potentiometer is being wonky, which a potentiometer has never been for me before). Also, I *really* don’t think that indicating mood is the way to go. I am thinking of measuring heart rate and GSR as combined mood indicators (but am a little overwhelmed by finding and understanding op amps!), and then I think I will want to send all my data into Arduino, make the sense of it that I want, and then send it via serial into the datalogger.