Archive for 2009

« Previous Entries

Scents and Sensibilities

Scratch&Sniff


I am hideously behind in my documentation, so much so that I didn’t have anything up in time for the first day of the Winter Show. Which turns out to have been kind of a blessing, as I hadn’t really devoted much time to thinking about the project beyond trying to get it working. Which is uncharacteristic for me, though this project has been nothing if atypical.

The projects [1][2] I submitted to previous shows were polished and worked exactly as intended but were complicated to explain. They came with highly polished spiels that explained the hows and whys and, at least in my mind, completely airtight rationalizations for their existence.

But smells don’t bend to the will as easily as wire and LEDs. They’re invisible, often uncooperative, and, as I learned yesterday, highly subjective. The beauty for me of Scratch&Sniff has been the ease of its explanation (partly because the concept is simple: it’s a scratch and sniff television screen, and partly because I just haven’t had time to rationalize its construction beyond “wouldn’t it be cool if”) coupled with the growth of its meaning and interpretation while watching it in use.

Experiencing the wonders of scratch and sniff TV

In the past I’ve been afraid of allowing too much human element into my work. Both T.H.A.W. (a synthesizer interface that used a hairdryer and “melting” ice cubes) and Al-Gorithm (the paper output of a computer program written for a human being) minimized the subjective experience of the viewer/participant. They were both hermetic systems. You could like them or not, but you couldn’t really argue about how they worked or your role within them.

Scratch&Sniff on the other hand eschews all discourse in favor of an extremely simple concept that the viewer’s experience validates (or doesn’t, depending on the viewer). As at every show, the people I’ve spoken to have fallen into the three rough camps they always seem to:

  1. The Wowers: “This is so cool, how did you do it?”
  2. The Insiders: “This reminds me of a project by x at y, and have you thought about z?”
  3. The Skeptics: “What is the point of a smelly TV? How are you going to monetize it?”

The fascinating thing, though, has been how many people have taken issue with the project based not on how it works but on the smells themselves. “This smells like air freshener, not grass.” The technology vanishes! And what exactly does your TV smell like when you scratch it, I want to ask.

Another surprising thing has been the trepidation with which people approach scratching the screen (“Can I really push hard? Won’t it hurt the screen?”) coupled with the brute force to which they subject the obviously delicate surrounding foam core.

In any case, really interesting. I will post more once I get caught up with my documentation (and sleep) in the coming week.

tweepetry

My father-in-law is obsessed with Twitter poetry, or tweepetry, as he calls it. As someone incapable of succinct expression, I’m a great admirer of the masters of the 140 character quip, foremost among them the inimitable Anderson Miller and the by now overfollowed Shitmydadsays. I’m not sure anyone really knows what the point of Twitter is, but it does lend itself to recording felicitous turns of phrase, so I applaud my pop-in-law’s to up the literary ante.

As a gift last year, I made him a site that aggregates tweepetry using Seaofclouds’s nifty little Twitter-scraping javascript. The concept was super simple: tag any tweet with #tweepetry and it automatically appears on tweepetry.com. I added a couple of snippets to the code to remove the hash tag and done!

It worked great for a couple of weeks. Then the bits of tweepetry that had appeared on the site began disappearing. After three weeks, they were all gone. I did some research into the Twitter Search API and it turns out that only the last 10 days or so are indexed. Anything older than that can no longer be fetched dynamically using search. So tweepetry.com sat empty for six months gathering internet dust.

After three months of database programming, I realized I’d amassed the tools to resolve this problem so I revisited the site, rewriting everything but its visual elements from scratch.


Some recent tweeps


HOW IT WORKS

The site is still dynamic, but the dynamism is all backstage.

There’s now a php script running on my server that polls Twitter every 10 minutes (the maximum number of searches from one IP is limited to 150 per 24 hours). It talks to a MySQL database with two very simple tables, the first to recorded the id, username, time, and text of a particular tweet and the second to keep track of the id of the last tweet. I used two tables to keep my database queries fast. Every time the script runs, it searches Twitter for tweets that include the “#tweepetry” hash tag. If it finds some, it compares the id of the latest with the id stored in the second table. If they’re the same, nothing happens, but if they’re different, each tweet is stored in the database until the id of the last recorded tweet is reached, at which point it is updated to reflect the new additions. Then there’s a simple script that fetches all this information and displays it. That’s it!

The Kill Switch: Turn Off Sites At Will

Following the footsteps of fine sites such as bacolicious, fale.ca, and cornify, The Kill Switch loads any website of your choosing (save nytimes.com, which doesn’t play nice) into an iframe using URL rule rewrites in an .htaccess file to funnel whatever follows “/TheKillSwitch/” into a GET variable and superimposes a nice toggle switch with which you can turn the site on and off (toggling the visibility an initially invisible black div).

Try out the The Kill Switch or use the live example below by clicking on the toggle switch.




Ideally, your browser would remember which sites were off so that even if you closed the window or navigated away from them, the next time you tried to open them, you’d be redirected to my page until you toggled them back. Greasemonkey and SQL would do the trick, but that would limit the site to Firefox. As a compromise, I’ll try to have my site remember which sites are on and off, so that if someone else KillSwitches Google while you’re browsing it through my site, it would turn off for you too.

John Dimatos alerted me to a much more elegant solution which is both way beyond my ken and also way too irreversible (and way cool too). Steve Lambert’s Self-Control is a little application that allows you to blacklist websites for a specific time period. It works on a system level (I’m guessing on your hosts file) and is a real bitch to shut off when after three hours, you regret the bravado that led you to believe you could go without checking your fantasy team for a week.

Get meta or
suicidal.

Hours of fun.

It’s been a while since I really dug into the web, and I hadn’t realized just how shitty sound playback is in pre-HTML5 browsers. Eventually, I got the sound working using Scott Schiller’s extremely elegant Soundmanager2, which uses behind-the-scenes Flash to deliver reliable cross-browser and platform sound with Javascript. Not ideal but certainly better than relying on god knows what sound plugin.

Recursive Concepts In Art: Dimensional Hanging Compositions

This second visit to the ideas that inspired AL-Gorithm last spring emphasized the question of authorship/ownership I obliquely raised in its predecessor. At one point do words stop being attributable? Is it at the word level, the sentence level, or perhaps at some sort of grammar-unit-agnostic semantic level? Jeehyun, Joshua, and I agreed that this new iteration should stress recursion—that every part of the project should reflect on itself and extend the idea of lexical recombination.

ITERATION 1: The project’s first focus is the only requirement of the assignment that spawned it—that we turn in a three-page paper describing our intentions and how our piece seeks to accomplish them. We each wrote a paper. We then cut up all the papers and reassembled them into a single paper (below). The title was a leftover scrap we felt captured both the spirit and intention of the piece.

FinalText

ITERATION 2: Since of each of us has a different native language, we translated the above into Spanish and Korean, passing the text through another level of filtration and reinterpretation.

ITERATION 3: We “performed” the paper, dressed in black and white to mimic text, in front of the class, reading it in a staggered, canon-like manner to get a variety of sonic overlays.

IMG_9761ITERATION 4: During our performance, we asked our classmates to stand in the center of the room and make a new text, providing them with scissors and glue and a blank sheet of paper to work with while we read. Ten minutes later, we had sixteen very different results (pictured below), though all but one used only the words we provided and the majority respected word boundaries. In the discussion that followed our performance, people commented that our dress, our demeanor, and our (physical) positions of power within the room combined with the obvious cues provided by the glue sticks and scissors at each station to make it almost inevitable that people would cut up the text we’d provided unquestioningly.

text

ITERATION 5: We printed out the Frankenstein text in all three languages and overlaid them to create a visual equivalent to the sonic cacophony of our performance. The various texts come in and out of phase much as they did when we were speaking.

amalgam

My original paper is here.

Celebrity Site-ing

phpnDRw7g

For my Dynamic Web midterm, I built a database to log and map celebrity sightings. I implemented sorting and pagination (and understand why there are frameworks built for dealing with such things), session variables, user accounts and tracking by hand. I also used Google’s Static Maps API, which requires no Javascripting—just pass in all your parameters in the URL.

I apologize in advance to any celebrities who might stumble on this site when self-Googling: I saw all of you; the dates, however, might be a tad shaky.

THE TABLES

Overall Structure:

phpnfsXQN

Sightings:

phpbuCk0R


phphycLrD

Linking Tables:

phpQq7pw7


Users:

phpZ6MgEU

EyeR

IMG_9427

I’m working with a small side-looking infrared emitter/receiver pair that I got from Sparkfun to see if I can detect blinks. My theory is that the surfaces of my cornea and of my eyelid will reflect (detectably) different amounts of IR light, thus allowing me to sense blinks. I’m getting awesome values from the pair using a 10k resistor, 25-1000, so almost the full possible range.

There’s not much reliable research online about the effects of long-term IR exposure. Some people say that because it doesn’t cause the iris to contract as bright visible light does, it will blind you if you look at it too long. Other people say that’s nonsense, claiming that the IR light in question would have to be much brighter than an LED to cause any damage. Still others (my favorite group) post frantically to medical forums after having spent hours staring at their remote controls while pushing the buttons (?!), suddenly panicked that they may have caused themselves irreparable damage.


I tested various brightnesses using a digital camera and varied resistance, and am using a highly directional light that will be aimed at the side of my cornea rather than directly at my retina, so I’m not too worried.

IMG_9428To detect reflection, the emitter and receiver need to be installed completely flush to the same surface and about 10mm apart. I get good readings when holding them up to my eye, a variation of between 50 and a 100, good enough to work with.

One hour later…

Mounted on the glasses, it doesn’t really work. There’s too much infrared variation in ambient light. I may need to use a camera. And my eye feels like I’ve been staring into the sun for too long. It might be fine to stare at an IR LED from a distance, but right up against your eye, it starts to feel not so good after very little time. I am nixing this particular plan.

New York Single-Handed

I noticed last winter that New Yorkers lose an inordinate number of gloves. I started counting on my way to and from school every day and gave up sometime after about thirty, lying in piles of slush or thoughtlessly trampled underboot. This winter I decided to do something about it.

NYC Glove Orphanage

The New York City Glove Orphanage is a collection of gloves found on the streets of New York. The site was an exercise in PHP and MySQL backend building for a class assignment, but the idea lives on. Initially the idea was to allow people to create profiles a la dating site for their remaining gloves (“looking for other my half”) or to use the site as a mismatched pair clearing house, but both of those require getting other people to come to the site. Too much work. In the spring when the gloves come off, I hope to have a box full that I can make something with, a tree of blooming fingers and palms I can “plant” somewhere along my daily route so that people can be reunited with their long lost gloves.

I have a couple of rules. I don’t pick up latex gloves or any other disposable glove (I count work gloves, of which I have one representative sample, as disposables because they are interchangeable, ubiquitous, and more often than not filthy). If I see the owner of a glove drop it, I return it immediately. I carry around a plastic bag for quick hygienic scoop-ups of gloves of questionable origin.

How Data Gets to Asia

Asian Crossing (Click to enlarge)
Asian Data Routes Visualization (Click to enlarge)

Regardless of where I start, it always takes me forever to get to Asia, though given a choice, I prefer flying overland from Western Europe. Data packets seem to make the same trip pretty effortlessly, so I was curious to see what route they take.

I selected thirty Asian websites and traced the route the data took from my computer in New York to get to them using Tellurian.net’s handy traceroute script (I’m behind an NYU firewall that makes tracerouting pretty difficult). The results were pretty crappy. Half the time, the trace timed out before it even reached Asia.

Show/hide raw traceroute data

I ended up using this nifty visual traceroute tool which uses Google maps to plot an approximate route to figure out how packets got from here to there. I discovered a number of interesting things:

  • Most data heads to China from the Los Angeles area, though interestingly enough, Baidu always seems to go through Mexico. I’m guessing this has something to do with the wires it favors.
  • The latency between hops once the data reaches China jumps from between 4 and 40ms to well over 200ms (an effect of the Great Firewall, I assume).
  • Because of this, most data that is bound for Asian destinations other than China tends to avoid China, with the notable exception of SK Telecom’s website which is routed through Suide, a Chinese city I’d never heard of.
  • The majority of the data lines belong either to Verizon or to AT&T, though there are other providers, such as Cogentco also pop up occasionally.
  • Many of the Indian and Vietnamese sites I looked up are hosted in the US so they didn’t make it onto my visualization.
  • Traceroutes are not all that reliable.

Interesting stuff. I’ll do the same exercise from Shanghai the next time I’m in China just for comparison’s sake.

« Previous Entries