Monday, October 29, 2007

Loom: Update 2

This week was all about max/msp. I got myself up to reasonable speed with max and have built a basic circuit that takes in readings from sensors, midi-formats them, and sends them out via midi to max. Once they get to max, i take the values in off channels 0 - 15 and send them through various filters. I was happy to get some noise out of my circuits this week.

Once I was able to get the readings from arduino to max, I focused on manipulating the midi data so as to get the kinds of textures/sounds that I'm looking to sculpt out of the data. I'm still working on that now.

Next week, I plan to continue working on the sound, and also doing the following:

- build the loom with sensors tentatively placed. I will be building a warp-weighted vertical loom.
- build the loom
- complete my max patches
- get the materials i'm going to actually be weaving with

This week, I didn't have any major hangups. Now that I actually have data coming in and pushing sound out of the patches i'm using, I am feeling good about getting the max/msp stuff done. I expect next week will be full of issues, since I will putting together a kind of prototype for two wednesdays from now.

Tuesday, October 23, 2007

Kick Me: Finished!

We got our xbee/fsr controlled kick game for Mesh Networking working today!

The icons come out on a broadcasted beat, which our xbee picks up, and then are 'kicked' to one of four environments, depending on which force sensor pad the player stomps on.

So okay, we aren't actually 'kicking' anymore; it's now 'Stomp Me'. Or alternately Kick (Stomp) - A - Mole (Icon).

Anyways, here's a screen cap:

And the Processing source code:


Monday, October 22, 2007

Loom: Update 1

So I've broken the task of building this loom down into a few categories of attack:

Material (yarn)
Loom (building + augmentation of...)
Hardware (sensors, circuits)
Software (music mapping and programming)

This week I took on a few of the tasks under the Software header. I mapped out how I would use the loom for actual sound production and worked on some test patches in max/msp.

I also decided on what kinds of sounds I am going to produce. I'm going with deep synthy sounds, contrasted with fuzzy, crackly, scratchy sounds. Although it's nothing I'm completely intentionally doing, I'm well aware that many of the sounds I'm going with reference wool, hair, and other organic fibers.

As far as mapping goes, I'm tentatively going with this plan: I'd like the warp (vertical strands) to alter the sounds I've already laid on the canvas (which will be controlled by the weft, or the horizontal strands). The shuttle will either operate as a beat keeper, or it will act as some kind of interrupt as it slides across the warp. Actually, it will become percussive by default, as it affects the warp threads. I'd also like to have panning mapped literally going from left to right across the loom.

This next week, I want to continue working on my patches. The max/msp part feels like the largest challenge so far, since it is the part I'm the least familiar with. I will also try to build out a 'test loom', which will just be warp and weft threads hand-laid out so I can try to mock up what I ultimately want to do with the final loom.

The biggest challenge is working with max/msp. I'm fairly new to this program, and it can seem like a beast, and therefore hard to get started with. I'm overwhelmed by what I can potentially do, and by deciding what I exactly need to do. For now, I'm just accepting midi-data in from a test circuit, and producing sounds with that data.

Tuesday, October 16, 2007

xbee game (as yet unnamed)

My group and I decided to make a little foot-eye coordination game, coordinated to a xbee broadcasted beat. The parts to our project are as such:

- a physical interface consisting of a kick pad with FSRs in them, for recording which pad was kicked and how hard.
- the hardware involving an xbee and arduino, for capturing the broadcast beats and fsr readings
- the software, processing, for displaying our environment, which will be updated per the data sent over from our arduino.

Basically, our processing environment consists of four areas: a forest, a city, a desert, and a river. The screen will be divided into four equal parts for each eco-system. Moving along the bottom of the screen (coordinated to every 2nd broadcast beat) will be a conveyor belt, carrying with it three different kinds of icons: an egg, a baby, or a seed:

These icons will drop onto the conveyor belt in coordination with the broadcasted beat. Depending on which FSR pad you kick, you can send each of these icons out into one of the four environments. How hard you kick the pad will determine how far out 'into' the screen the icon travels. Finally, depending on which icon you kicked and which environment it landed in, the egg/seed/baby will grow into a specific animal/plant/character. For example, if you kick the baby into the city/desert/forest/river, you will get:

So far, we have designed our icons and have the core architecture of the processing program in place. We also have been able to pick up the broadcasted beat and are working on putting together a kick pad.

We have divided up the labor as such:

Shin-yi + Sarah: Graphics/Animation/Processing programming
Daniel + Shilya: Kick pads and hardware programming

Sunday, October 07, 2007


My partner and I each built a device with an arduino and xbee radios that can wirelessly play rock/paper/scissors with the other. We got it 100% working now, but until today, there were two strange bugs causing me (the programmer) a major headache.


The Problems :(
The first bug was how the win/loss/tie was being tallied; only one of us ever got the results back from our match (had one of our win/loss/tie LEDs switch on), and it was always opposite of what it should have been. For example, if I rolled first, and chose rock, and then she rolled and chose scissors, her 'win' light would turn on (even though she should have lost), and I would have no outcome LED turn on at all.

The second bug (which turned out to be the reason for why one of us wouldn't have an outcome LED light up) was causing the character 'A' to be sent out the serial port, after each round played. Whenever we started a new round, the program would run through the whole switch statement, and then for one us, begin to start a new round up again, without having triggered the program to do so. This also caused one of us to not have an outcome LED turn on, because I programmed the game to turn off all LEDs on the board (to reset the board, essentially) at the start of each new round.

The Answers! :)
The first bug was due to my dyslexic coding. After I make a choice and send it to my opponent, and receive my opponent's choice, i run the data through a function that compares the two choices and switches on the appropriate outcome LED (win/tie/loss). Well, the issue turned out to be that I was comparing the opponent's choice as though it was *mine* and my choice as though it was my *opponent's*. Thus, we were getting the results backwards and the wrong outcomes. Once I fixed this, we were getting the right outcome LEDs to turn on.

The second bug was due to us not having put any delays in our main switch statement. After adding a 1 second delay before setting the game back into 'gameOver' mode (in the last case statement), we finally weren't getting any extra characters sent out the serial port (which was screwing up the whole game flow). Basically, I have a function in the main loop that is constantly checking the status of the play button. If the play button is high (is depressed) *and* the game's current status is 'gameOver', it sets the game's status to 'start', sends an 'A' out the serial port (to start the handshake with the other device), and randomly picks a number corresponding to rock/paper/scissors while waiting for the other guy to start their game too. Essentially, it starts a new round of rock/paper/scissors. Well, what was happening was that the program was playing and processing one round faster than we could finish pushing the button. Which is pretty damn fast. So adding a 1 second delay in there gave our lowly human hands enough time to stop pushing the button before the game was over.

Other than those issues, we only had one other pitfall, which I'm sure plagues 90% of people working with xbees. At least when you first start working with them, and have been up coding for 12 hours straight: We assigned the same id's to each radio. We figured that problem out early on, but it's still worth mentioning. Make sure your radios actually have someone else to talk to. Talking to yourself doesn't get you too far in the world of wireless communication.

Wednesday, October 03, 2007

Weaving Sound

For NIME this year, I've decided to create a loom which triggers samples and other various sounds, via max/msp. The exact details are yet to be worked out, as this is the simply the first step taken out of many. After much rumination on how I could combine both fiber arts and sound however, I'm happy to of finally found a direction which feels 'right'.

Looms, of course, are the tools used in weaving. They range from simple, hand-held devices, to lap-sized instruments, to giant, room-filling machines. Typically, there is a warp (vertical strands) and a weft (horizontal strands), that are brought together, transforming wools (or other raw materials) into fabric.

Historically, weaving is an ancient, cross-cultural, (traditionally) organic craft, typically assigned to women and yielding items of both expressive and utilitarian purpose.

I find something attractive in pairing both a usually soft, natural, feminine process with an assumed masculine, electronic process, comprised of components not normally thought of as 'soft' (i.e., wires, sensors, chips).

Juxtaposition aside, I feel there is a connection between weaving and musical composition. Actually, whether or not it actually ends up 'musical' is secondary. Transducing the motion of weaving into sound waves feels natural, almost literal – weaving together notes, samples, and aural textures into compositions of patterns and discrete designs.

Here are some of the different kinds of looms I'm looking at:

Frame Loom

Peg Loom

Heddle Loom

Knit Looms

Monday, October 01, 2007


Happiness and creative flow... While the first does not beget the second, I think it's safe to say that the reverse is definitely true. Being 'in the moment' of intense creativity and therefore productivity is one of the most fulfilling sensations I'm able to feel. It's within these moments that all the dots seem to connect themselves, with little forced effort from my end.

In anycase, I just read a paper detailing the findings of a study of over 800 adolescents and their levels of happiness throughout the day over a one week period. There is an attempt to correlate these moments of happiness to possible moments of activities which might induce such a 'flow'.

The results were not incredibly surprising from the researchers' point of view (the kids were happier hanging out with friends vs studying, happier on a saturday than on monday), except for one point which was taken as counterintuitive: kids from lower socio-economic classes were found to feel better about themselves and feel happier overall, than kids from upper-middle and upper-class segments of society.

Honestly, that doesn't surprise me too much. I feel like higher echelons of society put a lot more pressure on kids to perform to a certain level, while laying restrictions on freedom of choice, specifically pertaining to education, careers and friends. Not only that, but we all know that money is the root of all evil; materialism can be a real drag.

The part of the studying that was most interesting to me was the finding that 'Happiness will increase to the extent that individuals are provided with the means to learn skills that can be deployed to meet reasonable challenges...'. So basically, people like to feel like they are learning, growing, and accomplishing something.

That's why I always go back to school whenever I start to feel a little depressed.

Quick pcomp sketch

So I was asked to make a little device that addresses a problem on the ITP floor. Well, 'problem' is a very subjective term, and it turned out that my 'problem' with the ITP floor wasn't as much of one for anyone else, thereby pointing out that I might be a little OCD. oh well.

The problem I chose to tackle was the one of the pcomp lab's tool box drawers not always being fully shut (photo coming soon). It's not a *huge* problem to me, but an issue nonetheless, however petty it might be. And anyways, it's the one I chose to solve, so here you go:

Originally uploaded by 0x000000

This device is just a photocell + a doorbell buzzer. When the arduino reads a value off the photocell of less than 200 for more than 10 seconds (ideally, this would be set to a couple minutes, so people have time to open the drawer and shuffle about for their item), a very loud, obnoxious, annoying buzz goes off, until the drawer is fully shut again.

arduino src