Last week Andrew and I (finally!) collaborated for an hour long hack in Taeyoon's class in an effort to create a 'simple' piece of electronics that helps describe an aspect of computation. Here, seven leds illuminate the cardboard display controlled by eight cardboard and copper tape switches.
The past couple weeks I've been playing around with audio reactive spring systems. My idea was to create a particle system held together with springs that would help visualize wave patterns and reflections in different geometric spaces. The program I ended up with this weekend has a little over 20,000 spring connections, though it's more visually interesting than educational or revealing about acoustics - fun nonetheless. I'm attaching the application here since it was too slow to really capture well with video. Also, I think this is maybe the first time I've 'shipped' an app (not sure if this counts :) ).
More lighting prototypes. Moving forward!!
Building out a custom DMX system with the Studio Indefinit crew.
There are four weeks left at SFPC and so I'm jumping in on a few quick hardware projects. First up, I'm playing with the 'freelancer's timer' again. The idea is a simple desktop device to keep track of your time when juggling multiple projects. You can turn two timers on and off by sliding a magnet across the surface of a wooden box. In turn, new entries are made in a google spreadsheet updating your work status.
I'd love to have time over the next few weeks to refine this and place the hardware in a slightly more custom enclosure with a design on top that speaks to the act of switching between jobs, and responds to the magnet's possible positions.
Another hardware project I started this morning with Gugo - who had the fun idea to make a tactile braille interface. I've had a pile of solenoids kicking around for a while and so we're finally putting them to good use. Today we made a simple breakout for an arduino to control 6 solenoids. The next task is to write or find a library to convert braille into binary states for six digital pins. The goal in the end would be an interface to rest your hand - some type of stretched fabric - and feel the pulses of the solenoids as they played out ones and zeros from code which parsed letters out of words and sentences.
Over the past two weeks at SFPC, Zan Armstrong and I have been plugging away (in our spare time) at trying to visualize some of the initial data from the Public Radio's Kickstarter. It's been fun diving into javascript again (after my brief stint with the NYC convolution project this summer) and really fun learning about the quirks of d3. Thank you, Zan!
So far our efforts have been focused on:
Interesting fact:
Over the next few weeks the plan is to add a bit more info and functionality to the map and try and develop some interactive features to answer questions like..
Where is my dot?
What were the most popular stations overall?
Did people near me get the same radio station?
Who else got my radio station?
Who else got x type of station (NPR, sports, conservative talk, jazz, alternative, etc)?
Update: 12/8 NPR Affiliate Stations
Here's the same map showing backers who chose an NPR affiliate station in green, and non NPR affiliate in blue.
I'm continuing to play with lifting rhythms in light from videos and using them to trigger sounds. Yesterday, I got a major Open Frameworks tutorial from Jonas Jongejan who helped me implement his Biquad Filter in my code in Open Frameworks. The bandpass filter helps capture the fleeting moments when the raindrops poke through the algae covering the water. Fun!
We're doing an abridged version of Zach's 'algorithms for animation class' at SFPC, and the past two days have been diving into trigonometry. The challenge for the morning was to make a John Whitney inspired animation, exploiting the awesomeness of sin/cos/tan/arctan.
I've also been playing with Lissajou patterns on the oscilloscope from FM and AM synthesis in Max - amazed at how simple and beautiful they can be!
Prototype drawings for an upcoming permanent LED installation.
A quick share of some of the electronics work at SFPC. This week Taeyoon led the second circuits class building on his first week of logic gates & transistors. It's been really fun making simple transistor circuits and helping teach electronics to the rest of the gang.
Here's a half adder assembled from a quad Nand gate IC and two transistors.
Cool Stuff.... NAND is the basic building block from which all other logic gates can be derived.
XOR + AND = Half Adder !
I've been working on a Processing sketch to send pixel brightness information from a video to a Max/Msp sketch - doing a kind of reverse audio visualizer. Originally, I'd set out scanning pixel by pixel until Zach L. showed me how to use 4 ' for loops ' to move around the image, by superimposing a larger 2D array over a smaller 2D array.
I spent the morning working through it and now am in love with printing out code..
Weekly post reflecting on Allison Burtch's class at SFPC, Critical Theory of Technology
The main text for the first week of Critical Theory of Technology was Mindstorms, a book from 1980 by the MIT mathematician, educator and theorist, Seymour Papert. It was presented for our class in the context of Alan Kay's Dynabook and Steve Job's notion of the computer as a 'bicycle for the mind.'
In Mindstorms, Papert advances a framework and educational model in which computers are used as a creative educational platform for children. Papert, who himself associates his lifelong joy of mathematics with an early exposure to mechanical gears, sees the computer - and programming - as a tool and creative entry into the kind of abstract thinking associated with math. Mindstorms explores the notion of 'math phobia,' and in probing the roots of this fear, suggests a void of relatable experiences for students when learning math.
In an effort to fill this gap and provide a sensory and memorable experience, Papert created LOGO - a programming language which takes instructions from the students in order to move a small turtle along a computer screen and create images. These drawings and shapes in this sense serve as the output of solved equations, but also as a framework for students to dissect the intricacies of math. In LOGO, students can also relate to this turtle in the sense that they can physically walk and move the same path which is being programmed to the screen.
When forming this kind of relationship with the computer, a new set of challenges are posed for the students. With the simple example of drawing a circle, the students become both the student and the teacher - algorithms aren't taught in this sense, they're discovered and (although not entirely explored by Papert) the student is engaged in forming their own language for education in general. The computer in his LOGO language, when used in this way, transcends the kind of input/output that is expected of human computer interaction and uses simple programming as a jumping off point for learning.
While I got excited about Papert's pedagogy reading Mindstorms, I felt he skimmed the surface of this notion of learning how to learn, and failed to pursue this outside of mathematics. For example, What are the ways we might be able to teach the humanities in this kind of way? What are the ways to implement these theories without a computer?
Admittedly, I've not been as active as I've wanted to be on this blog - especially over the last two months - but a lot has been going on! The Public Radio went live on Kickstarter, I'm designing a 150 sq ft permanent lighting installation with my friends, Studio Indefinit, I finished up my time poking around in the world of residential acoustics consulting AND, decided that pursuing a career in architectural acoustics via my planned approach through RPI's program was not for me - at least not right now.
Through a few great suggestions from friends and being tangentially involved in the interaction design world recently, I landed on The School for Poetic Computation and this past week began classes. SFPC is led by an amazing group of artists, technologists and makers, but foremost is promoting itself as offering a type of residence/research/education space, where ideas can incubate around things like the pedagogy of computation and programming, and specifically this term looking at assistive technology.
We really only just began, but the approach so far has been exciting for me in unexpected ways, like an early rule established - no laptops out during class unless we're specifically working in code. Yes, I like it!
A handful of the exercises we've focused on in the first two days actually didn't involve a single keystroke. In The Human Fax Machine we were challenged to encode a set of drawing instructions to members of our group through a handful of unique sounds. Two members would tap and shake random objects in the hopes that the other two members of the team were sketching out a desired, simple shape. In essence, we've been breaking down the foundations of computation by exploring of the elements and approaches to teaching it. What are the basic elements of a language, it's syntax, it's rules and contradictions? In a similar exercise we were asked to come up with a game to teach binary numbers to kids. I came up with a kind of 'Binary Two-Step' dance.
Two Step: 8 people shoulder-to-shoulder. You can only step forward or backwards and only move to one of these alternating positions when the person to your right, takes a step back.
I've also been thinking a lot about my time in undergraduate studying music. While I'm absolutely thrilled to be at SFPC, I'm a little bit nervous about spending time thinking about pedagogy before (at least for me) developing a solid vocabulary and expressiveness with programming languages. At Bard - almost 8 years ago - I went from thinking I was going to study photography and science to becoming a music major, and cramming in technique, and ear training, and composition all in 4 years. What sounds like a lot of time is basically nothing to go from 0-100, i.e high school rock bands to jazz composition, improv and 20th century music.
It took me a long, long time to digest everything from Bard (music and otherwise) and to really feel comfortable about getting an education on education - what would become years of teaching myself how to learn new things.
I stopped playing drums this past fall. And that's huge for me given that it's defined me as a person for the last 15 years of my life. After my dad passed away a year ago I buried myself in circuits, The Public Radio project, and programming more seriously (i.e. less Arduino IDE). I'm completely hooked on these new things, but admittedly there's a kind of desire for instant gratification that anyone staring at a steep learning curve ahead maintains. I trust though that this oscillation between the micro and macro at SFPC will ultimately pay off, and any desire to learn how to make really pretty particle systems in D3 or processing, would be kind of a waste of time - at least right now.
Focus on concept. Continue to develop better tools to teach yourself. Carry on.
More soon.
I spent the weekend working on modeling some ideas for an interactive lighting sculpture and in the process, realized the upper limits of my computer with this 4,000+ led array.
I like how easy Sketchup is, though compared to Rhino (which I kind of started understanding) it seems like I'm drawing cartoons as opposed to realistic, neatly rendered models.
At some point soon I'll make the switch over to Rhino. For now though, I don't have the time to invest in the steeper learning curve.
Onward!
I was having fun this morning with the new acoustic mapping tool I made. It includes a custom Teensy 3.1 breakout board that holds four mic pre amps, and connects to a 144 segment led strip. The strip is separated in the code into four regions, and the microphones are physically placed at the center of each of these regions on the strip.
I'm still playing around with the display and calibration routine a bit, and I'm going back and forth on whether or not to tag each segment with a unique color, so you can distinguish between microphones more easily.
Here's a quick video of what it looks like in action. In the beginning of the clip, there's a single blue led animation that increments along the strip while the teensy calibrates. The teensy listens for the maximum and minimum ranges of SPL amplitude and then uses this information to set the ranges on the display. Once that's set, the rest of the lights come on.
And this is what is looks like when you take a picture!
This is listening to 180Hz
Here's another at 123Hz.
This is listening to 123Hz
Looking at the two pictures it's easy to see that 123Hz is more resonant along this one path in my living room. There are also less extreme phase cancellations at this frequency along this path than at 280Hz (i.e less dips in the volume as you move around).
Experimenting with 2d arrays to, save("texture.png")
About six weeks ago, I put together a board layout to accommodate a Teensy 3.1, and four mic pre channels with precision rectifying. It was a lot of fun laying out a through-hole board after spending all winter doing SMT on The Public Radio. It's also a beautiful thing placing an order on Osh Park and having it run $30 as opposed to the $300 with TPR. As far as assembly goes, well that's a different story :)
Eagle-ing
I made a few silly errors in calculating my gain setting resistors for the mic preamps (namely not factoring in microphone impedance) and with the tight layout, and pad sizes that were just too small it more or less meant building a second board.
There's still some fixing to do with quieting the noise coming off of the pixelstrip, but all in all I'm excited to start taking some new photographs with it, for the ongoing acoustic mapping project.
First build
This month I'm spending two days a week in a more formal setting learning about architectural acoustics. It's just for a brief period and is hopefully giving me a sense of what working in acoustics is all about. It's no surprise that like many people I know in the tech/music/electronics crossover world, I'm interested in the whole picture. Not simply wondering about the DAW, or the microphone, or the song for that matter that you might be recording, but also the room - what's on the walls, how is the shape of the space you're in becoming literally part of your instrument? Or, why does it seem sometimes like I can hear the music from the outdoor concert "better" when I'm further away? Or, why do those cheap baffles I helped a friend install years ago, not actually work at all, but we thought we heard a difference.
While designing recording studios, listening rooms and performance halls, or even taking into account the effects of psychoacoustics in these spaces, is certainly part of architectural acoustics, a lot of what goes on (especially in residential acoustics) seems to be more in the arena of noise abatement - controlling, restricting, and decoupling unwanted noises. And though this might seem somewhat less interesting (it's possible it is, like I said I'm totally new to this) there are certainly many interesting factors that go into the design process in residential acoustics. In addition to the architectural considerations like aesthetics, design and construction feasibility, looking at use cases for a space and weighing cost vs. efficacy, architectural acousticians look at things like sound transmission classes, vibration analysis, air flow, reflections and absorptions and resonances to name a few, and figure out how all of these things affect and become effected by the architectural considerations.
Like most engineering this involves lots of modeling - physical, numerical, even aural, but mostly just numerical, which means spreadsheets. Lots of spreadsheets. MATLAB is big in this world (and I'm excited to start learning it), but when you're down and dirty there's always google docs!
One of the more important factors in understanding a room's acoustics is looking at it's reverberant qualities: how sounds linger after whatever's making the sound, stops. And which frequencies in particular linger, and for how long. This boils down into what is known as RT-60 - how long it takes for the reflections of the direct sound to drop by 60db. There are papers on papers about which algorithms best model this acoustic principal and in what situations the Sabine, Eyring, or Fitzroy equations are better suited. All of these equations look at the volume and surface areas in a room and what the absorptive properties are of these surfaces at a range of frequencies (125Hz-4KHz for Sabine). So far I've only managed to eek out a sheet for the RT-60 of the Sabine equation in my free time, but feel free to take a peek at it and play around with it.
Hopefully more reflections, comments on my month to come. I'm still hoping to roll the NYC impulse responses from earlier this month into some Web Audio API concoction and loop all of these things together, that's the idea, right?
Soon :)
Last night, Daniel and I made a few stops around town recording impulse responses. We were pretty down and dirty about it: field recorder, stereo mic, and balloons. One of us would watch levels and the other would move around and try and not look too suspicious while they knifed balloons.
First stop, this amazing tunnel near my house in Prospect Park where there's about a 5-6 second natural reverb. It's super responsive on the low end and has this weird delay.
Next up, recording random objects at my desk while we ate dinner: 4 foot packing tube, a frame drum and this bag of bones that Daniel wanted to record (yes).
Finally, we hit the Clinton Washington G train concourse - a recommendation from G. Wilson - which also proved to be interesting: long decay and a much more even frequency response than the tunnel.
All in all a good night, a great learning experience, and beginning of a solid ongoing summer project.
Here's a zipped folder of the IRs recorded. Enjoy!
Okay, I'll let you in on a secret... The Public Radio is a mechanically tuned device. Sssshhhhhhhh.
For a number of reasons, cost and ease of build/debugging being most important, the Public Radio went from a fully digital device with a small amount of firmware, to a digital IC that requires mechanical (read using a screw driver) tuning. It's not a huge pain, but there's an important catch in producing this device, which the main selling point remember, is that it's pre-tuned: you have to be able to always measure it's tuning frequency. Typically this is easy, you just tune it and verify by listening that you're on the right station. However, it get's a little trickier when the station doesn't exist locally, because you have no reference as to which station your listening, or not listening, to.
There are FM transmitters, like the kind we used to use in the early iPod days that broadcast on an open frequency band over the car's radio and these are helpful to have though they can be problematic in a major city like NYC where there are a lot of FM stations and not a lot of space on the air. So, what to do when you need to tune your Public Radio and there's no UI on the device, or simply a reference station to listen to.
Unfortunately, the FM IC we're using doesn't offer up any tuning information in the form of a station id that it can send to a microcontroller, to confirm the station it thinks it's tuned to. So this afternoon, in anticipation for our REV 3 boards showing up later this week, I put together a quick tuning calibration sketch with an Arduino - mapping the radio's varying voltages on its tune pins, to FM stations. It seems pretty accurate, and precise to within 20Khz, which is a good start.
We're open source on github. So, here's this too.
/*
A tuning routine for the Public Radio to test for station freqs, by Zach Dunham.
Averaging function from Tom Igoe at http://arduino.cc/en/Tutorial/Smoothing
www.thepublicrad.io
***steps***
connect A0 to tuning pot, center pin 2
connect grounds
connect radio pwr to 3.3V
run sketch, open serial monitor and tune until the appropriate station
appears in the serial monitor
*/
const int numReadings = 5; // number of readings, indices for the averaging array
float readings[numReadings]; // the readings from the analog input
int index = 0; // the index of the current reading
float total = 0; // the running total
float average = 0; // the average
int PotPin2 = A0; //input from the radio, wiper of the tune pot
float tune = 0.00; //variable for station id
void setup() {
for (int thisReading = 0; thisReading < numReadings; thisReading++)
readings[thisReading] = 0;
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}
// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
tune = analogRead(PotPin2); //read the pot value
tune = constrain(tune, 0.0, 212.0); //constrain it's range
tune = mapfloat(tune, 0.0, 212.0, 86.33, 108.43); //map the potpin2 readings into the FM range with floats
tune = averagestation(tune); //smooth the readings with the average function
Serial.println(tune); // print the station
delay(100);
}
//maps from floating point number to floating point number
float mapfloat(float x, float in_min, float in_max, float out_min, float out_max)
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
//taken from the great, Tom Igoe!
//this averages the readings to help smooth data in the serial monitor
float averagestation(float tune){
// subtract the last reading:
total= total - readings[index];
// read from the sensor:
readings[index] = tune;
// add the reading to the total:
total= total + readings[index];
// advance to the next position in the array:
index = index + 1;
// if we're at the end of the array...
if (index >= numReadings)
// ...wrap around to the beginning:
index = 0;
// calculate the average:
average = total / numReadings;
// send it to the computer as ASCII digits
return (average);
delay(1); // delay in between reads for stability
}
