Finals Week: Project 2 Ending and Cultural Events.

Almost End of Project 2

Well, it’s nearing the end of the road. With less than 24 hours to go til our projects need be handed in, in as complete as form as possible, I present my last blog post on this process.
As of last Thursday, I was anticipating a long weekend of studying. Some major projects and finals were to occupy my time and I was to get a solid chunk of work out of the way…. Unfortunately, I forgot about a major event to which my parents contacted me on Thursday night to warn me about– I was to have a throat-scope procedure done Friday afternoon. Without realizing it, I had lost a solid day and a half of work due to the fact that I forgot to put an appointment on my calendar, justly raising my stress level. Therefore, Thursday evening I put aside my plans to work on the project. I made some progress. Some. A relative term.

Before this, however, I got some interesting work done earlier that week. We decided to see if our Arduino Pro Mini’s would be an acceptable alternative to just a working concept project instead of the inconsistent Spark Core. After soldering in headers, I had believed it would work well. However, after several tests, I reached the conclusion that something had gone wrong in the soldering process. Of course it would! After consulting with others, I tried wiring some headers together. What I had not realized is that the two other parts of the board had the same connections in order to make things work. Connections like ground and power, the TXO and the RXI, the CTS and the DTR. So, simply wiring them together, at a first glance, appeared to be a solid workaround.


After working the Wednesday before on soldering and making sure my connections working on the replacement Arduino, I came home Thursday night to discover that yes, my sound sensor was recognizing the power. However, the output was a consistent value of 250 to 260, and would reflect zero change to actual sound input.  Screen Shot 2014-11-12 at 6.51.09 PM
There was power getting through, but it just wasn’t sending the right signals to get the damn thing to  work. Could one of the ends of the driver side be messed up? Or one of the sides on the actual Arduino? What about the pins to connect to the sound sensor? So many possibilities. That is how my Thursday evening turned into a night of messing around with wires for hours to figure out what exactly was going on.
First, I tried messing the wires with how they connected. According to some information I found online, some of the connections could be messed up and needed to be connected in a certain order. So I tried that.
Suffice to say, that didn’t solve the problem. Next step was to try the same order again and see if I had just not pushed some wiring in all the way. Power was sent to the board, but still, no progress.

So, next was to figure out some work around. I was convinced that the FTDI driver portion was the part that wasn’t working properly. So, I dug around in my magic kit of old parts from my Wearables class and found another driver port. Suitably in a nice purple color. I wired that sucker up to the Arduino and gave it a whirl. It looked neat at the very least, and it was a creative workaround.

Ahh, so as you can sorta see in the picture, the light on the sound sensor lit up. It was receiving sound and broadcasting a signal. However, it wasn’t the signal I had been hoping for.

Screen Shot 2014-11-12 at 8.02.32 PM


Yep, definitely static values. So that was unsuccessful. At this time, I reached the conclusion that the FTDI driver side was working just fine, on both the red and purple drivers. So, what was the next option? There were other pins around the board that could work to supply power to the Arduino. Why not try those and see if those would provide the necessary power to the board and sound sensor? Well, I gave it a shot. It was a much more tangly-mess than I had anticipated, but I got it hooked up… and…

No go. Still didn’t provide the necessary signal to allow the sensor to print variable values of sound sensor. So, the conclusion I reached was that I solidly messed up with the Arduino Pro Mini. Well that sucks.
So, what are my other options? If the board that was supposed to be a workaround for the board that doesn’t work, doesn’t work, what else do I have the time to figure out how to use? I decided to fall back and try everything I could to make this project at least a proof of concept. Lets go with the SparkCore.

Actual End of Project 2.

So, how did I spend my last weekend working on the project with the SparkCore?
First things first, I tried to create some code to measure my results, whether that be an actual publishable tweet, or simply a println. To do that, I had to set up a timer for the system to count up until it hits a specific allotted time. After a minute of hearing sounds, the sketch would print the total number of sounds heard, and then reset back to 0.

Screen Shot 2014-11-17 at 11.28.22 PM Screen Shot 2014-11-17 at 11.22.10 PM
t the time of publication, these were two events I measured while typing this very blog post. Well that’s some proof that my code works, I think?

This is the code that I used for a proof of concept:

// Create a variable that will store the sound value

double sound = 0.0;
#include "math.h";

float n;
//int counter;
int j;

int savedTime;
int totalTime = 60000;

void setup()
// Register a Spark variable here
Spark.variable("sound", &sound, DOUBLE);

// Connect the sound sensor to A7 and configure it
// to be an input
pinMode(A7, INPUT);
savedTime = millis();
j = 1;


void loop()
// Calculate how much time has passed
int passedTime = millis() - savedTime;
// Has five seconds passed?
if (passedTime > totalTime) {
Serial.println( " Total Tallied Sounds Heard: " );
savedTime = millis(); // Save the current time to restart the timer!
int reading = 0;
double voltage = 0.0;

// Keep reading the sensor value so when we make an API
// call to read its value, we have the latest one
reading = analogRead(A7);

// The returned value from the Core is going to be in the range from 0 to 4095
// Calculate the voltage from the sensor reading
voltage = (reading * 3.3) / 4095;

// Calculate the sound and update our static variable
sound = (20 * (log(15.00 / voltage) ) );

if (reading = 100 && reading < 150)

if (reading = 100)

if (reading = 150)

if (reading = 300)

if (reading = 450)

if (reading = 600)

if (reading = 750)

if (reading > 900 )

Serial.println (reading);
if (reading >150 && reading totalTime) {
Serial.println( " Total " );
savedTime = millis(); // Save the current time to restart the timer!
// j = 0;
n = 0;

As a whole, I tried to do my best to make it an Internet of Things program. But problems kept arising. The biggest being Temboo. I wanted my project, at the very least, as a proof of concept to tally up the total number of sounds, and publish a tweet, with the total number of sounds heard. This hasn’t worked. In fact, for whatever reason, Temboo won’t work within the SparkCore sketches, despite importing the data. When verified I get a bunch of terrifying nonsense. nonsense

Well this seems to be problematic. From my basic understanding, I believe this means that my Temboo code for printing a Tweet on Twitter doesn’t work or isn’t compatible with either Spark or the Arduino kit. So, I started messing around.
I tried using the same Temboo code and libraries found within Spark to see if any of their examples could work. I entered my username, my key, the app name, everything required. Still, nothing would work, except for my simple dummy sketch. Which I’m going to roll with.

At the end of the day, all these tech failures have left me feeling quite discouraged. I couldn’t get the damn project anywhere close near completion, or even proof of concept. As a senior preparing to go into the real world,  it is incredibly disheartening to become so overwhelmed by code that you don’t know what to do.  It’s frustrating, but growth comes out of failure, right? Like that phoenix rises from the ashes in that one Harry Potter film, it’s possible, right?

Final Thoughts and some wrap up.
The intention of the project was to analyze sound based on keyboard presses. Setting up a timer for a minute and measuring the amount of key presses in that minute would create a total number of keypresses. That number then, would be sent to a blog post or a Twitter feed, and publish the results. However, the total number of characters would be separated into random words of random length–all whose value would tally up to the total number of keypresses originally calculated.

proofThat was the intention of what it would look like and the process of it.

Instead, the end result was a sketch that read each keypress and added them up. Then, that tally would simply be printed in a serial monitor associated with that sketch. It was a final effort in making things come together, and while it didn’t in a brilliant way, it was made possible by the impossible object, the Spark Core. The code ended up working, albeit not in my intentional manner, but it worked. It is what it is. At the very least, I’m damn proud of getting something to work, even when it all went oh so horribly wrong.
Thanks for reading along.


Cultural Events

Event 1: VTOL

My first cultural event I went to was one hosted by our very own program, hosting digital artist VTOL. From the time that I arrived, I found his creations to be quite interesting. VTOL uses numerous mediums in his work to create some meaningful artwork. It was also evident to see how much passion he puts into his work. At one point, it was said that he puts about a month’s work into each one of his pieces. And based on the relative complexity of each piece, you would say he spent months on each one.
Throughout his talk, he discussed a lot about the process of making each piece, the difficulties, the successes. He focused on several of his works, most of which he showed video of working and the methods used to create.
After everything he showed us, his work still struck me as incredible. I found it quit daunting to see some of his projects, but the fact that he gets each one done in roughly a months time, struck me as absolutely mind-boggling.
There were two works he focused on that particularly struck me as interesting. The first was a work he entitled as “Division by Zero.” This work was interesting as it was a speaker suspended by a magnet, leaving it floating in the air. This sound object seemed quite interesting from his statements that he made in the talk. It uses bluetooth to send sound to the ariel speaker, and uses data in numbers to project rather uncomfortable and glitchy sound. From an outsider view, seeing the project is really interesting based on the pure floating idea. Additionally, it was interesting to see in the videos to see the speaker move based on the sounds output. It was quite the interesting cool project.
Screen Shot 2014-11-16 at 8.06.42 PM
The second project that really caught my interest was entitled “Financial Risks.” What VTOL created was an interesting standing machine, with several arms each containing a swipe card reader. This piece largely seemed to be a comment on societies continued and willing use to swipe items with confidential information anywhere. For the installation, any time a user swipes their credit card along the six card readers, the machine would save the order in which the card readers were swiped, and create a generative image. Once the user is done, they may type in their pin, and print a receipt, containing an image of the generated picture from the user’s input. On printing, it will also play tones in the order that the card was swiped as well. It creates a very interesting compositional piece.
Screen Shot 2014-11-16 at 8.46.38 PM

Those two pieces were two that VTOL focused on and talked about in his session, and definitely two that struck me incredibly interesting. As a whole, I came away from the talk a bit confused I suppose. When I see creators make work likes this, it makes me personally worried if I could ever create anything as interesting. I find creating to sometimes to be daunting, and the magnitude of VTOL’s work is a bit intimidating to say the least.

Event 2: Mark Mothersbaugh

The second event I attended was Mark Mothersbaugh’s talk at the university. It was hosted by Phi Beta Kappa honor society here at DU. He was there to promote his upcoming art exhibit, entitled “Myopia.” From the start, I was treated to some jokes between Mark and his friend who helped him produce his work, Adam Lerner. So that made the atmosphere significantly more welcoming. The talk began with Mark talking all about his life and his works and how he has practiced art throughout the years, with playful quips from Adam every now and then. He talked his college days, his days with the 80’s band DEVO and their social experiment of music. He states that as a college student, he and his friends were tired of the norms of culture, and liked to focus on the devolution of human society. He and these friends then formed DEVO as a manifestation of this frustration with society. They were interested in using technology to manipulate something to create something more interesting and focused on exploration of results, rather than quickness of results. It was interesting to hear about his life and involvement with music.

What was even more interesting about the talk as a whole, was his discussion on him getting into print art and drawing. From a young kid, he had a hard time seeing, and once he received glasses, he believed he was seeing a whole new world. This inspired him, at least at a young age, to start drawing. And that was the beginning of him drawing. He told the audience that he’s been drawing nearly every single day since. Its with kinda of practice that he’s used to create his works for his show Myopia. While drawing was the root of his creation, he used drawing as a connection to other types of media, from music, to painting. Drawing was his means to access a creative world and make those connections.


As a whole, the artist talk was far more enjoyable than I had anticipated, especially due to Mark’s relaxing demeanor and willingness to describe pretty much is whole process to where he was at. It was a great experience to hear about his work and how it has progressed throughout the years and evolved into his exhibition.

Event 3: Max 7 Preview and Launch

Not as “cultural” per say as the other two events I went to, but an event very relevant to classes I’m currently taking and relevant to our field. I attended a brief session lead by EDP Professor Cory Metcalf on the release of Cycling 74’s Max 7. The program after several years of the release of Max 6, received an upgrade that makes it both look more professional, and function more properly for the visual artists current needs. Cory showed off several new functions of the program, from objects to other new elements. From the get go, one can recognize that the program has taken a turn to be competitive with other programs, just based on looks. It takes a new darker grey color scheme, along with new icons and buttons along the top and sides of the screen to maximize workflow. It is a great and needed addition, especially one that may help others get into the product better. This new design just consolidates some of the tedium of the past version.
Additionally, Max7 includes many behind the scenes technical upgrades. The one that I praised the most when discussed, was the ability to autosave. From working with Max6 in the past, it would notoriously not save anything were your patchers to crash. Max7 carries that new feature that allows the program to recover your data were it to crash. Its a brilliant new addition.
Other new features include full HD video support, new objects that consolidate other older objects. The only problem that I could see and have been warned about is the workflow changes. Apparently, it could take a few minutes to get used to the layout of everything. But that doesn’t seem to be a problem for most EDP students. As a whole, it was awesome to see the product get launched and be able to hear about many of the new features first hand.


Week 10

Well, I had hoped to get a lot of work done on my project this weekend. Unfortunately, Thursday during class I got an awful headache. Which led into feeling like general crap for the rest of the weekend. So minimal work was accomplished in all of my courses.

Anyways, progress is still underway. I’ve decided to change up my hardware a bit, based on the class observation that our SparkCore’s aren’t working nearly as well as anyone would want them to. In order to ensure some sort of presentable idea come next Tuesday, I’m going to use the Arduino Pro Mini that we were given at the beginning of the quarter. It isn’t an internet of things board; it doesn’t have wifi or anything, however, I may be able to make my code work just as well on it as I could a SparkCore.

So, after a while, I got the Mini soldered and working with my code. The unfortunate part is this took me way longer than I thought. I had accidentally messed up one of the connections on the board with my attempts to solder headers onto the unit. So after some trouble shooting, I solved the issue and now it’s working just fine. So now, fortunately I have both a working Arduino Uno and a Spark Core. Double the options.

I suppose the only thing I’m worried at this point is getting my idea to as close to proof as concept as possible. I have a long uneventful weekend up ahead, so I will have plenty of time to get things done and rolling.

My next post will be a general progress update and cover the culture event that I have attended throughout the quarter. So stay tuned for that! I hope to get plenty of work done on Wednesday and Thursday as well.

It’s finals crunch time.

Week 9

It is week 9. That’s a terrifying thought.

I’ve made some moderate progress with my project. Unfortunately, that was the supposed “easy” stuff. Now its the long, arduous task of figuring out how to make my code do something more. Last week I was able to solder headers onto my sound sensor without screwing up.


So yay soldering! I tested some of the code first with sensor that one of my classmates had to ensure I was making things work right. So to make sure the audio sensor works, I ran a sketch that would make the small LED on the sensor light up (pretty basic, but any progress for me, is good progress).


So next, I tried writing some code to both read and send a message, tallying up the total number of sounds the sensor hears. Thankfully, for our class teamwork, I was able to create some code with a little help that would read in different sound levels based on frequency. So it reads frequency values from 0 up to 900.

Screen Shot 2014-11-04 at 2.42.16 PM

Yay, it can tell when I’m being loud!
So up next is to see if I can the code to tally up based on every time audio sensor hears something. The current value “1.00” under each one, is a mis-attempt at me trying to get that tally to work…
Actually, I just think I figured it out. It was working just fine, but I wasn’t getting my sound values over that threshold of what was needed to constitute as a tally. So that’s actually working now, as you can see here:

Screen Shot 2014-11-04 at 3.04.05 PM

I suppose now is the most difficult part of the process: making it so I can create a tweet or a blogpost based on the number of sounds tallied up. I first need to isolate the right frequency of my keyboard, and then go do my continued Temboo research.
I will say, however, as a precaution, I went ahead and ordered a touch sensor or two for the first project idea I had. If this project goes south, and I can’t figure out the best way to print my results, well, I have a project that isn’t as Internet of Thingsy as I would like, but one that I am more familiar with in terms of making it work.

Let’s hope for the best.

Week 8

Well this is the beginning of week 8. Its time to begin the hard work on our final projects. In between last week and this week, I nailed down at least a broad idea of my project. I’ll also talk about a couple of concerns that I hope my classmates and I will be able to figure out during the next week or so.

So I chose the Keypress project. I’m hooking up a sound detector to a microphone. The microphone will detect the keypresses and tally them up over a 1 minute period. At the end of that one minute period, the total tally of keypresses will be used to determine the length of a blog post or a Tweet (yet to be fully determined, will investigate and decide today).The blog post will total up to that number of characters, but be divided into a random number of words, all of various length.

So, great idea right? I think it’s pretty neat, and I’m excited to see where it goes. However, I’m worried about not getting close to proof of concept. And that worry stems from a number of steps/challenges along the way.

Like last project, here is my step by step checklist.

1. Get the Sparkcore working. Last week we struggled for a while trying to get our Sparkcore mini-boards registered. Fortunately, I got it working at the end of last week. So now its making sure it is still working.
2. Hookup the sound detector to the Sparkcore; create a sketch that reads data values brought in by the Sound detector. While mine is still in the mail, fortunately I have classmates helpful enough to let me borrow one of their’s.
3. Right code to tally the number of sounds/keypresses received.
4. Coordinate that code with two Temboos/Choreos. The first being Wordnik. WIth the Wordnik “Random Words” choreo, I hope to be able to make some sort of statement that divides the number of characters tallied, into potential words. Based on the number of characters, the data will select a word with that many characters. The second choreo from Temboo is a blogging site, with more information mentioned next.
5. Once this is achieved, the sketch will somehow use data to post a blog post. With what has been said above, the intended goal is to use another api of a blogging site to post a random blog post based on characters pressed.

So, getting this to work will be a process. I hope to get steps 2 and 3 figured out before the end of this week, with 4 and 5 finished before the due date.

Wish me luck.

Week 7: Final Project 2 Ideas

Let me start by first saying, how is it week 7? Where did this quarter go? The quarter system really boggles my mind in terms of how fast the weeks fly by. With week 7 comes more work and more things to get done. Fortunately, I have two quality concepts for my final class project.

To start off, both ideas involve using the Sparkcore miniboards to control the input and output of data. They’re small, selfpowered units that will allow me to be able to send the data to each other, or right back to my computer. Which is nice. Anyways, on to my project ideas.

Project 1: Interactive Emotional Button Pressing.

Ever see an EasyButton sitting on a friends desk and can’t resist the urge to press it? Or go to a website that has a button and says, “Don’t Press it?” Our minds are wired to want to impulsively do something, even if it’s the most menial and simple of tasks like pressing a button. For my first project, I wanted to combine that idea with some notions of emotion. I want to create two main units, each housing two buttons hooked up to a Sparkcore.  Each button is created by using a capacitive touch sensor or touch pad. Additionally, each button with have something signifying a sort of emotion. Ideas include painting one red and one green, one black and one white, one with a frowny face and one with a smiley face. At each unit, there would be signs enticing the user to press the button. With a press, a little small LED light display will blink and light up. Behind the scenes, the data based on each button pressed will be sent to my computer, which would be running a processing sketch. The sketch in turn, would create a data visualization, based on each button press. Other ideas associated with this could be differentiating each unit, without emotion connections, encouraging people to either “Don’t Press the Button” and “Do press the button” to create a visualization based on that differing idea. It’s still a thought,  hope to gain more feedback on the idea and its processes soon.

Project 2: Type Away

The second idea is based on the idea of key strokes and typing behavior. For this, I would look at mounting some sort of sensor to the side of my computer to interpret individual keypresses. Each keypress would then send a total number keypress count to a processing sketch and begin randomly printing words. At the end, it would create a blog post based on the number of characters pressed. Those characters would be divided into various lengths of words to create a seemingly random blog post. It seems like a pretty cool idea with not much complicated, however, the biggest concern I have is determining how to tally key presses. In terms of sensors, data out put is really limited. The best idea I have is a sound sensor, that takes in the right variable frequencies of keypresses. I too, hope to be receiving some feedback from classmates in which route I should take.

Either way, those are my two major ideas at this point in time. Fortunately, I don’t need to necessarily worry about one versus the other, as both involve getting started with understanding the Sparkcore.

I’m excited and nervous and stoked to see where this project takes me.

Week 6.5: Project 2 Ideas

One of the biggest problems I have some times is creative ideas. Combined with my limited knowledge of sensors and coding, this becomes even more difficult for my pathetic mind to handle. Fortunately, I’ve come up with a couple of ideas that could work for my second project. I believe at this point, my biggest problem on any ideas is any interpretation of the idea of Internet of Things objects. I have some ideas that can hook up with the internet, but an IoT object, as we defined, is hard for me to create an interesting and worthwhile idea.

  1. An object with multiple motion sensors placed in a fairly popular area. Data received from those motion sensors create a data visualization of sorts.
  2. An object with multiple motion sensors placed in a popular area. Data received makes another object move/change.
  3. -An object with motion sensors. Motion sensors/accelerometers/GPS placed with a person in a backpack or other carrier. Data based on distance travelled creates visualization. Could be set up that amount of travel info changes by day.
  4. An object that uses capacitive touches sensors. Data received based on pressing several different sensors create a data visualization. Each sensor brings it’s own change in the data represented. Used in coordination with other data received, potentially from online sources.
  5. Similar to idea 4, use sensors to take in some sort of data paired with a capacitive touch sensor. Use a lot of RGB LED’s to form some sort of representation in a grid of sorts. Probably using individual RGB LEDs, around 20 or 30 of em.
  6. Use a light sensor to detect overall change in light values throughout the day. Place sensor in a specific place that isn’t man made so it adjusts via natural lighting. Send data to a board and create some representation of changing light. Could be affected by many things that can change light values.
  7. -Use a motion sensor to somehow analyze how often a person types each day. Use these values in to create a random word blog based on the number of words typed.
  8. -Hook up a bunch of random pressure and capacitive touch sensors in an open area and encourage people to press them in random orders/etc. Save the data and order to create a data visualization. Potentially track data

Week 6: Adjustments and some fun designing.

Well, let me first start off by saying, “HOLY GUACAMOLE IT’S WEEK 6.” That’s not cool. The quarter system flies by so fast, you never know what has hit you. This means that the quarter is almost halfway done. I still have so much to do.

Thankfully, I was able to hand in my first project last week. It ended up turning out great. I presented first to my colleagues and received some incredible feedback. Most of the information I was given was helpful. I received some great new ideas, most of which I’ve already implemented into my redesigned project 1. While some ideas where pretty intense, others were on point in terms of formatting and making my sketch look cleaner.

Screen Shot 2014-10-14 at 9.10.40 AM

If we recall to my original project 1 sketch, it’s basic functionality is the same. It would show locations based on your area, and produce a colored and size representation of the quality of the business based on reviews. For the 2.0 version, I’ve changed it a bit. First and foremost, I made the overall name of the business size larger. That way you can actually read what’s on screen. Secondly, I’ve changed the names color as well. Instead of a white text, I made it a very light blue. Give’s it a little more pop. I’ve also spaced out the reviews and added arrows pointing to the corresponding review (still working on making it line up perfectly based on the text size growth of the review).
Additionally, I changed the colors of the ratings as well. Instead of making them change distinctly from red to green, they now change from dark grey to white. While there could be better color correlation, the dark grey to white indicates that the fainter reviews are more negative that the ones that stand out due to both their size and how white the color is. The final improvement is the addition of the “Recommended” text to the right of the reviews. Any review with a score above a 4.6 will receive this designation, based on the fact that these are arguably the best businesses in the area. It’s a small, but more resourceful change.


In other news, last week we discussed the content of the TBD Catalog and how some of the ideas were formulated and are viewed as Internet of Things objects. We looked at the process of how these ideas were designed via the TBD card game. It was actually quite fun to sit down with several of my colleagues and brainstorm some goofy and helpful ideas of the future. We were given three cards: one representing a thing, one an attribute, and the other being a function of the object. So combined plus our brains, we would make create some interesting ideas. For me, the concept that I created and stuck with me was the Boomba. It was a Roomba vacuum cleaner mixed with a set of Bose Speakers. Designed to cover up the awful noise of a normal vacuum by playing music loudly over it. People may sync up with it via Bluetooth, wifi, or over 4g XLTE data. The ideas was to make the chore that the vacuum was doing for you, more entertaining for the owner, by allowing them the freedom to play music and relax while the Boomba does all the work. It turned out to be a fun design to create and to present to both the class and to Julian from the team behind the TBD Catalog. I love designing, so it was a nice change of pace from coding for me. Next week we will see where both the designing and the coding ideas will take me in terms of brainstorming our second Project.