A Week of Making: Day 4

We recently learned how to transmit signals using serial communications from an Arduino to the browser and produce an “outcome” with P5.js. Physical interactions, such as turning a potentiometer or pressing a switch, resulted in signals being passed from the Arduino using Serial.print().

As a prototype to explore this functionality, my partner, Bryan, and I built a rain simulator that was controlled with a force sensor. More force produced more rain drops. (link to code)

An early iteration of the code used three bands of values from the force sensor to trigger varying amounts of rain. A sensor reading between 0 to 300 created a light drizzle, 301 to 800 created a moderate rainfall, and 800 to 1023 resulted in a monsoon. However, we wanted a more nuanced gradient of falling raindrops. By using a “greater than” condition for the modulo operation was able to produce the desired effect.

Interacting with the computer using a device other than the traditional mouse, trackpad, or keyboard was thrilling. Using an unexpected mechanism can inspire interactions originally overlooked or not considered. After building the rain-maker, I’ve been considering what other mechanisms I could use to control a game and how unexpected sensors may challenge a user’s preconception of a familiar game. For example, what if:

  • interacting with a photo resister moved the paddle for pong?
  • two force sensors controlled left-to-right movement and up-and-down movement respectively?
  • a potentiometer was used to control an object balancing on something else?

A Week of Making: Day 3

Still wanting to work with sound, but feeling a bit defeated by yesterday’s (somewhat) unsuccessful pursuit, I wired up a potentiometer to a speaker. Turning the potentiometer controls the pitch as well as toggles between the two LEDs. This small project is an iteration on my previous “siren” in which the user alternated pressing two buttons to generate a distinct pitch associated with each LED. By now implementing a similar system but using the potentiometer, it’s a little more like a blended “weeee-wooo” sound heard from emergency vehicles. And I think the code is now more precise! Imagine the passenger in a police car having to turn a knob back and forth as they race to an emergency!

screenshot-2016-10-06-20-50-58

A Week of Making: Day 2

Input: Button; Output: Tone

After reading and researching alternative forms of writing music, I came across Terry Riley’s In C. It consists of 53 short musical phrases to be played in order, but each phrase is to be played as many times as each musician chooses.

Using this as a framework, I wanted to use a number of push buttons and associated speakers to act as each musician. When a button is pressed, the “musician” advances to the next bar. Until this event occurs, the phrase plays on loop. In this way, it allows an individual to perform the piece without requiring an ensemble.

So far I’ve programmed two buttons/speaker sets, as well as the melodies for 2 bars — but the speakers are playing the music in series rather than both outputting simultaneously. I suspect this has to do with my “play tone” code being part of the for loop and sequentially for each speaker. I think I might need to have the looping of sound occur automatically rather than reading the melody each time loop() is called over and over.

link to code

A Week of Making: Day 1

Input: Force; Output: Multiple LEDs

As a challenge for the week, I’ve set out to make a “physical-computing-something” every day. To start, I revisited an earlier prompt to make a Love-O-Meter. An increase in force applied to the FSR results in each of the lights turning on at different steps. More force = more love = more LEDs. I set the breakpoints to increase non-linearly so that (in theory) it is more difficult to be more in love.