The Video Machine

Overview

The Video Machine is a video controller, powered by an Arduino, that controls the playback of videos presented on a web browser. By pressing a button on the controller, the correlated video is being played on the screen and heard through the speakers.
Videos are being played in an infinite loop.
Only the videos that are being played, are being heard.

I was lucky enough to work on this project with the super talented Mint for our Physical Computing class mid-term.
Working with Mint not only was a great learning experience, but also a lot of fun! I hope I’ll be able to work with her again on our next project (more on that below).

The Video Machine from Dror Ayalon on Vimeo.

Many thanks for Joe Mango, our beloved resident, who assisted a lot with finding the right technologies for the project, and helped us on one critical moment, when suddenly nothing worked.

The Video Machine – Split Screen from Dror Ayalon on Vimeo.

The building process

The process of building The Video Machine went through the following stages:

  • Prototyping – Once we had a broad idea about what we want to make, we wanted to test how hard would it be to build such interaction, and if the interaction feels ‘right’ to us.
  • Understanding the complications The prototyping stage helped us understand what could be the possible complications of this product, and what might be the limitation. We analysed what could be the limitations of the serial communication between the Arduino board and our laptop computer, and what types of video manipulations could be easily achieved using JavaScript.
    Understanding what’s possible helped us shape our final design, and the different features
  • Designing the architecture – Before we started to build the final product, we talked about the technical design of the product under the hood. These decisions basically defined the way the end product would operate, and the way users would interact with it.
  • Picking up the technologies – To apply our technical design, we needed to find the right tools.
    For the video manipulations, we decided to use vanilla JavaScript, because its easy to use video API. The biggest discussion was around the implantation of the buttons, on which the user needs to press in order to play the videos. After some research, and brainstorming with Joe Mango, we decided to use the Adafruit Trellis. That was probably the most important decision we took, and one that made this project possible to make, given the short amount of time we had at that point (four days).
  • Building, and making changes – We started to assemble the project and the write the needed code. While doing that, we changed our technical design a few times, in order to overcome some limitations we learned about along the way. And then came then moment where everything worked smoothly.
The Video Machine - Final product
The Video Machine – Final product

Some code

The entire code can be viewed on our GitHub repository.

Reactions

The reactions to The Video Machine were amazing. The signals started to arrive on the prototyping stage, when people constantly wanted to check it out.

When we showed the final project to people on the ITP floor, it appeared that everyone wants to put a hand on our box.

The Video Machine
The Video Machine

People were experimenting, listening, looking, clicking, laughing, some of them even lined up to use our product.

The Video Machine
The Video Machine

Further work

I hope that Mint and I will be able to continue to work on this project for our final term.
I cannot wait to see the second version of The Video Machine.
I believe that the goals for the next version would be:

  • To add more functionality, that will allow better and easier video/sound manipulation.
  • To make playing very easy for people with no knowledge of music or playing live music. Beat sync could be a good start. The product should allow anyone to create nice tunes.
  • To find a new way to interact with the content, using the controller. This new interaction needs to be somethings that allows some kind of manipulation to the video or the sound, that is not possible (or less convenient) using the current and typical controller interface.
  • To improve the content so all videos will be very useful for as many types of music as possible.
  • To improve the web interface to make it adjustable for different screen sizes.
The Video Machine - Controller
The Video Machine – Controller

The ITP GitHub Hall of Fame

To practice my web APIs skills, I got some data from the GitHub API, and used it to create a list of the most starred (== popular) ITP related repositories.

See it here.

The ITP GitHub Hall of Fame
The ITP GitHub Hall of Fame

The expected (unpleasant) surprise

The process of making this page wasn’t smooth at all. In fact, this project cannot be further away from my original intentions. Here’s the truth:

  • I decided to let users enter a word (as an input), and to use this word to form a Haiku poem from three different poems.
  • I found poetry.db, which at first glance looked like the perfect source for my project.
  • I started to work on the logic that will form new Haiku poems out of the text I’ll get from poetry.db.
  • The logic was partially ready, and I was eager to test it on real data.
  • Oh no! My browser is shouting at me that I have a cross origin request error, and it is blocking my request to the API. I’m starting an endless search to find a solution, while going over countless Stackverflow threads, that appeared to be somewhat useless in my poor situation.
  • Aha! Apparently, JSONP should be JS’s workaround for this problem. My project could be saved!
  • Oh no! poetry.db’s server does not support JSONP. My options are:
    • To setup a web server and to hope for the best.
    • To try to find a new project that has better chances of success. — Chosen.
  • A new project! This time I’ll go for an API that was build by great developers, for the average developer, something that is a ‘one size fits all’, and I can assume that is stable and well maintain – GitHub’s API!

Some conclusions

GitHub’s API is well structured, fast, and reliable. I will surely recommend it to everyone.

Eventually, this process taught me (again), that when I deal with web APIs, the hustle is just part of the game. I’m sure that if I had some more time (a few extra days) I could have found a solution for the poetry.db API, and I could have completed my original project.

The cross-origin problem is a problem I face often, and I hope that we will be able to talk about it in class. I really feel that mastering the logic behind the cross-origin workaround is critical for web development.

(if you got to this point, feel free to scroll up and click that ‘See it here’ link again).