Archive for the ‘General’ category

Analyzing reacTable through TAC Paradigm

October 8th, 2009

Token and Constraints (TAC) Paradigm

The TAC Paradigm describes a TUI as a set of TAC relationships, defined by tokens and constraints. In the example of the reacTable TUI, the tokens are those graspable pyfos – the tangible music controllers to be manipulated above the table-top surface. There are 6 groups of tangibles, including Generators, Audio filters, Controllers, Control filters, Audio mixers, and Global. The constraints are the bounds of the table-top surface, serving as a reference frame for the user’s interactions with the tangible music controllers, as well as the tangible music controllers themselves, as they relate to each other atop the surface. The variables – the digital information coupled with the tangible music controller tokens – are the behaviors of each of the tokens and the connections the tokens can make with each other.

Properties of the TAC Paradigm

There are five properties of the TAC Paradigm: Couple, Relative Definition, Association, Computational Interpretation, and Manipulation. We’ve already described Coupling as the relation between the variables and the tokens of the reacTable. We’ve shown Relative Definition exists when the tangible music controllers serve as both tokens and constraints depending on the table-top context. We’ll proceed by showing the latter three properties.

The Association property says that a new TAC is created when a tangible music controller A is placed upon the table-top surface. Because a tangible music controller is both a token and and constraint, the TAC consists of a token – the tangible music controller A – and a constraint list including the other tangible music controllers already on the table. By removing one of the neighboring controllers B, you remove not only one constraint from the TAC of controller A, but you also destroy the TAC associated with controller B, the token associated with that TAC. Likewise, when you remove the controller A from its associated TAC, you destroy the TAC and remove one constraint from each of the other TACs associated with the table-top controllers.

A token has Computational Interpretation when it is associated with its constraints. For example, when the user places a token atop the reacTable surface, it plays sounds and displays visuals (from the specific behavior of the specific tangible music controller). When the user surrounds the token by yet more constraints, any neighboring tangible music controller constraints, the token has more levels of computational interpretation (from the connections between the tangible music controllers). When the token is removed from the table (its constraint), the sounds and visuals associated with that token stop.

The Manipulation of reacTable is continuous. The manipulation of tokens and constraints atop the surface result in continuous feedback.

TAC Relationships in reacTable TUI

We can now describe the TAC relationships in the reacTable TUI:

reacTable TAC table updated

reacTable: Live Music and Tabletop TUI

September 28th, 2009

Design Concept

This TUI, presented as a tabletop music instrument controlled by pucks placed on the surface, revolutionizes the way we synthesize and perform sounds. The pucks used in the interface are easy to maneuver — they can be spun, flipped onto the other side, removed, or replaced. Depending on, for example, the orientation and relative position on the surface, the interface provides audio feedback and beautiful visual representations of the synthesized sounds.

Use Scenarios

It was designed for a diverse demographic of users, including visitors at a museum installation, casual users, and professionals in concert. Since there are no privileged points of view or points of control, it provides for a highly social and collaborate user experience. Unlike the TUI video editor or TERN, the possibilities and combinations on the reacTable are infinite, and the user’s continuous actions will result in realtime response.

Interaction Techniques

Each object represents a modular synthesizer component and has a specific function. Objects generate, modify, or control sound. A set of rules connects objects depending on type, affinity, and proximity to their neighbors.

The visual feedback projected around an object conveys information about the behavior of the object, as well as draws the connections between the object and its neighbors. The visual feedback can also convey the real sound waveforms. Users interact with the interface given these visual and audio cues.

Implementation

Components of the reacTable InterfaceUnder the tabletop surface, the TUI uses computer vision (camera) and a projector. The camera loads video into reacTIVision, which analyzes the markers on the pucks and their placement on the tabletop surface. The algorithms spit out a TUIO into the connection manager, which then transmits the connection info into an audio synthesizer and visual synthesizer. The visual synthesizer determines the video to be displayed through the projector. Meanwhile, the audio synthesizer not only plays the audio but also produces for the visual synthesizer the waveform data to be displayed.

Example of fiducials to be placed on the sides of pucks

Above the surface, markers and pucks tagged with fiducials provide the information needed for the detection algorithms written for reacTIVision. These markers and pucks are ideal for this interface because they allow for infinite combinations of patterns for information representation, and they are cheap to product. The latter reason is a particularly compelling for use scenarios such as a children’s museum, where markers and pucks can easily be damaged or missing.

Interface-related Skills and Knowledge

There are no skills required of the user, not even any related to the application domain, in order to perform on the reacTable. A user could certainly benefit from having knowledge in the physics of audio, since each synthesized sound is a function of a certain sound wave. The interface relies on a specific syntax comprised of 6 functional groups, including:
- Audio generators
- Audio filters
- Controllers
- Control filters
- Audio mixers
- Global objects
The pucks from each of the 6 groups have vary in their physical shapes and associated audio and visual feedback. They are designed to affect one another so that the final synthesized sounds can be very nuanced and complex. For example, the sound resulting from an audio generator can be further manipulated by N neighboring controllers. Thus, the reacTable is a venue for a variety of complex relationships between each type of puck. In order for an audio mixer to perform its function, it must be associated with 2 audio generators each with only 1 audio output. The audio mixer itself takes 2 audios inputs and returns 1 audio output.

Even without knowledge of these complex relationships, however, a casual user can still interact with the surface and enjoy an experimental experience.

To conclude, the reacTable’s continuous and multidimensional interaction combines “precision with freedom” and “expression and creativity with entertainment.” Most importantly, it successfully avoids the files, folders, and hyperlinks metaphors still dominant in HCI.

Errors on Google App Inventor

September 16th, 2009

As I learned the hard way after some troubleshooting, there are two important preparations you have to make before using App Inventor.

The first is that your computer must be running Java 1.6 (also called Java SE 6.0). On the Apple website, you can find this update under Java 1.6, Update 4 from July 2009.

Even after you’ve installed it, your computer may still be running an older version of Java. On a Mac, you’ll want to open Applications > Utilities > Java Preferences. Under both “Java Applet Plugin” and “Java Applications”, drag Java SE 6 to the top.

You should be all set, Java-wise.

The second basic requirement for running App Inventor is that you should be on Firefox 3 or greater.

“Mailto:” Link Encoder

September 6th, 2009

Ward off spam by encrypting your mailto links using this helpful encoder:

http://www.katpatuka.org/pub/doc/anti-spam.html

“helen@cafegirl.org”, for example, comes out to:
<a href="mailto:%68%65%6C%65%6E%40%63%61%66%65%67%69%72%6C%2E%6F%72%67">email me</a>

Spam that!

iPhone vs. Android: Camera Battle

September 6th, 2009

I finally received my developer’s Android phone today! And now, the first of many battles to take place in this arena… Camera Battle!

Taken by an Android:
Taken by an Android

Taken by an iPhone:
Taken by an iPhone


… and the Android wins!

Excitement for the Upcoming Semester!

September 4th, 2009

Over the summer, I experienced a sudden shift in academic focus. Since returning to campus for Mentor training and First-Year Orientation, I have been so excited about starting up with my classes — about getting in touch with my inner geek and steadfastly pursuing what I somehow knew all along was meant for me. This semester will have an very technical focus, with 3 classes in the CS department and one Studio Art class concentrated in media art and design.

I was also offered the TA position for our Computer Science department’s new introductory-level class, CS114, The Socio-Techno Web.

As more and more people use the technologies and services made available from Computer Science, online environments like Facebook, Second Life, MySpace, Wikipedia, blogs, and open source development communities, have been flourishing. It is becoming clear that problems existing in our real world transfer and get amplified in the virtual world created by the highly interconnected and ubiquitous computing. This course with start by studying the structure of the traditional Web and its recent successor, the Social Web, and will focus on issues of virtual identity, personal and group privacy, trust evaluation and propagation, online security, critical thinking, online propaganda, googlearchy, fraud and manipulation, restricted resources, class differences, self-perception, and decision-making.

Given my experience with social media, social networking, and mobile application programming, as well as my interest in history, progress, and the world today, I am very excited about what this course will offer.

My responsibility is largely to assist with the programming component of the course, much of which will take place on the Google Android phone. Wellesley is one of 12 universities participating in a pilot of App Inventor for the Android. In a few days, I’ll receive my own Android so I can start playing with it. I am very excited to be a part of this.