Plagiarize Something: Synthesizer Edition

March 20, 2013


Welcome to Who Plagiarized It Anyway?, the DIY game show where everything is replicated by following a tutorial and the points don’t matter.

This past week-and-a-half or so, I put almost all my other commitments on hold to build this super great little synthesizer. Why build a synthesizer in a wearable computing-centric course, you might ask? Because synthesizers are cool and 8-bit bleep sounds make me happy. If you’re interested in following along and building your own, you can find the tutorial on Instructables here.

The synth is very simple and easy to use. A power input is featured on the left side of my box, and a 1/4″ audio output jack on the front. In the photo above I’ve used a 1/4″ to 3.5mm adapter to hook it up to my speaker system at home. I will note that, in the event that you get to use my version of this project one-on-one, you should be discouraged from using headphones, as this thing is pumping out a 5v signal that will probably-certainly make your ears bleed.

At the top of the box are a power switch and LED, a tempo knob and orange tempo LED, a frequency knob to control the pitch of your sound, and a big shiny record button for storing sequences of pitches into temporary memory for looping.

The real source of magic (frustration) behind this project is the brain of my synth – the ATtiny45, an 8-pin microcontroller. Although the tutorial has instructions laid out for using the Arduino as well (which I have actually used in the past), I was encouraged to go this route. Although this slowed down my progress very early on thanks to a moderate learning curve, I ultimately gained valuable knowledge and am far less likely to shy away from using it in future projects.

Big thanks to Steve Daniels for supplying me with the ATtiny45 chips I used, the AVRISP mkII programmer to make them do things, and some subtle guidance throughout the process.


My proto-synth, a.k.a. my components laid out on a breadboard.

Pictured above is my prototype, laid out only moments after I got the ATtiny45 working for the first time. The reason this took me so long to get off the ground (2 nights worth of troubleshooting to be precise) was because I needed to do more tinkering than I’m used to in order to program the darn thing. Whereas the Arduino is essentially a plug-and-program device, the ATtiny45 required the use of an external programmer (in this case, the AVRISP mkII) and the use of a voltage regulator (a 7805). The ATtiny wants 5v of power and I had 9v, and for some reason I didn’t realize this until the second night. Why? A) because I’ve never used a regulator before, and B) because I brushed over any mention of the 7805 in the tutorial. To be fair, the tutorial assumed a lot of things about my prior experience going into this project. Google was certainly my friend in this journey.

Luckily, the 7805 is very simple to use and after getting over that hurdle the programming process went through fairly smoothly. I followed this tutorial to get the programming ball rolling, adapting any mention of the Arduino to the AVRISP mkII I used.

In the photo above on the right side you can see my AVRISP mkII connections still intact. To program the ATtiny, I laid the chip between those connections in the centre of the breadboard. The programming itself was done through the Arduino IDE, just like programming a regular Arduino.


Planning out the holes to-be-drilled on my enclosure.

I’ll use this out-of-context photo to talk about a couple more of my challenges in getting the ATtiny45 to abide by my will. Firstly, although I had successfully programmed the chip after two nights of tinkering, the sound output was sounding like a rapid series of irritating ticks. After doing some research (because of course, the tutorial didn’t make any mention of this possibility), I theorized that I was having a clock speed issue. A virgin ATtiny45 runs at 1 MHz, though bootloaders can be burnt onto it to have it run at 8 MHz (which it is natively capable of) or 20 MHz (which requires an external crystal oscillator hooked up to the chip).

For some reason I thought burning the 20 MHz bootloader onto the chip would be a good idea. It turns out that once this has been done, the ATtiny wants to run at 20 MHz no matter what. As a result, I was unable to program the chip after this point, much less burn the correct 8 MHz bootloader. Luckily, I had two ATtiny45s! Of course the solution was to burn the incorrect bootloader onto both chips! Huzzah!

So now instead of a terrible sounding synth, I had two bricked microcontrollers. It turns out the only way to alleviate the issue (outside of a hard reset) was to give the chips what they wanted. I purchased a 20 MHz crystal and a couple 18 pF capacitors, hooked them up to the ATtiny’s, and upon burning the 8 MHz bootloader was back in business!


Drilling holes from my enclosure.


A close-up of the box with the components mounted.


The underside of my mounted components.


(Almost) everything mounted and looking shiny!


My circuit board with most of the components soldered on.

Of course the issues didn’t end there. Although I had gotten my ATtiny’s to work once again, the sound output was still poor. I was troubleshooting the issue at school one afternoon and ran into David Bouchard who I am eternally grateful for. Not only did he basically volunteer to help me fix this issue, he stuck around for likely close to two hours until my synth was sounding great.

I won’t get too in-depth here, but I’ll summarize the gist of it:

1) I needed to be designating certain pins on the chip as analog inputs rather than digital (it seems the ATtiny45 is a bit more fiddely in specifying the I/O than Arduino is) — this wasn’t related to the sound issue, but to the potentiometer I was using for my tempo, which it turns out wasn’t actually doing anything.

2) I needed a capacitor (10 µF) on my power rails to address the sound issue. This wasn’t mentioned in the tutorial at all, though he used an Arduino through his process which may explain some of the discrepancies I was having. Nonetheless, this made everything work and brought a smile to my face.


The circuit board, components, and enclosure coming together.

If I said those were the last of my issues, I would be lying however. It turns out my enclosure is made of aluminum. Apparently aluminum is a conductive material and you shouldn’t be leaving electronic components on it all willy-nilly. This caused more than a few short circuits, though my sleep-deprived brain presented me with the ingenious solution to tape all of the things! Long story short: I masking taped a lot of the box and some of the component leads, and that made everything work just fine.

You can check out a brief video documenting my fun playing with the synthesizer below.

TIFF Next Wave Report

May 13, 2012

TIFF Future Games, Students playing Face Fighter

You may recall that Jonathan and I were fortunate enough to see Face Fighter featured in the TIFF Next Wave festival. The event, which happened from May 10th – 11th, exhibited seven films and five video games created by post-secondary students in the Next Wave “Future Frames and Games” programme. The experience was incredible without a doubt, and here I’ll attempt to share my experiences.

Firstly, for those not in the know, TIFF (the Toronto International Film Festival) is a Canadian not-for-profit organization best known for their annual cinematic extravaganza, which regularly draws in celebrities, famous directors, and other related figures into the city. (I guess they show films too, but we won’t get into that). In the last few years, TIFF’s horizons have expanded quite a bit to help further foster and support creativity in the Toronto arts and media industries, most recently with the TIFF Nexus initiative. I’ve had the pleasure of working with the TIFF Nexus team a few times and can vouch for the incredible work they’re doing for the public awareness of New Media art in Toronto.

Introductions aside, the Future Games programme was a great opportunity for Jonathan and I to help make a bigger dent into this swiftly-growing Toronto indie game development scene. We were able to meet the developers of three out of the five games that were shown (four out of five if you count our game, but we were kind of already familiar with ourselves). To Glen Watkinson, Nguyen Tran, Derrick Law and Samuel Law, developers of Crack UP, Nimbus, and ASDF, it was an honour meeting you all and I look forward to seeing what new games you all churn out in the coming years.

TIFF Future Games Exhibitors

As for the “screening” itself, TIFF welcomed about 30-40 high school students on the first day and closer to 60 on the second day. We got to watch them enjoy our game, attempt to assist friends without realizing that the game’s head-tracking might be negatively affected by peering over their friend’s shoulders, and overall have a head-bangingly good time.

After students tried out our games for about an hour, we got to sit on a panel, mediated by the amazing Nick Pagee and Peter Kuplowsky, and answered some of the questions they had for us. Jonathan and I shared our experiences conceiving of the game’s premise (which involved a good number of Tim Horton’s donuts and some borderline-hallucinatory late nights brain storming), as well as some advice for students who were struggling between studying in a “profitable” field and, well…game design. Needless to say, we encouraged them to do whatever it was they truly loved while protecting the integrity of the game developer community. In particular, I mentioned the recent planting of Ubisoft’s Toronto studio and the provincial investments being made into the video game industry. For anyone who is struggling with their love of game making, I would say now is as good a time as ever to be apart of this ever-growing community.

I’d like to give a big thank you to all of the TIFF programmers and staff who made the Future Games exhibit possible. I had a blast participating in the event and hope to be involved in more to come!

A Networked Face Fighter

April 30, 2012

Face Fighter Networked

By now, many Torontonian New Media art lovers are familiar with Super Conveniently Head-Controlled Face Fighter 10987654321. Put simply, the game is a classic space shooter, except you control your ship through a face tracking interface. Moving your head from side to side maneuvers the ship, and nodding your head causes the ship to shoot a bullet. To create more interesting interactions with the game, Jonathan Séguin and I experimented with adding a networked layer to the piece for some multiplayer shoot’em up action.

We were initially intrigued with the idea of creating a “spontaneous multiplayer mode.” Users would play through the game as though it were a regular, single-player Face Fighter experience, up until the point where a second user connects to the game server. Once this happens, the first player’s game would be interrupted with a “warning” signal, shortly followed by the introduction of the second player’s purple ship. Players would engage each other in a teeth-grinding duel, created by a continuous series of speedy decisions — “should I shoot or dodge at this moment?”

Face Fighter Networked Screenshot Full

Another concept that struck us was the notion of replacing a boss’ AI with an additional user’s input. This case would be similar to the scenario outlined above, except the second player sprite might be the giant boss head we never ended up using for the game. This way, both players wouldn’t suspect that they are in a networked experience, but instead assume that they are facing a boss with a sophisticated AI.

We did end up creating a prototype for the first outlined scenario (two ships facing off against one another). In the prototype, basic functionality for transmitting and receiving movement from both players simultaneously was developed.

The idea of “spontaneous networking” has excited us to create more iterations of the game with this networked layer. We would like to test user’s behaviours and reactions in this context to see whether or not human input is identifiable, even behind a computer interface and graphics.

Face Fighter to be Featured in TIFF Next Wave!

April 12, 2012

TIFF Next Wave

You heard that right, folks! Super Conveniently Head-Controlled Face Fighter 10987654321 (or simply “Face Fighter” for short), an interactive video game installation created by Jonathan Séguin and myself is going to be featured in TIFF Next Wave from May 10th – 12th. More specifically, our piece will be shown in the “Future Games” exhibit.

They accentuate the film component quite a bit in their advertising, but it’s good to know that video game innovation is being celebrated in the Toronto cultural arts scene. Rest assured, TIFF has given our game a “G” rating, so feel free to bring along your youngins.

From the Future Games website:
“Future Games presents a selection of the country’s most challenging and innovative video games made by post-secondary students. A hands-on play session at TIFF Bell Lightbox will be followed by a panel discussion, giving high school students a chance to engage with the creators and discuss game and interactive media design opportunities at Canadian post-secondary institutions.”

You can see more about the exhibition, as well as the other four games being featured alongside Face Fighter on their website.

Response: On Getting Paid by Jessica Hische

April 9, 2012

Jessica Hische has written an excellent series of articles primarily directed to young designers and illustrators who are looking to get (paid) work in their respective industries. Typically, young freelancers such as myself struggle with the whole monetary compensation thing, and unjustifiably so. Hische is fairly keen on the idea that all designers with at least some weight to their work, even undergraduates, deserve to be paid for their services. Period.

A young designer could encounter several scenarios (many of which are humorously highlighted on Hische’s Should I Work for Free? flowchart) — for example, are you doing work for a legitimate business, a not-for-profit, or a charity? Should you be getting paid to some degree regardless? In most cases, Hische concludes with a resounding “yes” — that you should not only be getting paid for your work, but also critically thinking about what you charge. The value you attach to your services will consequently be attached to how much you’re worth as a professional. Hische suggests that keeping your rates in check (and at a reasonably high amount) will help to set a standard for all clients looking to hire within design-related fields.

I’ve had a particularly difficult time deciding to charge an hourly rate versus a flat fee from personal experience. Clients tend to prefer solid quotes that they can budget for. Even in the event that you prefer to charge an hourly rate, the client is at least going to expect that you’ll know how much time will go into the project (and as a result, how much they’re going to be paying). This is especially challenging for new freelancers who don’t quite know how much time they’ll need to put into a particular project. Hische bluntly states that “pricing hourly punishes efficiency” (though she does say to take the idea with a grain of salt). To explain this idea, she uses the example of two professional designers who produce work of equal value, both charging hourly rates. However, one designer works at a more efficient pace than the other, accomplishing in 7 hours what the other designer did in 18. If both were to charge $100 an hour for their work, the client would be paying out $700 to the more efficient designer, whereas they would be paying $1800 to the less efficient designer for a work of equal value. Hische is firm in declaring that this isn’t fair, and to combat this, all designers should consider charging at flat rates.

I think one of the biggest concerns for young designers is knowing how much to charge for your work — especially if you opt to charge a flat rate. How much value can you really attach to your work when you’ve only had a few clients under your belt? While Hische does provide a quote example for charging an international clothing brand, she notes that most designers are reluctant to share what they charge with the rest of the world for fairly understandable reasons. Ultimately, “standard prices” are not set in stone for a new designer. When deliberating on a quote, Hische notes that designers should consider the amount of time they’ll be putting into the project, how big the client is, and what kinds of rights they will require.

Reading what Hische has to say on the matter certainly helped shed some light on considerations to be made when charging a client. The bottom line is that our work has a value, and we will set the bar for what it’s worth — what we’re worth.