Binary Telepathy

For our final 5-in-5 project, Anderson and I collaborated on an experiment concerning ESP. Inspired by Ganzfeld experiments and this recent interview with Matmos, we designed an experiment to answer the following questions: Can binary data be transmitted telepathically? If so, how accurately can it be transmitted? At what speed?

Here’s how the experiment works. The researcher (me) attempts to telepathically transmit eight bits of binary data (one byte) to the experiment subject. To help control for bias, the bits to be transmitted are generated at random at the beginning of each experiment, and the researcher and the subject are located in different rooms while the experiment takes place. The bits are communicated sequentially; a series of timed tones, under the control of the researcher, regulates data transmission (letting the subject know when to move on to the next byte).

Our experiment today incorporated eight subjects, each of which attempted to receive eight bits of information. The total amount of attempted information transmission was eight bytes.

Here I am, trying to visualize and communicate zeroes and ones

Our colleague Vikram tries his hardest to read my mind.

Check after the jump for the results. Also make sure to check out 5-in-5 Guest Star Andrew Schneider’s first-person documentation of being an experimental subject.

Results

The above graph shows our results. Out of 64 bits, 36 (or 56%) were transmitted accurately. One subject (5-in-5er Kristin O’Friel) managed to accurately receive seven out of eight bits. The average experiment lasted about ninety seconds (from the beginning of the first bit to the end of the last), yielding a data transmission rate of 0.08 bits per second.

The following diagrams are a graphic representation of the data that was transmitted and received. Each row of squares in the diagram corresponds to one subject.

Image of the bits sent

Image of the bits as received by subjects

Image of correct bits (green = accurate transmission, red = inaccurate transmission)

Here’s the worksheet that we gave to our subjects to record their reception of the data. Use this worksheet at home to replicate our experiment.

Future Directions

While our experiment was neither rigorous nor precise, we are nonetheless encouraged by the relatively high accuracy (6% greater than chance) found in our results. We’re confident that the low speed of transmission—several million times slower than a typical WiFi connection—can be mitigated with training and disciplined practice. Eventually, the telepathic transmission of data could bring low-cost wireless network connections to many hard-to-reach places, while avoiding the controversial (empirically detectable) radiation associated with mobile phones and WiFi.

Concentrating on a bit

Add comment | August 1st, 2008

Strokeweight: Drawing Text

Today I made a New Interface for Textual Expression, as part of a continuation of my master’s thesis research. Strokeweight is an interface that correlates gestures of drawing to gestures of text. Click below to view a demonstration video on Vimeo. Technical details can be found after the jump.

(The source text used in the demonstration video is Lord Dunsany’s Poltarnees, Beholder of Ocean, which has nothing to do with fruit. I don’t know why I drew fruit. I guess I drew fruit because it’s easy to draw, and also delicious.)

Here’s how it works.

Strokeweight requires a two-dimensional array of strings. I created this array by running a short story by Lord Dunsany through a Markov chain algorithm, and then using the Markov chain to populate the cells in the array. The algorithm I used works like this: A random seed token is placed in a random grid cell, and this token is passed to the Markov chain to generate values for the surrounding cells. The tokens in those cells are passed to the Markov chain to generate values for the cells surrounding them, and so on recursively, until the entire grid is filled. You end up with a two-dimensional grid that has tree-like “strands” of Markov-compliant text running through it in different directions.

The “Markov grid” thereby created is loaded into a Processing applet, which associates the position of stylus (or the mouse) to a position in the grid. The string contained in that position on the grid is sent (via OSC) to a Cocoa application that actually displays the text. Lifting the stylus from the tablet (or releasing the mouse button) tells the text display to insert a new line; leaving the pen up for more than a second or so will generate a second new line.

Here’s how the interface is set up.

The relationship between the drawing and the text is not literal in any way, of course, but it does manage to capture a number of drawing-related gestures and translate them into textual “gestures”:

• Small, slow movements of the stylus tend to move along (relatively) coherent sequences of cells, and therefore generate (relatively) coherent text
• Large, fast movements skip across sequences and create less coherent text
• Detail work in which the stylus is repeatedly lifted from the tablet, then replaced, creates staccato enjambments
• Lifting the stylus to “rest” effectively creates a new stanza

Overall, I’m satisfied with the results, especially for a day’s worth of work. I’d like to think about making adjustments to incorporate stylus pressure, and maybe adjust the “markov grid” algorithm to create coherent text more frequently (or ditch the concept altogether).

Bonus for people who have read this far: a complete reading of the poem written in the demonstration video, read by yours truly (192kbps MP3). I did this mostly to test out ITP’s swank new audio booth.

1 comment | August 1st, 2008

twbasic: BASIC for Twitter

My day 2 project is called twbasic. It’s an implementation of classic, line-numbered, home computer-era BASIC that runs on top of Twitter. You can start using twbasic right now by twittering your program listing to @twbasic. Here’s how to get twenty rolls of a six-sided die:

@twbasic 10 for i = 1 to val(ARG$)
@twbasic 20 print rnd(6) + 1
@twbasic 30 next i
@twbasic run 20

(The above screenshot depicts twbasic providing a listing of the program above, and then the results of running the code.)

A reference for using twbasic can be found after the jump.

Twbasic Language Reference

Twbasic is built on top of Malcom McLean’s liberally licensed MiniBasic. Twbasic supports all of MiniBasic’s keywords (see the manual for a list and explanations), with the following additions and omissions:

• The INPUT keyword is unsupported. (It doesn’t make sense in the context of twitter, since there is no keyboard to retrieve input from.)
• An additional global variable, ARG$, is available to your program. This variable contains the whatever string follows the run command (see below).
• Keywords are insensitive to case. (MiniBasic requires keywords in all-caps. I found that to be annoying for use from mobile phones.)

Twbasic also limits the output of any program to 120 characters (approximately one tweet). The server is currently set up to automatically kill any twbasic process that runs longer than fifteen seconds (so keep your programs brief).

Using twbasic

To use twbasic, simply start tweeting your program listing to twbasic using the reply syntax, like so:

@twbasic 10 rem my first twbasic program
@twbasic 20 print "hello!"

To retrieve a listing of your program, send @twbasic list. Your program will be sent back to you as a reply, one line at a time. (This might take a while.)

To clear your current program and start from scratch, send @twbasic clear.

You can revise a line in your program by sending another line with the same line number. For example, if you had originally sent the program above, then sent @twbasic 20 print "goodbye!", then you’d receive the following listing from @twbasic list:

@twbasic 10 rem my first twbasic program
@twbasic 20 print "goodbye!"

Once you’re satisfied with your program listing, run your program with the following syntax: @twbasic run. Any characters following run will be available within the program as the ARG$ variable.

After you’ve run your code, twbasic reply with its output (if any). If you’re following @twbasic, the output will show up on your timeline. If not, you’ll have to visit twitter.com/twbasic.

(Please be patient with twbasic: it’s only as responsive as its friendly whale master allows it to be.)

Rationale

The abbreviated, text-heavy and asynchronous nature of Twitter reminded me of my formative years in front of a TRS-80 Color Computer 2. I used BASIC then, why not use it now?

While twbasic is mostly just a fun hack, it could potentially form the basis of a mobile, cross-platform programming platform. Twitter’s biggest assets are its scriptability (via the excellent API) and its accessibility (if you can text, you can tweet). So if you’re on the road somewhere with only your uncle’s crippled mobile phone, you can still use twbasic to write some trigonometry algorithms.

Let me know if you have any problems (that can’t be explained away by twitter’s recent flakiness) or if you come up with any ideas for interesting applications.

1 comment | July 30th, 2008

Mega Man Linocut Prints

My day 1 project was about an analogy between retro video games and printmaking.

The Nintendo Entertainment System has a limited palette: of fifty-odd possible colors, only twenty-five can appear at any one time, and only four of those can be used in a single sprite.  Games produced for the NES made careful use of this palette, expressing as much information through color as possible.  This is famously the case in the Mega Man games for the NES, in which Mega Man (our hero) changes colors to indicate which weapon he’s using.

In printmaking (and I’m a novice at this, so let me know if I’m getting something wrong), multicolor prints are often made by overlaying a number of blocks with complementary negative spaces, producing a number of interlocking monochromatic fields. Look at it sideways, and that’s a lot like how color works on the Nintendo.

As a means of investigating this parallelism (and making some fan art in the process) I made these blocks for a basic Mega Man sprite (his shooting stance).  There are four blocks: one for the background, one for Mega Man’s outline, and the two colors to indicate which weapon he’s using.  The blocks were made by drawing a 32×24 grid on the linoleum, then drawing an outline around the pixels that belonged to each color area.  I scored the edges of the areas with an exacto knife to ensure neatness, and then went at the thing with my linoleum cutter.  That was how I spent the majority of the day.

Once you’ve got your blocks, inking and printing a bunch of Mega Men is easy.  My first test print is at the beginning of this entry.  I think the ragged (”hand pulled” or whatever) registration served the subject matter, so I stuck with it for the rest of the day.  Here’s a larger composition I’ve been working on, in various stages of completion:

(detail from center top)

6 comments | July 29th, 2008