Thursday, September 17, 2020

Partscaster: T style with P-Rails

Super pleased with this guitar that I put together from custom parts a short while ago:

One of my life-long passions has been creating music. For the past decade and a half, the form that musical expression has taken is in playing the guitar. I've played most Sundays in church for the past several years and over time, I've been exploring different variations on amps, effects, and guitars to try to find the perfect balance of tones, to fit the mood of the moment in music.

Since many of the songs we play are by different groups, who each use different instruments, I've been looking for a way to have a wide variety of different sounds on tap. Ideally, this wouldn't require carting half a dozen different guitars and amps on stage each weekend. This started me looking for different styles of guitar pickups that are versatile and mimic a number of different popular configurations. When I learned about Seymour Duncan's P-Rails pickups, they sounded like a perfect solution for the kind of versatility I sought.

These pickups include a P90 pickup as well as a "rail" style coil, both in a tidy package that fits a space for most humbucker pickups. If wired to switch between the P90, the rail pickup, or both, this one pickup could do triple-duty; matching three common pickup styles. Seymour Duncan also provides a great way to handle the switching between these different modes in their Triple Shot mounting rings. These are essentially pickup rings that also include two small switches, and by flipping through different combinations, the pickups can be run as: P90-only, rail-only, both in parallel, and both in series. My mind was swimming with possibilities.

With the pickups sorted out, now the question was, what kind of platform should these pickups be put into? I've recently been enjoying Telecaster guitars, and the traditional shape and style of an early 1950s Telecaster has a timeless appeal that seemed like an inconspicious way to bring a surprising amount of versatility on stage. Rather than buy a Tele to rip it apart, I thought I could start fresh, and it seemed like building my own Tele-style guitar from parts might not be too far a stretch for me, as little woodworking experience as I had had at this point. The place many people turn for custom guitar parts Warmoth, which has a great reputation for high quality custom work. I choose a Telecaster shape routed for Humbucker pickups, made of Alder (same as the American Standard Telecaster I also have).

For the neck of the guitar, I had a couple of unique things in mind. First was the thickness of the neck. I have relatively long fingers, and the thin necks on some electric guitars tend to cause discomfort on long playing sessions. I've found thicker necks to be much more comfortable, so I decided to pick a Boatneck profile when ordering from Warmoth. The second non-traditional detail that I had in mind was to spring for stainless steel frets. I dislike the idea of the frets wearing down over the years as I play, and I wanted to build something that I'd enjoy playing for years to come. The durability of stainless frets might mean that I'll never need to refret this neck, which sounds like a win to me.

The last question was the finish. Traditionally, the early Fender guitars were finished with nitrocellulose laquer, and even today many high end instruments use this as the weatherproof coating. While in some ways inferior to modern materials, there are two aspects to this finish that I found attractive: ease of applying the finish and repairing mistakes (thanks to its ability to "burn in" to previous layers) and the way that it hardens and wears over time. The worn-in look is quite popular these days, especially on telecasters, and while I have no plans to artificially relic this guitar, I'd love to watch how the finish ages over the years. I decided to apply the finish myself, so I bought a few rattle cans of nitrocellulose laquer in butterscotch transparent and clear. I applied a few coats of clear as a sealer, then around 4 coats of butterscotch, followed by around 10 coats of clear on top. The neck of the guitar I sprayed with clear only. After waiting a couple of weeks for it to dry, I wet-sanded with a series of increasingly high grits of sandpaper. Starting from around 180 grit, I worked up slowly to 4000. It was pretty nerve-wracking at the start, seeing the shiny, but a bit orange-peel-y, finish turn dull and flat. Not until over 2000 grit did it start to shine again.

The painting all finished, it was time to put it together! For the wiring, I thought it would be cool to try a 4-way switch with positions for neck pickup only, bridge pickup only, both in parallel, and both in series (to match the multiple ways to wire each pickup). This would create a dizzying array of pickup combinations - 40, to be precise, which is probably too many, but hey, if you've got it why not! The last detail of the wiring which is somewhat unusual is the "treble bleed circuit" which consists of a capacitor + resistor on the volume potentiometer. It allows some of the high frequencies to continue to "bleed" through the volume control as it is turned down. The effect is that as the volume is turned down, the sound gets "thinner" and more bright, rather than darker and more muddy which would naturally happen on a volume pot without this added detail. I've loved this feature of my American Standard Telecaster, so I decided to duplicate it here.

Over the course of a few months, I worked on this over the weekends and vacations and finally wrapped it all up around Christmas time. Without further ado, the pictures:

Here are the specs at a glance:

Sunday, August 23, 2020


I've had a longstanding interest in cryptography and recently dove into a set of exercises that teach basic concepts of cryptanalysis. I highly recommend it if you are looking to learn more about cryptography: Cryptopals.

Early Telecasters A Visual History

Along with software development, my other passion is for making music. There have been a few instruments I've specialized in over the years, but my far and away favorite at the moment is electric guitar, specifically a Fender Telecaster. For the past couple of years, I've been playing a 2015 American Standard. Here are a few pictures:

One of the things that amazes me about this instrument is the classic design which has undergone very few changes since this instrument was first introduced in 1950. As one of the very first mass produced electric guitars, the Telecaster continues to influence modern music as well as the design of electric guitars. Most electric guitar makers sell a "T" style guitar in their lineup.

Lets look back at a brief visual history of the first decade of the Telecaster family of guitars.


Beginning in 1950, the Fender Electric Instrument Manufacturing Company began selling a couple of styles of electric guitar. First, the single pickup Esquire, followed shortly by the two pickup Broadcaster.


One of the surprising details to me about this guitar, is the presence of a three-way selector switch. In most electric guitars, the selector switch activates different combinations of the pickups in the guitar. Most single pickup guitars omit a selector switch (see for example, the Gibson Les Paul Junior). So what is a selector switch doing on a single pickup guitar?

In the wiring for an Esquire, the middle position matches what most would consider a normal setup for a single pickup guitar with two knobs. In this position, the volume and tone knobs control the output from the pickups. When the switch is up towards the neck of the guitar, an additional capacitor is in the output chain in place of the tone knob. This cuts out many of the high frequencies in the output and produces a somewhat muddy sound more reminiscent of a bass guitar. This video has a great demonstration of the Esquire tones. A demonstration of the tones begins around 3:27 in the video. This circuit position in particular is not typically found on a modern electric guitar, pretty unique! The final position, down towards the bridge is a circuit that bypasses the tone control entirely and is the least filtered of the circuit options. Only the volume control is changing the output, so you get the widest possible set of frequencies. There are a few guitars out there today that dispense with a tone control. One example is the Jim Root Telecaster, however it is a very different beast than the 1950 Fender Esquire.

And now for the look:

While the single pickup guitar was the first to be widely available, from the beginning, Fender had planned to produce a two pickup guitar. In fact, these early Esquire guitars reportedly had a cutout for the neck pickup ready to go but hidden away under the pickguard. And that brings us to the next guitar available in 1950: the Broadcaster.

With it's two pickups mounted on a solid ash body, this is very recognizably the first example of what is today the Telecaster. Originally named the Broadcaster, it would soon have to be renamed due to a trademark dispute. Few guitars carry the Broadcaster name.

While the Broadcaster has the recognizable two pickup configuration, two knobs, and a three way selector, the wiring is very different from what would later become what is now considered normal Telecaster wiring. In these early models, the three selector switch toggled between the following settings. (Note, more details on this original Broadcaster wiring can be found here.) Here's what the different positions in a Broadcaster switch do:

The position with the switch down towards the bridge includes the output of the bridge pickup, with no tone adjustment similar to this setting in the Esquire. However, rather than ignore the tone know, in this position, the "tone" knob is a "blend" control which adds in the output from the neck pickup. Turned one way, the neck pickup is all the way in, the other way it's all the way out. Next, the middle position includes the full output of only the neck pickup (no tone modification). The final position, up towards the neck, includes only the neck pickup with a capacitor that filters out the high frequencies. I found it fascinating that in the original Broadcaster wiring, there's no variable tone control, just pickup selection with one option being a fixed tone cut. The closest-to-bridge switch position is most similar to the middle position in modern Telecasters. Although, in a modern telecaster, there's a constant balance of output between the picksups when both are active.

A good example of the tones that come from this wiring can be found in this video. Although this isn't an original Broadcaster, it demonstrates the different behaviors of this pickup switch. Here's another example. For a video showcasing an actual 1950 Broadcaster, check out this video from Norman's Rare Guitars.


Over the course of 1951, the Broadcaster would be renamed to the Telecaster. Aside from the name change, the guitars' design was essentially unchanged.

In early 1951, Fender continued making Broadcaster guitars. However, the Gretsch company notified Fender that the Broadcaster name on their guitar conflicted with their trademarked Gretsch Broadkaster drum set. It doesn't sound like the two companies went to court over the name. I wonder how it would have gone had Fender decided not to change the name. Gretsch also produced electric guitars at the time, and continues to make and sell them today. In 1951, none of the Gretsch guitars were named Broadcaster, though they do today sell a Broadkaster Guitar.


Following the notice from Gretsch guitars, Fender began producing their formerly-known-as-Broadcaster guitars with no model name on the decal. The headstock of the guitar was labelled only with the name Fender, hence guitars produced in their period are dubbed "Nocaster" guitars. Aside from the name change on the headstock, the Nocaster is visually similar to the Broadcaster that came before it. The body is painted a translucent Butterscotch Blond with a single-ply black pickguard:

These Nocaster guitars are quite rare as they were produced for only a partial year. By year's end, these guitars bore their new and final name.


In late 1951, the guitar received the name that it is known by today: the Telecaster. Other than the new name on the headstock, these guitars were identical to those produced earlier in the year.

While these guitars now bear their modern name, the wiring of the pickups is significantly different than what they carry today. Modern style pickup wiring was introduced in the late 1952.


Fender continued to produce Esquires as well in 1951. In addition to the "Butterscotch Blond" color, the Esquire was also available in a "Blond" color which was a translucent white. The finish on these guitars tend to yellow significantly as they age, so most old guitars have a noticable yellow tint to them. Here are a few pictures:

Few other instruments have been in continuous manufacture as the humble Telecaster and it still plays a major role in modern music. Here's to the next 70 years.

Friday, June 22, 2018

Developing in GitHub using Cloud Shell

If you're not familiar with Google Cloud Shell, it's a great tool for doing command line development in a Linux environment. I've been using it as an always-on development environment for web focused projects. Whichever machine I happen to be using, my dev environment is always available.

One of the ways I'm using Cloud Shell is as a development environment for my open source projects. Cloud Shell comes with loads of developer tools pre-installed, including git which is quite handy if you are hosting projects on Github. Head over to to start using Cloud Shell.

Here's how you can set up your own open source development environment with Github in Cloud Shell, in three easy steps!

Set up your git environment

First, you'll need to have the git client available. Easy, git is already installed (yay!)

Next, set up your git environment with the email address and name that your changes will be published under:

git config --global "YOUR NAME"
git config --global "YOUR EMAIL ADDRESS"

If you are using two factor auth for your GitHub account, you'll need to generate an access token. Once created, you'll use the hexidecimal string instead of your GitHub account password. For example, the generate password might look something like


Clone a repo from GitHub to Cloud Shell

With command line credentials in hand, you can now clone the repository from GitHub into your Cloud Shell environment to start making changes. Step three!

For example:

git clone

Now the files are available in your local Cloud Shell environment and you can change them to your heart's content. There is a simple text editor available in Cloud Shell which you can launch from the command line with a command like

cd jsBytes

Commit and publish your changes

After editing a file or two, commit your changes to your local repository and then publish them on GitHub. Remember that when prompted for the password, use the access token you generated earlier instead of your GitHub password.

git status
git commit -a -m 'Add one usage example to README.'
git push origin master

There you have it, an easy way to work on your GitHub project using Google Cloud Shell as your development environment.

Friday, February 24, 2017

Arduino Programming in ChromeOS

Are you ready to turn your Chromebook into a lean mean Arduino programming machine? No? Maybe? Great!

I've recently gotten into microcontroller programming, chasing dreams of electric guitar fueled audio bliss. Several microcontrollers have played the role of distortion effects prototype, and I haven't settled on one yet, but I can say the easiest I've found to use so far are the ones produced by Arduino. In fact, you can set up a Chromebook as development environment for programming an Arduino.

Here are the steps you'll need complete this amazing Chromebook transformation. Note that there are some risks in tweaking the setup of your machine.

First you'll need to enter developer mode, hold down escape and refresh while pressing the power button. Then on the warning boot screen, press ctrl+d.

Then, install Crouton. Here's a helpful download link:

Then run Crouton setup by entering the terminal, which is done by hitting ctrl+alt+t then run shell (type shell followed by enter). I ran my setup like this: sudo sh ~/Downloads/crouton -r trusty -t xfce.

To run once installed, use sudo startxfce4

From time to time, as Chrome OS is updated, it may be necessary to update the Crouton installation. I've updated by running sudo sh ~/Downloads/crouton -r trusty -t xfce -u

Now its time to get the development environment for Arduino. There are some helpful instructions here:

I've set up a couple of Chromebooks with the Arduino dev environment and as time has gone on, the approach has changed a bit. In my first setup, I did the following to install it:
sudo apt-get update && sudo apt-get install arduino arduino-core 
I then tried running arduino as root (sudo ./arduino ), but had the following error:

error while loading shared libraries: cannot open shared object file: No such file or directory

Ah, there was a missing dependency, which I was able to install as follows:

sudo apt-get install libncurses5-dev

In a later version of Arduino's software, I got the following after downloading the Arduino IDE and running sudo ./install then sudo ./arduino:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/.../arduino-1.6.13/java/lib/i386/ cannot open shared object file: No such file or directory

I resolved a sequence of errors by installing the following
sudo apt-get install libX11-6:i386
sudo apt install libxext6:i386
sudo apt-get install libxrender1:i386
sudo apt-get install libXtst6:i386
sudo apt-get install libXi6:i386
sudo apt-get install libstdc++6:i386

I also edited the audino file, which is an executable script, and removed the reference to GTKLookAndFeel. This allowed me to run the Arduino IDE without having to replace my installation of Java.

From there I've been able to compile programs and upload them to the Arduino to my hearts content. Happy coding!

Wednesday, July 22, 2015

Teaching Kids to Program - Part 1

This summer, I've been teaching my two oldest kids to program. They're ages sever and four and a half so I'm tailoring our lessons to what I imagine they can grasp in what can be a very abstract field of study. I've been super impressed with what they've learned so far!

The first challenge was thinking how to make programming interesting and compelling. Something too abstract feels like it would be challenging, there needs to be immediate feedback. Type this in, see what changes on the screen. How about we set out to make a game? That was one of the first pursuits that got me into programming in my teenage years.

The second consideration was balancing simplicity and ease of use. When programming, I always felt more confident when I could understand at a pretty low level what was going on. For this reason I wanted to make sure they gained an understanding of the fundamentals. We'd start with a view of a computer as a very simple machine. Even if this means there is some extra coding needed to get the desired effect on the screen. It's better (IMHO) to add abstractions later once they have an underlying understanding than to try to understand a powerful but complicated library that initially gets quick results.

I'm planning to post what we covered each week. We spend 30-60 minutes in a once a week session though some weeks we're taking off. It is summer after all!

Here's what we covered in our first lesson.

1. You can tell a computer what to do!

We opened up the terminal and I told them to type

print "Hello [name]"

Here it is, immediate feedback with the simplest possible "program." To get this working, I added a bash alias print=echo. Seems like print is a more common name across programming languages for "write something to stdout."

This went over pretty well, both kids typed some things.

Time to introduce some programming concepts. I explained that this was calling a function named print. The print function writes out whatever you tell it to write. I hope purist will forgive my painting with a broad brush.

Next I explained that the words that you give to the function to put on the screen are an argument, er, well, a parameter. The looks on their faces when I called these arguments made it pretty clear that they were thinking of what transpires out in the sandbox.

So here we'd covered the main ideas I wanted to teach them in the first lesson. You can tell a computer what to do! The "what to do" is specified using a function and the parameters that you pass to the function to tell it what or how you want things done.

Time for more fun.

Our four and a half year old can read basic words, but I imagined typing and reading might get tedious pretty fast. So next we turned to something just as simple that doesn't require reading from the screen, and not surprisingly was quite a bit of fun: the Mac say program.

If you've never played with this, in the Mac terminal there is command "say" which works like echo except it speaks whatever you give it in a computerized voice. We started with

say "Hello [name]"

Great fun! From there I asked them what parameters we should give the say function next. This filled the rest of our time. By far the biggest hit was say "[Baby's name] are you pooping?"

Yup, teaching kids to program.

Wednesday, May 15, 2013

Easy Raspberry Pi Setup (Using Windows)

So there I was, new Raspberry Pi in hand. Now to set it up. One small setback, I don't exactly have a monitor, keyboard, and mouse handy. How did I end up with so many laptops?

Turns out setting it up and getting to a command line was a breeze, no monitor (etc.) required. All it took was an Ethernet cable and my router.

Here's what I did.

First, I wrote the operating system disk image to an SD card using the instructions on the Raspberry Pi Quick Start Guide.
  • Downloaded the latest image from
  • Extracted it and found the .img file
  • Installed Win 32 Disk Imager
  • Plugged in the SD card
  • Used the disk imager to write the .img file to the drive for the SD card
Second, I started up the Raspberry Pi to connect to it.

I plugged the Raspberry Pi into the router using that Ethernet cable, then powered it up!

The next step will depend on your router but some routers will show you a list of the devices that are connected to the network from the admin screen. Here's an example

Armed with the IP address, you can ssh into the Raspberry Pi machine. (I used PuTTY.)

There you have it. From the command line you can configure whatever else is needed and you'll never have to scrounge up one of those pesky keyboards.

Thursday, July 19, 2012

waitFor JavaScript

In the spirit of building the simplest thing that could possibly work, I revisit the concept in another of my posts: simple asynchronous JavaScript.

Time and time again I see web developers relying on the order that JavaScript loads in a page to ensure that the site will work. This keeps the mental model simple, "all the stuff above this code will be available here", but it means that people trying to speed up browsers and JavaScript interpreters have their hands tied. Why not instead load and execute as much JavaScript in parallel as possible, like a mutlithreaded application, and wait for your dependencies to load or preconditions to be met before your code runs.

You could do it all in just a few lines:

function waitFor(condition, callback) {
  function waiter(condition, callback) {
    return function() {
      var condMet = false;
      try {
        condMet = condition();
      } catch (e) {}

      if (condMet) {
      } else {
        setTimeout(waiter(condition, callback), 5);

  waiter(condition, callback)();

Using it looks a bit like this

  // condition
  function() {return window.dependency;},
  // callback
  function() {
    // do things using dependency.

For example, here's how you might set this up to check if jQuery has been loaded and that a particular element on the page has been loaded in the DOM.

waitFor(function() {return $('#msgid');}, function() {
    $('#msgid').html('jQuery says "hi"!');

Now it doesn't matter what order your script tags are in. Of course, you'll get the best performance if jQuery gets loaded before this waitFor call is made. The wait and retry loop adds some cost. If browsers had an event model available for script loading or conditions then we wouldn't have to poll using setTimeout/Interval. But for existing browsers all the way back to IE 6, this simple helper function will work.

For managing JavaScript dependencies there's also require.js which does quite a bit more (and is larger). I wrote this to be lighter weight and it is more general and flexible than a framework like require.js. Using waitFor, you could set up logic that is triggered if and when certain arbitrary conditions become true.

One little improvement, if you are waiting for lots of things then you would probably want to replace multiple timers with a single timer that will check all conditions. Like this:

function waitFor(condition, callback) {
  waitFor.waitingFor.push([condition, callback]);

waitFor.waitingFor = [];

waitFor.check = function() {
  var stillWaitingFor = [];
  for (var i = 0; i < waitFor.waitingFor.length; i++) {
    var condMet = false;
    try {
      condMet = waitFor.waitingFor[i][0]();
    } catch (e) {}
    if (condMet) {
    } else {

  waitFor.waitingFor = stillWaitingFor;
  if (stillWaitingFor.length > 0) {
    setTimeout(waitFor.check, 5);

Here's a minified version. I added some newlines for formatting which you can take out.

function w(c,b){w.w.push([c,b]);w.c()}
w.w=[];w.c=function(){for(var s=[],b=0;b<w.w.length;b++)
{var d=!1;try{d=w.w[b][0]()}catch(e){}
if(d)w.w[b][1]();else s.push(w.w[b])}w.w=s;0<s.length
&&setTimeout(w.c,5)};var waitFor=w;

Happy coding!