All posts by bneedhamia

Collaboration is not Part of Making; it’s the Heart of Making

This post is about what I’ve learned about Making through the Robotic Glockenspiel project.

Even at the beginning of the project, I was “standing on the shoulders of giants“:

As I learned things, I’d document them for others:

  • I blogged at major points in the project. I could have blogged more frequently.
  • I tweeted synopses of the blog entries, to point to the blog
  • I made YouTube videos from the very start, of the little soldering projects I built to relearn how to solder
  •  Once the software was (mostly) working, I put as much as I could think of on GitHub:
    • my Glockenspiel Arduino sketch
    • my Midi file reading library
    • my SD-card simple persistent settings library
    • The circuit diagram, in Fritzing format
    • the Bill of Materials (parts list)
    • the public domain MIDI files of the Christmas carols, as well as the Aria Maestosa source files for the carols.

Sharing shaped my thinking and the structure of the project:

  • Blogging made me imagine what someone like me would like to know about robotic instruments and glockenspiel construction.
  • Making YouTube videos made me think about how the project demos well or badly, and pulled me out of the technical bits into the user experience.  Trying to make a video of the glockenspiel playing showed me how unacceptably loud it was.
  • Tweeting made me think about how to get the word out about what I’d done so far, and what media to use to connect with like-minded people.
  • Open-sourcing the project on GitHub seriously changed how I organized the software (I created the libraries and examples of how to use them), and stretched my ideas of what a Git repo was for (e.g., Bill of Materials). It made me think of reusability of the code.

Sharing sends many messages

At work, Jessica and I discussed what Sharing Making says, and came up with these ideas:

  • The foreground message: “how to do what I did”. You’re giving people a recipe, that’s hopefully complete enough to be useful.
  • It’s a resource list: “Here are links to the sources I used to get where I am with this project”. It lets people find more detail and the people who created those details.
  • “I appreciate the work people put into the resources I used” – making a resource list gives kudos back to the authors.
  • “How I got here”. It’s a journal, showing your process of creation. Not just the recipe, but a guide to how to be a chef who creates recipes.  This is the big reason you want to share your project as you go rather than when it’s “finished”.
  • It shows authority: “Now I know how to do this.” “I’ve got chops”
  • Advertising that you’re a resource: “I’ve shared this much; ask me questions about problems you run into”
  • An advertisement for collaboration: “These are areas I’m interested in” “Contact me if you want to work together in an area”
  • Most importantly: if you only share the demo – what you did – you’re only saying “look at how great I am and you can’t be”; if you share how to duplicate the project, you’re saying “I’m nurturing the community”. I’ve seen how when people only post a photo or demo, the first comment on it is “So, where’s the source?”

So far, I’ve only written; I haven’t actually participated in a community

  • I’ve blogged, tweeted, youtubed, and githubbed, but I haven’t heard from anyone who’s used this info, and I haven’t offered changes to anyone else’s Open Source project – yet.
  • Everything I’ve said about “sharing” is just speculation at this point. I look forward to actually collaborating (in some way) with other people who are into music technology.
  • I need to “advertise” the project so people can find it. Once it’s more complete, I can put it up on the Arduino Blog, Sparkfun’s site, etc. I can also do more exercises to make the libraries I’ve created more useful.
  • Life is all about creating long-term, mutually-beneficial relationships. Linda says writing isn’t about one fantastic book; it’s about continually writing  wonderful new books for your growing audience. In the same way, Making isn’t about one cool project; it’s about building relationships to Make stuff that’s so much more wonderful than you can make alone.


Design Thinking via the Robotic Glockenspiel Project

Now that the glockenspiel is working and in a case, this post is about what I’ve learned about Design Thinking through my Robotic Glockenspiel project.

Caveat: since I didn’t apply formal Design Thinking to the project, I’m going to be shamelessly revisionistic in order to talk about how the project would have been better via Design Thinking.

Design Thinking process (Stanford)
Design Thinking process (Stanford)

The Design Thinking steps we use at work are labeled a little differently from the picture:

  • Gain Empathy
  • Develop Insights
  • Ideate
  • Get Feedback
  • Prototype
  • Test

A brief history of the project

  1. I was a music nerd as a toddler, then a band geek in late grade school and early Jr. High; then a vocalist from late Jr. High through adulthood. I love music.
  2. In the deep past I was charmed by music boxes and by The Mighty Wurlitzer at The Organ Grinder pizza in Portland Oregon.
  3. In 2003 I wrote a project note something like “make a circuit to play a toy xylophone”. And there it sat for years, awaiting something to help break through the inertia. I’d used Pic chips, but they were time consuming to use. I’d fiddled a little with Arduino, but hadn’t devoted any serious time to it.
  4. In 2014 I spent some mad money on an Arduino Starter Kit, and had a grand time going through the exercises in it.
    • During this time I started to post YouTube videos of the projects. This was the beginning of my blogging about projects.

      My first YouTube Project video
      My first YouTube Project video
  5. As my Intel Sabbatical (8 weeks of vacation) started looming, I decided I wanted to build a Robotic Glockenspiel with part of that time. I started learning circuits I needed, and how to tune chimes.
  6. I spent the last few weeks of my Sabbatical feverishly working on the project; then spent much of my Christmas vacation getting it to a point where it would work. I blogged the project as I went, and put the project code, music, and materials list under GitHub.
  7. There’s plenty left to do, but enough is done to talk about it. You can see and hear the chimes.

The project though the lens of Design Thinking

  • Gain Empathy: I wanted to build it for myself. I thought I knew what I wanted, but I didn’t really examine it any more than any hobbyist. Also, only later did I realize that there were a couple more audiences: 1) my wife, family, and friends, 2) other Makers and musicians, and 3) my co-workers. I only talked with my wife about what we might do with it after it (the first version) was playing music.
  • Develop Insights: Early on I did actually spend time thinking about what music I wanted to play: Public Domain Christmas Carols, mostly from the Oxford Book of Carols. Looking at specific carols led me to design a chromatic scale with a large (1.5 octave) range, rather than the 8-note Major-scale many hobbyists have built. I also knew I wanted to play MIDI files that I could create with an open source MIDI editor. Originally I wanted to play playlists and Midi files from the net, but later realized that playing them locally (from an SD card) fit better into the model of setting it up somewhere and having it play.
  • Ideate:  I didn’t spend much time ideating: creating alternative physical designs and interactions beyond the single design I could think of: a thing that looked like a xylophone in a box, with an Arduino playing it from a playlist and MIDI files on an SD card.
  • Prototype, Test: Here’s where most engineers want to start the process: Skip the understanding and alternatives, and jump straight into building stuff. In retrospect,this is the bulk of the work I did – so it’s clear I fell into the trap of the engineer’s approach rather than the designer’s approach.
    • I tried out several types of chimes cut from different metals, and settled on 1/2″ conduit.
    • I tried out a couple ways of cutting the chimes to length and tuning them, settling on a pipe-cutter, rough metal file, and my ukulele tuner – this worked great. My first narrative blog was about cutting and tuning chimes.
    • I built a few test chime mountings, to see if the chimes would ring properly. I tried 2 ways of mounting the set of chimes, because my first attempt failed miserably.
    • I experimented a bit in mounting the solenoids, mainly because I’d just bought a router and didn’t really know how to use it yet.
    • I made a test circuit before too long, to make sure the power supply would ring all the chimes at a usable volume.
    • The software development went pretty smoothly, because I’m a software engineer by training.  …although I did get thrown a bit by Arduino interfacing (I forgot to write a blog entry on that). …and I changed the design a few times once I started thinking about making the project Open Source.
    • I waited until the mounting and circuit were done before I designed (or even thought much about) the box the whole thing would go into. As a result, the box is huge and unwieldy.
  • Get Feedback: Once the glockenspiel played tunes, I showed it off to Linda and we talked about how we might use it. This would have been a great conversation to have before I started – doh! We now think the best use would be 1) as a doorbell that plays tunes appropriate to the time of year, or 2) as a quiet music box that plays in the background at Christmas parties.  We also learned a few things from this first prototype:
    • It’s huge. I need to build a totally different, more compact frame. It’s bigger than a card table, and certainly can’t be discreetly tucked away as a doorbell.
    • It’s loud; perhaps literally deafening. I’ve experimented a bit with dampening the clanking, and have more experiments to do.
    • There’s no way to control it. After it started playing, I realised it needed at least Pause, Stop, and Skip buttons.
    • I generally like how it turned out: The circuit works, it sounds pretty good and is nicely in tune, it’s easy to make MIDI files for it to play, and easy to edit the playlist.

So even though the project was mostly for my own enjoyment – a situation where you’d be tempted to skip parts of Design Thinking, I could have made a much better first working prototype by  formally following the process: Gaining Empathy (looking into our lives and music); Developing Insights (analyzing how such a music box might fit into our lives and our house);  Ideating (coming up with multiple designs for a music box / doorbell)); prototyping and Getting Feedback through low-fidelity prototypes that would let us pretend we’re using it.

I’m sold on Design Thinking. I’ll be using it in the next project (or iteration of this one).

Next I start putting the control buttons into the circuit.

It’s all in the box (except the buttons)

In my previous post, I started putting the glockenspiel case together. Now I’ve bolted the glockenspiel harp and circuit boards into the base of the box, and temporarily mounted the handles and buttons. I still need to wire up the buttons.

assembled glockenspiel
assembled glockenspiel

In other news, I’ve tried out various ways of damping the initial, loud “clank” when a solenoid strikes a chime.  A piece of scotch tape on the top of the solenoid had no effect at all; a dab of silicone (which someone else suggested) can make just the right sound, but I’m a little puzzled about how to repeatably put just the right amount of silicone on each solenoid.

A daub of silicone on a solenoid. The silicone is about 2x as deep as it needs to be.
A daub of silicone on a solenoid. The silicone is about 2x as deep as it needs to be.

In my next post I reflect on how Design Thinking could have improved the project.

Gluing the Glockenspiel box

Now that the glockenspiel plays a number of Christmas carols, it’s time to put it in a box.

After a pile of routing I’m now nailing and gluing the Robotic Glockenspiel box together.  Since this is a first prototype (the flat chime harp is too large to be practical), I’ve made the box sides from 3/4″ x 6″ “white wood” (fir or pine) instead of hardwoods, and made no attempt to conceal the nails.

Gluing and nailing the glockenspiel box
Gluing and nailing the glockenspiel box

The base and top of the box are 1/2″ plywood with a nice veneer; the sides are fir/pine. The base is held in place by 1/2″ wide and 3/8″ deep dado joints in each side; the ends are connected via rabbet joints (which you can see in the photo). I’ve routed holes in the front for the 5 buttons that will control the glockenspiel, and scroll-sawn holes in the back to plug in power and usb cables.  I also used a flush trim router bit to make all the sides the same height (for some reason one of the boards I bought was about 1/16″ wider than the other).

I’d hoped to plug/unplug the SD card from the back, but found the thickness of the box walls would require a huge hole to get to the SD card. So instead I cut a small hole, then decided to plug/unplug the SD card from the inside.

I plan to connect the lid via a 30″ cabinet hinge from Lowes. I’ve routed out an indentation in the back of the box so the hinge will be flush with the top of the box.

Since this weekend is the end of my end-of-year vacation, progress on the glockenspiel will likely be a lot slower from now on.

The next step is to drill all the mounting holes, put a clear finish on the box, then mount the chimes and circuit inside the box. I plan to figure out the lid later.

Robotic Glockenspiel now plays 17 Carols

In my previous post, the robotic glockenspiel played its first tune. This post is an update on transcribing more tunes.

I’ve been busily transcribing public domain Christmas carols from “The Oxford Book of Carols” and other sources of public domain carols, so the glockenspiel has more material to play. All the carols are checked into the SD folder of the Robotic Glockenspiel Git repository, and are part of that open source project.

In other news, I bought this edge guide for my router, so now I can cut the grooves that will hold the base of the glockenspiel.  Next I need to learn how to make rabbet joints, so I can put the glockenspiel box together.

My next post is about crafting the cabinet for the glockenspiel.

A router is a most wonderful power tool

In my previous post I pointed to my Open Source code for the project. In this post, I describe the mounting of the solenoids to the frame.

The conundrum of the project has been how to mount the solenoids to the glockenspiel. If I were a metalworker, I’d probably tap the solenoid holes and fasten them with 2mm screws into a metal strip. My 2017 future self says to design a 3D printable holder. Not knowing how to tap such tiny holes and not (yet) knowing how to design 3d printed parts, I’ve been thinking and thinking about how to mount the solenoids to wood.

One day I was wondering out loud how to fasten the solenoids, and Linda said “Why don’t you just buy a router? They’re perfect for that sort of thing.”  So I did.

I bought a Dewalt DWP611PK compact router set and a starter kit of router bits so I could route channels in a bar of wood, then mount those solenoids into those channels. I originally picked the DWP611 because it fits in a CNC router I have my eye on (but no money for yet).

My first attempt with a router was pretty sad. I had imagined that since I knew the basics I’d be fine. A few unintentionally-diagonal cuts later, I realized that making the solenoid channel cuts freehand wouldn’t work: I’d need a jig to let the router cut exactly the width channel I needed.

So using the router and a makeshift fence, I made a little height-adjustable jig.  The first attempt at the jig turned out badly, but I’m happy with the second try:

Top of router jig for cutting channels
Router jig for cutting channels (top)
jig (bottom)
jig (bottom)

If I were to make jig revision 3, I’d change a few things:

  1. use wider wood to give the router more base to glide on
  2. make the gap large enough so I can clamp the wood to be worked to the jig.
  3. use a plunge router so that the ends of the jig are solid rather than open. Doing that will make the end less likely to warp and bend apart over time.

At any rate, I made a test slot using this jig, and it turned out great!

a solenoid pressed into a routed channel
a solenoid pressed into a routed channel

Now I’ve marked the real solenoid bar, and am ready to route the 19 solenoid slots.

marking the solenoid bar
marking the solenoid bar

In my next post, I describe the last steps to a functional robotic glockenspiel.

Robotic Glockenspiel and Arduino Midi File Reader library on GitHub

In my previous post I pointed to some sources of information about how to read Midi music files. I’ve now Open Sourced my working code.

I’m a total newbie at Git, but even so I’ve managed to create repositories for the Robotic Glockenspiel and the Arduino Midi File Reader library it uses.  See My GitHub  repositories for the current state of things.

The repos are far from ready for prime time, but they have the essentials for this project-in-progress:

  • The Arduino Midi File Reader library I wrote to deliver Midi events from the file in sequence. I’m hoping others will find this library useful. It currently has no documentation at all, other than the comments in the code.
  • The Fritzing circuit diagram for the glockenspiel controller so far (no physical user interface)
  • A Bill of Materials (parts list) for the electronics and a few other things. I still need to add the wood and work out e.g., the number of conduit pipes I needed to build the 19 chimes.
  • The Robotic Glockenspiel Arduino program, as-is. It currently will play a hard-coded list of Midi files that reside on the MicroSD card, with what seems to be the correct timing (although I know it will end each song abruptly).  There’s much left to add, such as using a network card to read the playlist and the Midi files from the net, and code to control the player using a set of pushbuttons.

As an added benefit, all this is now under a real revision control system rather than being backed up nightly to my USB fob.

In my next post, I show how I mounted the solenoids to the frame.

Party On!

Successfully reading a Midi file

In my previous post I covered the Arduino-based circuit I built to strike the chimes. I’ve also, with a little effort, gotten the Sparkfun MicroSD shield to work with the Arduino Mega 2560, so I’m now in the thick of writing the software to read music files for the Robotic Glockenspiel.

Not happy with the Arduino Midi libraries I’ve seen (they seem not very file-oriented), I’ve written the bones of what will become a Midi file-reading library. This library will enable an Arduino Sketch to read events from a Midi file, one by one, so that it can play the notes with the proper timing.

The trick of reading the Midi file was the “running status”, which omits midi channel bytes when they’re repeated.

Here are some useful pages for understanding Midi file format:

My next post points to the code I wrote to read Midi files.

DIY Glockenspiel: the circuit

Earlier, I described how to build a frame for the glockenspiel. In this post, I cover the circuit that will strike each chime.

I’ve successfully tested the glockenspiel control circuit. It’s an Arduino Mega 2560, a Sparkfun Wifi Shield,  and 19 repetitions of a simple solenoid control circuit.

Glockenspiel control circuit
Glockenspiel control circuit

(by the way, the solenoids in the photo are there only for testing. In the finished Glockenspiel, there will be long wires connecting the circuit to the glockenspiel-mounted solenoids.)

I started from a drum control circuit described in Make Magazine.

Tactile Metronome Solenoid Circuit from Make Magazine
Tactile Metronome Solenoid Circuit from Make Magazine

Then I chose a few specifics: at TIP120 transistor, a 1000uF capacitor, a 1N4004 diode, and a 5V solenoid from Sparkfun. …and did 19 iterations of the circuit; one per chime in the glockenspiel.

I’ve done a quick Fritzing circuit diagram, which I plan to upload to GitHub.

My main concern was whether the solenoids could be powered only by the VIn pin on the Arduino when powered via a 9V 650mA wall power supply. Turns out the answer seems to be “Yes”: the 1000uF capacitor prevents the solenoid from drawing down the main power enough to reset the Arduino, and the power consumption of the solenoids (see below) is easily supported by the power supply.

To avoid burning out the solenoids each one is powered only a few milliseconds at a time.  This causes the solenoid to hit the chime with just enough power to ring nicely, but not too loudly. The math’s pretty straightforward: the data sheet provides the maximum average wattage that the solenoid can dissipate and the minimum resistance of the solenoid. The power supply puts out about 9V. Working out the numbers, it looks like for quickly-paced music, a 6ms-per-strike is about the maximum the solenoid should support (conservatively). Playing most music, this shouldn’t be anywhere near the maximum power the solenoid can support.

You can see a video of the test of this circuit, showing that it can powerup, power down, and run through each of the solenoids.

Next, I write the code to read the music.