In an earlier post I mentioned that I’d used a tube of silicone to put a drop of silicone on each solenoid, to reduce the loud ‘clank’ when the solenoid strikes the chime. I found out that a drop of silicone is way too much: the chimes hardly sounded at all.
I then found these fabulous 21-gauge glue syringes on Amazon. They’re perfect for painting just the right amount of silicone on the tip of the solenoid. They’re easy to use: pop the syringe open, squeeze a little (very little) silicone out of the tube into the syringe, touch the tip of the syringe ‘needle’ (really a thin metal tube) to the solenoid tip, then gently squeeze the syringe plunger as you paint the silicone onto the solenoid tip.
The photo below shows the result: a pad of silicone that’s about 1/2 the thickness of the drop shown above. I still have to experiment / adjust a bit: I thought I painted all the solenoids with about the same amount of silicone, but the chimes sound very different from each other. I suspect that I just have to be more careful about painting exactly the same amount of silicone on each solenoid.
Since my last post about the glockenspiel, I’ve been taking a vacation from my vacation (aka working). Today I turned back to the glockenspiel and wired up the first of the 5 lighted switches.
The hardware is lighted buttons from Sparkfun in various colors, some 4-wire phone cable I bought years ago, and 4-conductor 0.1″ connectors. The heat-shrink tubing keeps the 5 pins of the button from shorting to each other. Two wires run the LED, and the other three make up the button (common, normally open, and the unused normally closed).
I had a little trouble reading the switch: whatever I did, the output was close to ground. After much experimentation, I realized that the pin I was using (pin 52) is used on the Arduino Mega 2560 for part of the SPI bus. Once I moved the input to an unused pin, it worked like a charm, with the internal pull-up resistor to keep the parts count nicely low.
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.
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.
The Design Thinking steps we use at work are labeled a little differently from the picture:
A brief history of the project
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.
In the deep past I was charmed by music boxes and by The Mighty Wurlitzer at The Organ Grinder pizza in Portland Oregon.
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.
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.
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.
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.
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.
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.
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.
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.
In my next post I reflect on how Design Thinking could have improved the project.
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.
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.
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.
Et proiectus est talpa – "and the mole was cast out"