This project reflects an obsession with wires, communication, and out-of-date consumer products. In order to do so, this installation explores systems of translation and adaptation by dismantling objects which are on the outer edge of their usable life and imbuing them with new, but not always useful, functionality.

A non-exhaustive list of the materials involved includes: an FM radio, an electric chord organ, PVC tubes, rolls of hole punched paper, and large plastic pillows filled with air. Connected by a series of inputs and outputs, the system plays out an absurd comic moment where all of the machinery forces airflow and data into a small instrument, playing an indecipherable tune.

The objects in the exhibition are meant to be used in conjunction with each other, in order to make a large elaborate instrument. The instrument works a bit like this: the Beep-Boop Machine reads data in the form of punched rolls of paper, and converts that data into MIDI. The MIDI information is then sent along a cable over to the micro-controller which controls the servo motors. Eventually, the data is expressed when a specific servo motor depresses a key on the chord organ.

Separate from that, the chord organ also needs airflow in order to produce sound. Whether it is a manual hand-pump or the new set of external fans, airflow must be generated for the chord organ to make noise. The air stored in the air-pillows serves as a container for this energy to be deployed within the system, which can be manipulated to increase the volume of the organ.

But Does it Actually Work?

Yes! Below is a run through of what the installation looks like in action. There is also a much shorter version with more closeups here, and this is an example of the chord organ playing a composition by John Cage.

Bonus

For making it this far down the page here is a little looped excerpt from Charlie Chaplin's Modern Times. This clip as well as another scene were projected adjacent to the installation during the exhibition, as aa way to bring some frantic energy into the space if I wasn't there to pump air.

In culmination of my studies at OCAD University, I will be having my MFA thesis exhibition on Saturday March 11th @ 49 McCaul Street, Toronto!

The exhibition Beep-Boopatronics is a project which takes nearly obsolete objects and imbues them with new, but not always useful, functionality. In particular, this exhibition takes a chord organ which plays itself, and connects it to a Beep-Boop Machine in order to examine how things can speak to each other.

WHEN

Opening reception: Saturday March 11th, 1:00pm - 4:00pm
The show runs from March 9th to 14th, 11:00am - 4pm

It’s been three years to the day that Google Reader shut down. And here’s a feature they could never build. Introducing email newsletters in your RSS reader.

You can now forward your email newsletters over to NewsBlur and then read your email newsletters right in your browser/phone/TV/tablet. A couple dozen users have been beta testing this feature for the last couple of months and everybody agrees, this feature is amazing.

Newsletters are formatted to fit all of your screens, so it looks just as good on the web as it does on your phone.

Here’s the best part. If you get a lot of newsletters, you can group them into folders and even train them to highlight the newsletters you want to read first.

Setting up newsletters on NewsBlur is easy. Just follow the personalized instructions on the web by going to Manage > Email Newsletters on either the web dashboard or the manage menu.

You might ask why not just subscribe your custom NewsBlur newsletter email address directly to the newsletter instead of forwarding copies of the newsletter. The answer is that if you want a single source of truth for where newsletters are going, you want that in your email client and not on NewsBlur. If you ever change news readers (and with new features like this, why would you want to) you’ll want to change only a single filter rule instead of dozens of newsletter emails.

And with this huge new feature, NewsBlur just became even better. NewsBlur has branched beyond RSS for a while now, fetching Twitter and YouTube stories even without RSS. With newsletters, NewsBlur becomes your single source.

Just Another Beep-Boop Machine is a small artwork, made to create an opportunity to play with music. A participant can punch holes in the provided cards, which are then used as the input information for the device to play a tune, as can be seen in the video above.
The cards can be used to reproduce familiar songs, or to just punch as many holes as you can, to see what happens.

How it works

The glowing green light emanating from the mouth of the device is actually a key part of its function: the holes punched into the cards allow the light to hit a corresponding sensor, which signals the microcontroller to play the requisite note. When the card is inserted, it covers the center light sensor, triggering the movement of the servo which draws in the card to play the song.

Its guts kind of look like this:
There you can see the array of LEDs, and photo-resisters which activate the sound. Not pictured is the microcontroller brain, which for this project was an Espruino Pico, flashed with MicroyPython (a process I detail here).

How To

I can not promise that this will be a comprehensive guide, but it should be a good foundation for you to try a similar project.

First some preliminary steps:
1. Grab all of the project's 3D models and assets from Thingiverse (don't forget to download the card templates from here as well!)
2. Get the source code for the project here
3. Review how to wire up a photo-resistor to a micocontroller from this post (though that code example is for an Arduino)

The 3D model file LED-holder.stl is the top mount for the LEDs, and will need to be 3D printed. For this project I used something similar to these (which were actually just a bit too bright). The LEDs just need to be mounted into this holder, and then wired in series to the microcontroller.

The file sensor-holder.stl, as you can guess, will hold the light sensors. Each needs to be mounted, and then wired to a specific pin on your microcontroller. For this project, the sensors are being used as a simple on-off switch, instead of sending analogue information. This makes the project a bit more flexible, as it does not require a crazy amount of analogue pins. The sensor-holder.stl and LED-holder.stl need to be connected with a 4-40 bolt on each side.

The servo is held in place by servo-mount-no-holes.stl, but the 3D-printable file does not have holes to bolt the servo in place, and so those will have to be drilled in later (...or you can just affix the servo to the mount with some tape, while you are adjusting its placement). The exact servo I used was this one, but just about any continuous rotation servo of a similar size should work. Once in place, attach the ring.stl to a servo disc, and then slide on an elastic band for some grip. The one sort of tricky thing is that you will have to find a way to put some pressure on the wheel, in order to drive the card through.

The Code

As mentioned above, the code runs on a microcontroller running MicroPython, and the script can be found here. You just need to wire up the components to the pins outlined in the code (or equivalent for different boards), and upload the main.py onto your device.

Really though, this project can be done on almost any microcontroller, as long as you write a script with similar logic. Basically, the main.py script just does this:

Initialize the pins corresponding to the light sensors as inputs.

Set up a PWM pin to output to a speaker or piezo buzzer.

Create a function which takes the pin receiving light, and then activates the piezo to play the corresponding note.

Wrap this all up in a loop that checks to see which pins are full of light, and then act accordingly.

Recently, I became quite interested in a new microcontroller called the pyboard (US|UK) which "is a small electronic circuit board that runs Micro Python on the bare metal, and gives you a low-level Python operating system that can be used to control all kinds of electronic projects".1

I've completed a number of projects with the Arduino, and Raspberry Pi, but I am particularly excited by MicroPython and the pyboard as they fit a great niche: the ease and flexibility of the Python programming language on a small and power efficient microcontroller. The only downside is that in September I will once again be tight on funds, as I am heading back to art school for one last last time again. As a result the pyboard's $44.95 USD price tag from Adafruit felt like a bit too much to spend on a fun experiment, without having a specific use in mind...

...buuuuuuuuuuut, after comparing the list of boards that MicroPython has been ported to, with what else is for sale on Adafruit, I found the Espruino Pico: an even tinier microcontroller for sale for only $24.95 USD! Of course, the lower price tag comes with comparably less functionality than the pyboard (the official pyboard is quite feature packed!), and also includes the burden of having to manually install MicroPython on the Espruino Pico.

Time to Install MicroPython on the Pico!

I've updated this post with instructions for two different ways to achieve our goal. In this post I'll start with the 'easy way', which will get us up and running a bit quicker. However, the second 'hard way' (I mean, it has a few more steps) is useful if you plan on hacking on the C code. In any case, both are kinda fun!

The Reasonably Easy Way

This set of instructions avoids the installation of alot of additional software, and removes the need to compile things from source. But still, before the real fun can begin we have to do a quick modification to our Espruino Pico.

Step 0: Preparing the board

To install new firmware onto to the Espruino Pico, we first need to figure out how to put the board into 'Device Firmware Upgrade' (DFU) mode. On the bottom of the board there is a set of BOOT0/BTN pads.
Shorting out this connection by rubbing an HB pencil across the gap will connect the push button on the top of the board to BOOT0. As a result, when you press the button and plug the board into a USB port (while continuing to hold down the button), the board will power up in DFU mode. Woo! If you would like some additional help programming the Pico, you can review the 'Advanced Flashing' section of this page.

Step 1: Getting the Software

If you visit https://micropython.org/download/ you will see a recent snapshot of the MicroPython software available to download. Additionally, at the bottom of the page there happens to be a 'Firmware for other boards' section, which includes a link to download a pre-built firmware image for the Espruino Pico!2 SO, grab a copy of each, and we can get started.

Take your micropython-master.zip file and extract it to your home directory. Then, in ~/micropython/tools you will find the file pydfu.py. This python script does rely on two dependencies that you may not have installed: pyusb, and libusb. If you are on Debian/Ubuntu you can solve this by running sudo apt-get install python-usb python3-usb, which will pull in libusb as a dependency.

For alternative instructions you can follow along here, and it should all work out okay. As of this writing, the most recent firmware file for the Pico is espruino-pico-2015-08-12-v1.4.5-1-gb7d5906.dfu, and so that is what I will use in the example below.

Step 2: Upload the Software

Move your firmware file to ~/micropython/tools, and in your terminal change your current working directory with a quick:

cd ~/micropython/tools

Now we just need to run:

sudo ./pydfu.py -u 'espruino-pico-2015-08-12-v1.4.5-1-gb7d5906.dfu'

If that completes successfully, then we did it! If things didn't quite work out then you may:

not have properly put the Pico in DFU mode

not have the right permissions to complete the above command

have done everything right, but still strange things happen for some strange reason

If strange things are happening, then it might be useful to take another look at the 'Advanced Flashing' section of this page, or do a search on the MicroPython forum.

Anyway, now that we've installed MicroPython you can go on ahead to the Testing it Out section of this blog post, and do fun things!

The Harder-ish Way

If you would like to compile the project from source, and do things manually, the MicroPython dev wiki does include just about all the info you would need to get the job done, but if you're new to the project the necessary information is split across a fewdifferentpages. Really, this entire blog post is just a compilation of the wiki's material, using slightly plainer language, mostly so that I can keep a record for myself all in one place for future reference.

To get things started, take a look way up at Step 0, to get your Pico ready to be programed.

Step 1: Preparing your computer

Before we can do anything really exciting, we have to install some software. I am using Debian 8 for this process, but it should be similar for recent Ubuntu versions. Note that the bulk of the text for this section was abridged from this page of the wiki.

Install dfu-utils

sudo apt-get install dfu-util

Create a udev rules file.

run sudo nano /etc/udev/rules.d/49-stmdiscovery.rules in your terminal, and enter the following contents:

That is the udev rule for the 'STM32F4 Discovery Board' from the MicroPython dev wiki linked above, I think it works in our case because the Discovery Board has the same usb vendor-ID:model-ID as the Espruino Pico. Or something.

Tell udev to reload its rules: sudo udevadm control --reload-rules

With this rule in place, we will not need to use sudo to deploy the firmware later on.

Step 3: Preparing the software

So. In order to put new firmware onto our Pico, we need to install some more additional software, and get the MicroPython software first.

You will need the following packages:

build-essential

libreadline-dev

libffi-dev

git

gcc-arm-none-eabi

binutils-arm-none-eabi

You can install these packages by running: sudo apt-get install build-essential libreadline-dev libffi-dev git gcc-arm-none-eabi binutils-arm-none-eabi. This will also probably pull in a bunch of dependencies.

Note that the gcc-arm-none-eabi binutils-arm-none-eabi packages are needed as we will require an ARM compiler. More info here if needed.

Now, we can get the source for MicroPython by running: git clone https://github.com/micropython/micropython.git

Once that is finished, to build for our platform we need to enter the directory for the stmhal port: cd ~/micropython/stmhal/

Step 4: Do the thing!

And now, we are finally at the point where we can do the thing that we came here to do!

To compile the firmware we just have to run: make BOARD=ESPRUINO_PICO from within the ~/micropython/stmhal/ directory.

If you recall from way up in Step 0, now is definitely the time to put the board in DFU mode by shorting out the BOOT0/BTN pads, and plugging the board into your computer while holding down the button on the top of the board.

Aaaaaaaaand now you just need to run:

make BOARD=ESPRUINO_PICO deploy

If all goes well, your terminal output should look something like this (be patient, this may take a while!):

If this didn't work, it could be because:

you don't have the packages installed to cross-compile for ARM

the board was not powered on in DFU mode

the udev rules thing didn't work out, in which case you can try sudo make BOARD=ESPRUINO_PICO deploy

there is a mysterious problem which is mysterious.

If you run into a mysterious problem, review the full instructions for the Discovery Board. Or, take a look at Step 2 of the 'easy way', and see if that works better for you.

Testing it Out!

If the previous steps for either method all went smoothly, we can test out the board by unplugging it, and plugging it back in. If your computer mounts the board as a storage device named 'PYBFLASH' it all worked out! In your terminal you can now enter screen /dev/ttyACM0 (may need to be run as sudo, depending on your setup) to access the python interpreter running on the board itself! In the interpreter, some quick example code is:

>>> import pyb
>>> led = pyb.LED(1)
>>> led.toggle()

This will turn on the Pico's red LED. You can also run a script in the root of the PYBFLASH directory as soon the board boots up, as long as it is named main.py. You can read way more about all this on the MicroPython docs: http://docs.micropython.org/en/latest/. When you're reading the docs, the examples sometimes give reference to the pin names for the pyboard, but the Pico has a whole different set of names which you can review here: http://www.espruino.com/Pico. For example, in the fading LED tutorial instead of assigning the LED + timer on pin X1, you could use pin B13.

Wrapping up

When it comes down to it, microcontrollers are fun, python is fun, and the two of them together should be super-great. I am a big fan of the MicroPython project and I do encourage you to check out the pyboard (US|UK) as it is an all around more capable device than the Pico: the official pyboard has more storage, more ram, accelerometers, and etc.! However, it seems that for artists and students there is something of magic microcontroller price-point around $24-$30 USD, and so if flashing the Pico gets MicroPython in more people's hands...then that's great!

FINAL NOTE: If any of the commands/advice/whatever from this blog post cause you or your electronic devices any harm of any kind: I AM TOTALLY NOT RESPONSIBLE.

This quote, an explanatory video, tutorials, and more can all be found at micropython.org! ↩

Thank you to Damien who pointed out to me that pre-built firmware for the Pico can be found on this page. ↩

Between 2003 and 2009, most music purchased through Apple’s iTunes store was locked using Apple’s FairPlay digital restrictions management (DRM) software, which is designed to prevent users from copying music they purchased. Apple did not seem particularly concerned by the fact that FairPlay was never effective at stopping unauthorized distribution and was easily removed with publicly available tools. After all, FairPlay was effective at preventing most users from playing their purchased music on devices that were not made by Apple.

Fundamentally, DRM for downloaded music failed because it is what I’ve called an antifeature. Like features, antifeatures are functionality created at enormous cost to technology developers. That said, unlike features which users clamor to pay extra for, users pay to have antifeatures removed. You can think of antifeatures as a technological mob protection racket. Apple charges more for music without DRM and independent music distributors often use “DRM-free” as a primary selling point for their products.

Unfortunately, after being defeated a half-decade ago, DRM for digital music is becoming the norm again through the growth of music streaming services like Pandora and Spotify, which nearly all use DRM. Impressed by the convenience of these services, many people have forgotten the lessons we learned in the fight against FairPlay. Once again, the justification for DRM is both familiar and similarly disingenuous. Although the stated goal is still to prevent unauthorized copying, tools for “stripping” DRM from services continue to be widely available. Of course, the very need for DRM on these services is reduced because users don’t normally store copies of music and because the same music is now available for download without DRM on services like iTunes.

We should remember that, like ten years ago, the real effect of DRM is to allow technology companies to capture value by creating dependence in their customers and by blocking innovation and competition. For example, DRM in streaming services blocks third-party apps from playing music from services, just as FairPlay ensured that iTunes music would only play on Apple devices. DRM in streaming services means that listening to music requires one to use special proprietary clients. For example, even with a premium account, a subscriber cannot listen to music from their catalog using an alternative or modified music player. It means that their television, car, or mobile device manufacturer must cut deals with their service to allow each paying customer to play the catalog they have subscribed to. Although streaming services are able to capture and control value more effectively, this comes at the cost of reduced freedom, choice, and flexibility for users and at higher prices paid by subscribers.

A decade ago, arguments against DRM for downloaded music focused on the claim that users should have control over the music they purchase. Although these arguments may not seem to apply to subscription services, it is worth remembering that DRM is fundamentally a problem because it means that we do not have control of the technology we use to play our music, and because the firms aiming to control us are using DRM to push antifeatures, raise prices, and block innovation. In all of these senses, DRM in streaming services is exactly as bad as FairPlay, and we should continue to demand better.