HUSH measures volume in a chosen space, and then displays that volume in three different ways: it tweets the average volume levels from @VolumeBot2013, displays the current volume levels in the chosen space, and displays historic volume trends online.
HUSH connects two different spaces: the chosen space, and wherever the user is. In this case, the Digital Futures Initiative lab was chosen as a test space. A student can check how loud the space is before travelling from home to work there.
The idea for HUSH sprang from a frustration with the often-noisy DFI lab space. About 35 students use the communal space, and it inevitably gets loud sometimes. We wanted a way to be able to see how loud the lab is before making the (sometimes long) commute to school.
When we began researching the project, it was difficult for us to find comparables; measuring volume in shared spaces seemed to be done in informal ways, such as through qualitative analysis and casual verbal reporting, unless there was a formal workplace study underway. The lack of examples on that side led us to use sound visualizers as touch points for the project. On Open Processing, we found circular sound visualizations (http://www.openprocessing.org/sketch/5989) which became points of inspiration for our analog clock. Projects that visualized other data sets, like text, also helped us reimagine the traditional clock face for our purposes.
We conducted informal interviews with classmates across DFI1 and DFI2, and discovered that noise levels in the space is a major issue. Many shared the frustration over commuting to the space to study, only to find on arrival that it was too loud for them to concentrate.
“Sometimes it gets really loud, but most of the time it’s quite tolerable,” said Humberto Aldaz, a first year DFI student.
The fluctuating noise levels seemed to cause problems.
“I find it frustrating when I come to the studio space and it’s loud,” said Ardavan Mirhosseini, another first year student.
And so, HUSH was born.
How it works
HUSH uses a microphone that is hooked up to a laptop. The laptop runs several sketches in Processing. The laptop is also connected to a projector.
There are three Processing sketches involved with HUSH:
- Twitter: the first sketch reads the volume levels. The average volume level of the room is tweeted out by @VolumeBot2013 every 10 minutes, unless there has been no change from the previous 10 minutes. .
Projection: the second sketch reads the volume levels and displays it on a clock interface. In the DFI lab, a projector is used to display this visualization on the wall. The colours of the clock’s minute and hour hands change as the volume level changes. .
- Data visualization: the third sketch reads the volume levels and gathers them in a text file. This file is then converted, through Processing, into an interactive data visualization which shows the volume trends for the lab over a 24 hour period, overwriting the levels for each day to show general trends. This is then put online. This visualization allows users to see when the lab is usually at its loudest or quietest. .
Hardware and Code
Links to github:
- Analog clock: https://github.com/km13oj/project_3/blob/master/final_analog_clock
- Data visualization: https://github.com/wrightlauraa/repo1/blob/master/HUSHdataviz
- Main sketch – twitter, volume measuring and data gathering: https://github.com/wrightlauraa/repo1/blob/master/HUSH-PART1
While the idea for this project is fairly simple, it was a technical challenge for a number of reasons.
1. Working with Twitter
We installed the Twitter4j library (http://twitter4j.org/en/) and figured out what code we needed to write to hook up our sketch with a Twitter account. However, Twitter only allows for 1,000 tweets a day. It is extremely easy to ‘overload’ Twitter (meaning exceed that number) with Processing sketches because they run very quickly. Once you send too many tweets in a row, or too many tweets that have the same text, Twitter will shut your account down for a few hours. This makes testing with Twitter frustrating. We eventually found a way to make our account only tweet every five minutes, and to also add a timestamp to every tweet so that there are no duplicates, which Twitter does not like.
2. The wires
We used a microphone to record the data. In order to string the microphone in a central location, we had to long wires. This was surprisingly difficult. We spent a long time working with TRS wires before realizing we needed TRRS wires, which work with microphones. These are surprisingly hard to come by, which was an extra added challenge.
3. Recording data
We had several options in order to gather our volume data. Originally, we wanted to get an XML feed from the Twitter account. This proved too difficult, so we chose to work with the Processing sketch’s volume recordings. After much searching online, and help from Nick, we managed to gather our volume data in a .txt file. This can then be extracted to use for visualizations.
4. Exporting to Android
Ideally, we wanted to export our Processing sketches as apps and then run them in Processing. This was not working, and we only later discovered that the Minim library (on which our volume measuring is heavily reliant upon) does not work with Android. So the tablet dream had to die.
A screen shot of our Processing code, which shows a funny error message we got when we accidentally added a data file to the same sketch twice.
Alternative applications for HUSH
The DFI lab was a test space for the HUSH project. It can apply to other shared spaces where noise levels can be a factor, such as cafes, libraries or offices. It can also be used in places which are meant to be loud, such as concert venues (is the band playing yet?) or bars (is it busy yet?). Moving forward, we hope to get the project working on a tablet and permanently install it in the DFI space.