Tuesday, April 14, 2009

Before working on this vest, I have never worked on a piece of clothing that incorporates technology. Sewing a well fitted vest is already enough of a conceptual exercise for me, so working with all the circuitry needed for the vest presented quite the challenge. To tell the truth, I was a bit intimidated when I saw all the wires, boards, and numerous parts that made up the functional parts of this project. However, once I started planning the design of the vest, I was more excited than anything else.

The placement of parts was not as hard as I thought it would be, especially since we went from twenty individual vibrating pads to twelve coupled vibrating pads. I designed the vest based on one of my own patterns. I added additional inside pockets, eyelets for the wires to pass through the lining, and adjustable bands around the back. I was able to complete the outer vest and lining separately before I was handed all the tech parts. After most of the wires had been soldered to the boards, I was able to start sewing the parts down to the lining fabric. The lilypad, lipower, usb connection board, and all twelve vibe boards were sewn on by hand.

Constructing the strip carrying the vibe boards was the first priority. I decided to use an interfaced cotton for the outer shell and a headliner foam for the inside for cushiony support. I attached velcro to the back vest liner so that the strip could be easily removed. The lilypad was placed on the back below the left shoulder so that the wires would remain relatively short between the lilypad and the vibe boards. The battery and lipower fit well in one of the front pockets with wires running from the lipower out one of the eyelets in the pocket liner, around the waist of the jacket, and up to the lilypad.

Once everything was sewn down, I completed the vest like I would a normal piece of clothing. The sewing was a little more difficult since I had to be extra careful in order to avoid machine sewing or ironing wires and parts. When the project started to resemble the likes of a vest, only then did I see the light at the end of the tunnel. I am grateful that I was able to work with such a talented team of engineers on this garment. For me, one of the hardest challenges of the vest was keeping the design from being taken over by the technology. Now that the vest is near complete, I think my design sensibility prevailed while most of the parts were kept hidden. Although this competition was geared toward the deaf community, I think anyone could enjoy wearing this one-of-a-kind garment


Sunday, April 12, 2009

Team Thumping Threads

I mentioned in an earlier post that I couldn’t have asked for a better team, those words could not be more true. I’m constantly amazed by the effort put forth by everyone. By the time all is said and done we’ll have put in a number of sleepless nights, and we’ll probably pull out quite a bit of hair. If we’ve learned anything from this project, it’s that the simplest things rarely turn out to be simple at all. We’ve hit a number of monumental decision points. Most of these moments were brought about by completely unexpected setbacks. It’s during these times that I’m grateful for profound level of determination and commitment from the team. I consider myself to be both persistent and patient when it comes to problem solving, but there have been times when I’ve called “time of death” on a certain line of research only to be met with “we’ve come this far, we’re not giving up now…”

“We’ve got this, no worries…”

“We can figure this problem out...”

The amount of motivation on this team is beyond belief. I already consider this project to be an unparalleled success. Each team member has brought a unique skill set (and energy) to the table, and building a common language has been a rewarding learning experience. If there’s any chance that this ambitious design idea could be successfully implemented, this is the team that could pull it off.


Thursday, April 9, 2009

Happy Mistakes

Getting the tech needs for this project was no easy task. Anyone who has worked on technical projects knows that if you expect something to work, it will not. Gotta love Murphys Law. The tech team encountered this on multiple levels throughout the project. One example of this was getting 2 LilyPads to talk to each other. This was necessary in order to meet our project specifications of using 12 motors. After setting up the LilyPads correctly, we could not get communication to last longer than 20 seconds. We started checking forums to see where we might have gone wrong and it turns out that this is a common issue and the problem is in the way the software implements the process. As a result of this shortcoming, we stumbled into a happy mistake. Instead of using 12 discrete frequency bands, we could use 12 motors on 6 frequency bands to create a more powerful sensation.

Most people who have worked on technical projects also know that you often stumble across happy mistakes. Team Thumping Threads embraces happy mistakes.


the tech team: rishi and matt

Wednesday, April 1, 2009

The Vibrotactile Sequencer

I've produced music with electronic tools for over ten years, and I've more recently gotten into building my own interfaces. I thought about the device we’re creating, and I realized it has the potential to completely change the way we connect with the music we make. While advances in technology have allowed for increasingly precise levels of control, ease of use has always been a top priority for software engineers. This becomes especially apparent in applications that generally call for a high level of creative freedom.

It was suggested during the midterm review that we experiment with sending discrete sound data to each individual motor. A hypothetical situation might involve using the amplitude of the kick drum waveform to control the lowest motor, low tom for the next highest, mid tom for the next, high tom for the next… and so on up the back with all the individual drum sounds.

I originally hadn’t given this much thought because our concept naturally spaces the drum sounds along the back. The kick drum has the most low frequency content and thus it will naturally be sent to the lowest of the vibrating motors. Over the years I’ve found that automated processes usually win out over brute force code that requires everything to be written out by hand. Why would the user want to worry about routing each individual drum sound when the filter bank could approximate this automatically?

Then I started tossing around the idea of building a sequencer that would be capable of building vibration patterns. Each motor could be referenced directly, and complex rhythmic material could be created between the six discrete signals (running out to 12 motors). The more I began to think about the additional level of control offered by this approach, the more I realized how powerful it could be.

While an array of filters is ideal for providing feedback about the overall frequency spectrum, it’s susceptible to a large amount of crosstalk between filters. A snare drum might potentially make its way into four of the six channels by virtue of its complex frequency spectrum. One tom sound may be only slightly distinguishable from another, and a polyrhythm between the two could quickly become confused with all the overlapping frequency content. In order to even begin representing a complex signal we’d a minimum of 128 or so discrete frequency bands, as opposed to our 6. When working with a small number of sound samples, the one-drum-per-channel route is the way to go.

When I sat down to build the sequencer in MAX/MSP, I threw on my headphones and loaded up my favorite playlist. I got to the point where I was ready to load in audio files and just before I was about to turn off my music I stopped myself. I realized that if I were looking to truly engage my senses while interacting with the sound, I should be able to see the auditory information in a number of heads up displays. I added an oscilloscope and spectrograph to each track of the sequencer, and a large scrolling spectrograph to display the main mix. I loaded sounds into the sequencer and started crafting a drum rhythm, all while listening to some ambient electronic music. I asked myself, “Do I feel connected with the rhythms I’m crafting?” When the answer wasn’t a resounding yes I’d tweak the settings of the displays; adding information at times, modifying the type of information at others. This sort of refining spurned me to add a few subtle features that make a big difference, such as a master tempo indicator light, and a scrolling time indicator.

The sequencer worked, but the overall design scheme was reminiscent of candy canes at Christmas time. Don’t get me wrong, there’s nothing wrong with candycanes or Christmas time… they’re just not right for this interface. I sat down with Chris and we gave the interface a complete makeover, reworking the whole design around the user experience. We’re going with an approach similar to that of apples Garage Band software… the user should be able to sit down and produce a piece of music with relatively little knowledge of music production software, and furthermore this whole process should be fun. To this end, we’ve been extremely successful.


Sunday, January 25, 2009


Synchronizing our schedules as a group was one of the biggest inhibitors to productive and creative collaboration, as it was difficult to coordinate more than one formal meeting per week.  The solution was Google Documents.

Google Documents has been an incredible tool that has allowed the team to quickly and easily share ideas online.  Through easily accessible and editable online documents, every team member can stay up to date with the most recent revision of a document.  It also allows us to view all changes made to documents, which makes it easy to give opinions on any slight changes the document may have gone through.

 After our initial discussion of our idea, a spreadsheet with objectives and due dates was created and turned into a Gantt Chart.  This helps the team stay on top of what needs to be completed for the next meeting by giving a nice graphical representation of the timeline and status of each objective.

Google Docs also came in handy when it came time to put together a part list for our dream prototype.  We were able to itemize an entire list, complete with prices and links to each product.  The links were a helpful resource that saved time when the team needed to look up a quick spec on a component.  This spreadsheet also contained fields for price and quantity, which were soon computed to a new cell containing our total price ($1000).  This provided a shocking reality check; our current budget is far less than $1000.  We are working on ways to make this project more affordable and actively seeking additional funding to retain our initial vision for our prototype.

This project is becoming larger and more thought provoking than any of us could have ever anticipated.  After we had come up with the premise for our idea, it seemed as if it would be simple to execute with most of the work going into the coding.  We did not realize how many small problems would come up.  Coming to the realization that a jacket is too heavy to wear during the summer months and not close enough to provide direct contact with the spine forced us to think of a suitable replacement.  The vest seems like a good replacement, but is made out of less material thus losing valuable surface area to attach components.  The idea of using zippers to allow the electronics to be easily removed was vetoed due to the fact that zippers are not comfortable when they are rubbing up against your spine.  This forced us to look into electronics that can survive being washed. This experience has really changed how I problem solve.  I have learned that part lists, spreadsheets, and flowcharts can all expose fundamental flaws in an idea that seems to be reasonable.

Monday, January 12, 2009

Technical Considerations

In working on the digital signal processing, we have a number of interesting challenges. It is not an easy task to correctly interpret a time based signal (the microphone) in terms of both its frequency and amplitude over time, and properly distribute a meaningful signal to an array of vibrating motors so that the wearer can experience something directly related to hearing music. Some of the important questions involved are:

* What range of input signals are we trying to represent? Music? Speech? Ambient sounds?
* What configuration (placement and frequency distribution) of motors is most meaningful, in terms of how the wearer interprets the information?
* What is the most efficient and effective way to analyze the input signal? Is an FFT necessary for our purpose, or would filtering be simpler?

All of the answers are currently under research by the team, through books, the internet, testing, and experiments. The second question on the list is an especially intriguing one, since there is not a great deal of published research and data on how human skin interprets periodic signals - we have to test the motors out on our own skin in a scientific way to figure out how best to drive and arrange them! These challenges are very exciting, as they let us take the theory taught in class, and apply it directly to a real world problem; this makes the work seem that much more meaningful and rewarding, and is an excellent motivation for collaborative work!


Monday, December 22, 2008

Garment Design

Constructing a garment that contains a sizable amount of hardware, is able to transmit detectable vibration patterns, is comfortable, safe, and easy to wear is not a simple task. An extraordinary amount of preparation was and is still needed to make this happen. After much discussion, the team decided that a vest would best suit the purpose of our team’s goals. We wanted a something that would fit close to the body, especially along the back of the spine, so that the vibrating pads would gently press against the skin of the wearer. We also needed something sturdy enough to hold the lily pads, batteries, wires, etc. We are able to incorporate a lining within the vest which allows us to hide most of the wiring and lily pads. Since the lily pads and wires are washable, they are able to remain in the vest lining at all times. However, the microphone, preamp, batteries, and vibrating pads are non-washable, and need to be mounted in such a way as to enable easy removal.

We still have a lot of experimentation ahead of us in terms of placement issues. Wiring, relative proximity of each item, and comfort on the body are all areas of concern. There was some early discussion about how to make the garment one size fits all. However, this issue has become less and less a priority as the hardware placement became more complex. We are still considering making the size of the garment somewhat adjustable with added straps on the back of the vest. These will let the wearer tighten the back of the vest so that the strip of vibrating pads will always touch the back of the spine. In terms of fabric, we were thinking along the lines of lightweight cotton twill for the front and sturdy cotton knit for the back of the vest, so that it can stretch smoothly across the back. Again, these are still preliminary ideas, and there is a lot of testing ahead of us, so we expect things to change.

We feel confident that we will be able to pull off a vest that is able to translate sound into comprehensive and discernable vibrations, while making whoever is wearing the vest look stylishly modern, of course. I myself have never incorporated this much technology into anything I’ve made in the past, so I am all the more excited to work with a team to face the challenge. If all goes according to schedule, this will be one of the coolest design projects I have ever participated in.