September 2015

[pcomp week 4] The Lonely But Tender Ghost v.2, now with sound! (analog outputs)

September 29, 2015 / 1 Comment

It was fun playing with speakers and servo motors this week. After doing the labs, I focused mostly on doing things with sound, but in the future I’d like to spend more time experimenting with servos…

In the tone lab, I had some fun with the pitch library, and found it pretty easy to change the song played to something else:

I wanted to continue building on my lonely ghost project from last week. When I last left it, I had hand-sewn an FSR that caused an RGB LED to change colors depending on how hard you squeezed it. It was supposed to express “feeling” with the colors — green was good, red was bad. At that point, using colors were the only output.

I added a speaker to my breadboard and worked on adding sound in addition to color as feedback for the toy’s feelings.

The first thing I did was add the tone() function to the code so that when the variable “force” was 3 — that is, pushed the hardest, the speaker would make a noise in addition to having the LED turn red.

I thought the ghost could be made to be a bit needier. What if it got lonely if you didn’t pay attention to it for a period of time?

I used the millis() function to count the number of milliseconds that have passed whenever the ghost was squeezed. I then set a variable called lonelyTime, which was the amount of time it that could pass before the ghost got lonely. When the last time squeezed subtracted from the current millisecond count exceeded lonelyTime, I had the speakers make a tone. It would stop when you squeezed it again.

(I used the same method to make the LED blink when you weren’t squeezing the FSR, which I thought was a more natural neutral state than having the light just be white.)

This was nice, but all of the tones sounded pretty boring and static. That’s when I realized I could use the pitches library, like in the tone lab, to compose custom sounds for each state. I ended up making three:

in pain

happy

lonely

I was a bit surprised by how much more effective the custom sounds were at expressing feeling compared to the basic speaker tones.

Now, the ghost feels much more like a pet or a needy toy. When he’s lonely, the light will turn yellow and he’ll make the lonely sound until you squeeze him. If you squeeze him gently, the light turns green and he makes the happy sound. If you squeeze him too hard, he’ll make a distressing sound and the light will turn red. The blink effect makes it feel more alive as well.

Check out the video (with sound) here:

My Arduino code is below.

[video & sound week 2] Late

September 26, 2015 / Leave a Comment

Osama and I teamed up to do our Video & Sound assignment this week, which was to make a short soundscape.

We decided to tell a short story (of sorts) through sound, and did all the recording at my apartment. Osama ran the recorder and microphone while I did the “acting.”

Notes on editing:

Even though we ran through some basics in class, I found Logic to be pretty confusing — I guess it takes practice!
Upon opening the wav files up in logic, we saw that our levels were slightly on the low side. I’m not totally sure how to fix this except adjusting the volume knob on the track…
I’m not sure how to get rid of some of the microphone noises (mostly heard in the bathroom in our piece.)
I don’t know how to adjust some of the background sounds, or if that’s even possible in editing. For example, we recorded the sound of “running away” and “running towards” separately and in separate places, and the background hum in the “running towards” part makes the transition hard to sound seamless. (You can hear what I’m talking about around 1:16.)
I wasn’t sure how to organize my different tracks, or when to use different tracks.

Overall, we had a fun time recording and putting it together.

You can find the uncompressed version of the file here, and the Logic file here.

[icm week 3] Allergic to Love v. 1

September 24, 2015 / Leave a Comment

[TLDR: Here’s my (unfinished but finished-enough-for-this-assignment) game, Allergic to Love.]

Oh man, this was a rough one. The beginning was good: Esther and I partnered up to start this project. I really wanted to make a game, so we went down the path of trying to build something that involved shooting at objects that moved on the screen.

Together we got as far as making things fall down, making things shoot up, and coming up with an interim solution for making objects disappear as they got hit. Esther did some pretty awesome work figuring out how to use arrays and create functions, and then we took that code and built separate things on top of it.

I quickly realized that what I wanted to do this week was beyond the scope of what we’ve learned so far in class, so it was quite difficult to sort out some specific things. Once I came up with the theme of the game, it took me a really long time to figure out how to make all the falling objects in the shape of hearts. After some experimenting with for loops, making functions, arrays and bezier curves, I got it!

This was very exciting. I started adding things like making them fall from different heights and at different speeds. Some of the trickiest stuff to figure out was how to make things happen in the win state and lose state. I ended up having to add a bunch of Boolean arrays. It also started to come together aesthetically.

I added some fun things, like making the girl’s skin turn green every time a heart hit the ground. (She’s allergic, after all.)

//if the heart hits the ground
    if (hearts.y[i] == height) {
      if (hearts.hitTheGround[i] === false) {
        hearts.onGround++; // skin changes color
        skin.r = skin.r - 10;
        skin.g = skin.g + 5;
        skin.b = skin.b + 5;
        hearts.clr[i] = (0); //hearts turn black
      }
      hearts.hitTheGround[i] = true;
    }

//if the heart hits the ground

if (hearts.y[i] == height) {

if (hearts.hitTheGround[i] === false) {

hearts.onGround++; // skin changes color

skin.r = skin.r - 10;

skin.g = skin.g + 5;

skin.b = skin.b + 5;

hearts.clr[i] = (0); //hearts turn black

}

hearts.hitTheGround[i] = true;

}

I also had some crazy mishaps experimenting with the gradient that frankly look way cooler than what I was going for.

There’s still a lot I want to do, and the code is incredibly unfinished and messy. But it’s almost 4 am and I got this thing in a playable state, so I guess now is as good a time as any to stop. And even though I’ve been playing it all evening, it’s pretty hard! I feel like there’s still a lot to improve on here, but this will have to do for version 1.

Check out Allergic to Love, v.1!

My (extremely messy) code is below.

[pcomp week 3] The Lonely But Tender Ghost (digital and analog inputs, digital outputs)

September 21, 2015 / Leave a Comment

This week we learned how to program the Arduino to take inputs from our sensors and program them to make stuff happen.

I went to the Soft Lab workshop on Friday, where I learned how to sew a simple button, so I used that in the first example of alternating LEDs with a switch:

The fun part was using analog sensors to change the brightness of LEDs — I wired up a force sensor and a photocell to control two different LEDs on the breadboard.

I had a ton of ideas for our assignment to do something creative with these sensors this week, many of which sounded great in my mind but in reality were all varying degrees of unfeasible for the time being. One thing that stuck with me — newly inspired by the Soft Lab — was the idea of doing something with a doll or plushie. My goal was to make a plushie that gave you the sense that it had feelings.

I decided to go with a force sensitive resistor. The idea was that I’d make a plushie with LED eyes that would change color depending on how hard you squeezed it.

Here’s the circuit I built on the breadboard:

The map() function was really helpful for me to turn the input from the sensor into three different states, which I could then turn into colors. I learned how to use an RGB LED with the help of this example from Adafruit, and I ended up using the setColor() function written in that sketch in my final code.

The next step was to make my plushie!

I realized that my original plan to sew two RGB LEDs into fabric as eyes was actually extraordinarily complicated, so I just made the light separate from the plushie and went with the next best thing: googly eyes.

I built my own force sensitive resistor with some conductive material and Velostat, and sewed it all up in some felt to make my little ghost plushie. I noticed that the input values I got from the commercial FSR went pretty accurately from 0 – 1023, but my homemade FSR pretty much started at 750 or so rather than 0. I adjusted my variable in my code to accommodate it and it worked perfectly well.

I decided to call him the Lonely But Tender Ghost. In his normal state, the light is white. When you squeeze him tenderly, the light turns green. If you squeeze him too hard the light turns red. 🙁

This is just a basic first project, but hopefully later on I can further explore building an object that makes you feel like it’s expressing human feelings, perhaps creating sympathy or empathy in you, the user.

My full Arduino code is below.

[pcomp week 3] Design meets disability reading & observation

September 20, 2015 / Leave a Comment

from the Alternative Limb Project

This week’s reading was Graham Pullin’s Design Meets Disability, discussing both objects explicitly used to counteract a disability, like prosthetics, as well as objects used by people of all abilities that have varying levels of inclusiveness. Glasses are cited as an example of successful design for disability, to the point that people don’t consider poor eyesight a disability because glasses have transitioned from being medical devices to fashion accessories. This reminds me of Norman’s phrase, “Attractive things work better.”

I appreciate this perspective in the context of physical computing. If we’re designing for the human body, it’s important to take into consideration the ways in which people’s bodies and abilities are different, and to not take any particular ability for granted. I think it’s neat to see examples of things designed specifically for, say, wheelchair users, but also to see products that keep different preferences of usage in mind (a clicking sound and sensation, for example.)

(A small note on the examples: it was fun to see Nick’s Bricolo because we used to work together at my old job before ITP!)

——-

For my observation assignment, I decided to watch people use the entrance to the subway. More specifically, I watched them use the Metrocard slider that collects their fare.

According to the MTA, people swipe in about 1.7 billion times a year. That’s a lot! I’ve probably done it a thousand times myself.

That said, it’s certainly not perfect. My assumption is that people who are accustomed to the system — understanding which way to swipe and the specific speed at which you swipe — can move through pretty quickly within 3 seconds or so with no problem. But tourists, anyone that has insufficient fare on their Metrocard or any other Metrocard problem, or people that move too slowly I predict will have trouble with the machine.

I watched people use the machine at Union Square because there’s a lot of activity there, and locals and tourists alike.

I noticed that the people using the machines generally fell into three groups:

Confident and experienced users who got through with no problem
Confused users who had problems, likely tourists
Confident users who had a problem with their card

The first group was the majority of users who moved through the system quickly. The second group usually approached the machines slowly and often in groups, and would often swipe too slowly or too quickly, receiving the “Swipe card again at this turnstile” message. They would try again and again until it worked. This usually would take something more like 10 or 15 seconds.

The third group actually ran into the most trouble. People who were experienced and confident moved forward with the speed of someone who would get through in a couple seconds, but were halted by the machine abruptly if the card didn’t work. Sometimes they would almost run into the turnstile because the momentum was carrying them forward. Other times there were almost collisions with people behind them, especially if they had to turn back to refill their card.

In the case of insufficient fare, people had to go back to the machines to refill them, which could take up to a few minutes.

Developing the correct motion to swipe in a way that the machine understands is a skill that improves with practice. This is probably one reason why most other (and more modern) subway systems around the world use a tapping system, which seems to be easier for anyone using the machine, even if they’ve never done it before.

The way to solve the insufficient fare problem seems to be harder. It’s not an issue of not informing riders of how much fare is left (since it’s on the display when you swipe in), but people forget that they need to refill even if during the last ride they knew they ran out. It seems to be an issue of when riders are notified that they need to refill, which should ideally be when they walk into the station and not when they’re already at the turnstile.

A shorter term solution might be to design the space around the turnstiles in such a way that people can quickly exit the turnstile area if they need to, so it’s not a crowded bottleneck.

[video & sound week 1] Plagiarism, originality and remix readings

September 19, 2015 / Leave a Comment

This week in Video & Sound we read and watched four pieces of media: Jonathan Lethem’s The Ecstacy of Influence: A Plagiarism; b) On the Rights of the Molotov Man: Appropriation and the Art of Context; c) Allergy to Originality and d) Kirby Ferguson’s Embrace the Remix. The common thread between them all is the idea that no art or work is truly original or creative, and that this isn’t a bad thing. In fact, it’s inevitable, and it should be celebrated because we progress collectively through the efforts of the past.

Ferguson’s talk cites a quotation from Henry Ford: “I invented nothing new. I simply assembled the discoveries of other men behind whom were centuries of work.” And, as Lethem writes, “Finding one’s voice isn’t just an emptying and purifying oneself of the words of others but an adopting and embracing of filiations, communities, and discourses.”

I agree with the sentiment that our culture stands on the ability to borrow and remix ideas, and that openly acknowledging our influences as artists or inventors is important. But I’m also sympathetic to the people whose work gets “stolen” as well. Ideally, we could live in a world where everyone openly admits to using other people’s work and happily allows anyone to use theirs as well. But because it’s so difficult for artists to make a living to begin with, our flawed copyright laws sometimes serve as the only kind of protection they have for their income. It’s hard to fault an artist for feeling protective in an imperfect system, which is why I found Susan Meiselas’s rebuttal sympathetic and a necessary perspective.

[video & sound week 1] Reaction to “Her Long Black Hair”

September 19, 2015 / Leave a Comment

This afternoon I took the train up to Central Park with my iPhone and my headphones to… listen to? experience? walk through? Janet Cardiff’s sound walk, “Her Long Black Hair.” I really enjoyed it.

There was something surreal about the way that the recording overlapped with the sounds of the city. Immediately as it begins, you’re sitting facing the street traffic as the cars whiz by, and you’re not sure if the sounds of tires and horns is coming from your headphones or from the street in front of you. (The reality is that it’s both.)

My favorite moments throughout the whole piece were like these, where it almost tricks you into thinking a sound is coming from the outside when it’s actually in the recording. There was a part when I was walking by some tall rocks with children climbing all over, and it took me a second to realize that the voices of children I could hear talking to each other about climbing did not belong to the ones in front of me.

I also enjoyed the semi-linear, ambiguously fictional tone of the piece. It almost made it feel like a kind of proto-virtual reality, or even a type of videogame — after all, you follow her directions and feel rewarded whenever something lines up between the recording and your reality. Like when Cardiff describes the bird on the head of a statue, and you see it in front of you.

One of the most poignant moments on my walk was under a tunnel. In the recording, there is a man singing. On my walk today, there was a man drumming. As she has you linger and listen, the two pieces of music lined up in my ears as an experience that was uniquely mine.

[pcomp week 2] Electronics labs, switches, and CHOP TO THE TOP!!!

September 15, 2015 / Leave a Comment

This week in pcomp we got our hands dirty with circuits and components.

I spent a good amount of time getting to know the multimeter, learning how to measure resistance, voltage and current. One of the hardest parts about it was holding the tiny components, measuring them with the multimeter and trying to take pictures at the same time!

I also started building basic circuits with switches and LEDs.

To do the exercise with the potentiometer, I realized I had to solder wires on to the sensor, so I also learned to solder for the first time. It definitely wasn’t the prettiest solder-job in the world, but it worked.

Applying what we learned in the labs, our assignment was to make a switch. We were encouraged to be creative — “A switch is nothing more than a mechanism to bring two pieces of conductive material together and separate them.”

I decided to make a game.

I wanted to do something that tested people’s ability to use chopsticks. I decided to make something that would have two conductive parts with a wide space in between them. The pieces would be connected when people moved other conductive things together in between them so that the circuit could be completed, at which point a light would turn on.

In order to encourage people to use chopsticks to pick things up rather than push things around, I had to make the space between the two conductive points vertical rather than horizontal on the table. Aluminum foil—cheap and abundant—was my material of choice for conducting electricity. So I made a bunch of balls of aluminum foil of different sizes as the things people had to pick up.

The tubes I used were originally pen holders that I had cut the bottoms out of, glueing foil at the bottom and the top. I had to test if a bunch of foil balls stacked on top of each other would be conductive enough to connect the bottom to the top, so I first used the multimeter, and then wired up a circuit that made an LED light up.

In order to make this game a race between two teams, I had two tubes and wired up two switches and LEDs of different colors in parallel on my breadboard. So now there’s a green team and a yellow team.

I’m not 100% sure the schematic I drew is accurate, mostly because I’m not sure if the line in the middle is correct. But I think it is?

It started to come together, and I wrote the rules:

Light your color first to win. Turn on your light by filling your tube to the top with the balls. You may only touch the balls with chopsticks.

(2 players: each player holds a pair of chopsticks)

(4 players: divide in 2 teams, each player holds 1 chopstick)

A silly game deserves a silly name, and thus I call it CHOP TO THE TOP!!!

And voila. I had Aaron (yellow) and Sam (green) play the game to demo. The LEDs are tiny so they’re a little hard to see, but it works!

[icm week 2] The beach

September 13, 2015 / 2 Comments

(TL;DR: The final sketch is here!)

Create a sketch that includes (all of these):

One element controlled by the mouse.
One element that changes over time, independently of the mouse.
One element that is different every time you run the sketch.

This week’s exercise builds off of what we learned last week and added more dynamic, interactive and/or moving pieces.

I had an idea to do a sunset scene, where the mouse would control the sun and the rest of the elements would change when the sun went down or up. One of the first things I did (pictured above) was divide the height in two to make horizon. Then I made the ocean by making a large blue arc expand slowly, creating the effect of the tide coming in.

But I wanted the tide to also recede, so I looked up how to use an “if…or” statement:

if (oceanWidth = 800 || oceanWidth = 699) {
tideO = tideO * - 1;
}
oceanWidth = oceanWidth + tideO;

This basically made it so that when the ocean arc reached a certain size, it would get smaller until it reached its minimum size, at which point it’d get bigger again.

I discovered the helpful lerpColor() function, which allowed me to easily make a gradient of colors for the sunset.

But I also wanted to make the colors change as the mouse (aka sun position) changed. I figured that if I could make alpha—or opacity—a variable, I could make it change according to the y position of the mouse. I ended up making two variables that controlled opacity, one for more intense color changes and one for less.

 a = mouseY;
b = mouseY/6;

I used these for opacity in my lerpColor() function.

from = color(225, 22, 84, a);
to = color(243 - b/2, 255 - b/2, 189 - b/2, a);

I also ended up using these variables in a slightly different way as well — by adding or subtracting values to the rgb codes, I could also make the colors brighter or darker as the mouse moved. So my color variables ended up looking like this:

cloudColor = color(218 - b, 240 - b/2, 247 - b/2);
oceanColor = color(36 - b, 123 - b/3, 160 - b/3);
whiteWashColor = color(139 - b, 240 - b/3, 238 - b/3);
sandColor = color(194 - b/2, 178 - b/2, 128 - b/2);
sunColor = color(247 + a, 94 + a, 3 + a);

The screenshots above show you what it looks like when the sun is up vs when it’s down. I’m happy I was able to make the sky change dramatically, while allowing the trees, sand and ocean change more subtly.

For the element that changes each time you run the sketch, I have two birds moving semi-randomly across the sky. And for fun I added a little crab that comes out only when the sun goes down. I haven’t figured out how to make these random movements less jarring and terrifying, which would probably help make the entire scene a bit more relaxed and chill as a beach should be. Oh well! Maybe it can just be the eternal dusk beach of your nightmares.

As with last week, I had a ton of fun making this sketch. The screenshot above is just a still, so check out the full thing here.

The code is below.

[pcomp week 2] The design of everyday objects & physical computing’s greatest hits

September 13, 2015 / Leave a Comment

This week we read two works by Donald A. Norman: the first chapter of his book, Design of Everyday Things, and his essay, Emotional Design: Attractive Things Work Better. The first rails against everyday objects that are poorly designed, by which he mostly means difficult to understand and confusing to use. He cites numerous examples, like doors that don’t make it clear whether you should pull or push, the thermostat in his refrigerator, and now-almost-obsolete landline telephones.

Scissors, Norman says, are an example of a well-designed everyday object because their affordances, constraints and mappings allow you to easily form a conceptual model in your mind of how they should be used, even if you’ve never done so before.

His essay is a response to some criticism in his book that makes it seem as though he values usability over all else in design—beauty, in particular. His response clarifies that it’s not what he was trying to say, and that designing with people’s emotions in mind is equally important.

These readings make me wonder about the cultural influences in what makes something considered easy to use, or beautiful. I was recently in Japan, a land well-known for its design and usability of everyday objects. As a non-Japanese speaker, some things were easy for me to understand: a basket under your restaurant chair for putting your purse, for example.

Others were not. Many ramen restaurants have you order via machine rather than telling it to the waitstaff (pictured above). The idea is great, but I unfortunately lacked the cultural knowledge or reading ability to figure parts of it out—like how you have to put your money in first before pushing the buttons for your order, and that you have to hit the change button to get change at all at the end.

You only have to give any modern 3 year-old an iPad to see how much culture determines whether or not something is easy to use, so I wonder what kind of cultural assumptions are in the background for a person to understand how to use something as seemingly straightforward as Norman’s scissors.

The final reading this week was Tom’s blog post, Physical Computing’s Greatest Hits (and misses). It’s intimidating and inspiring at the same time to see all the types of projects that can be made with physical computing. What I like in particular is a sense of playfulness about most of them. We don’t necessarily have to create world peace with our designs—making someone smile can be a good enough reason to make something.

nicole @ itp

very serious blog for schoolwork

Month: September 2015