My kids have been heavy into mazes lately, and have been making me draw them mazes by hand, so I wrote a web app to generate them. (Source code.)


“No One Knows” on ukulele

“No One Knows”
by Queens of the Stone Age

(I’ve got my G tuned an octave down, so maybe this will sound bad in standard tuning.)

These sorts of things, mainly:


and the rest kind of follows from that, hopefully.


Bigmouth Strikes Again for Ukulele

Bigmouth Strikes Again on uke

2210 / 2010 / 2013 / 4035
2210 / 2010 / 3211 / 0003

2000 / 0000 / … / 3211 / 0003

Sweetness, sweetness I was only joking
When I said I’d like to smash every tooth
In your head

Oh … sweetness, sweetness, I was only joking
When I said by rights you should be
Bludgeoned in your bed

And now I know how Joan of Arc felt
Now I know how Joan of Arc felt
As the flames rose to her roman nose
And her Walkman started to melt
Oh …

Bigmouth, la … bigmouth, la …
Bigmouth strikes again
And I’ve got no right to take my place
With the Human race


No Church in the Wild tab

Watch the ThroneNo Church in the Wild

The main riff is detuned a little:

e ---------------------------------|
B ---------------------------------|
D ---------------------------------|
G -----------------------------0-2-|
A ---------0-2-----3-2-0-----------|
E -0---2-3-----3-0-------3-2-0-----|
        h   h   p   p p   p p   h

And the refrain: Am / Bm / Em


DNS showdown

I resolved the “top 1000 sites” via Google’s Public DNS, and OpenDNS. Here are the results:

$ curl | grep _blank | grep -o http:[^\"]\* | grep -o //.\*/ | cut -d/ -f3 > top1000domains
$ time for i in `cat top1000domains`; do host $i > /dev/null; done
real 11m42.183s
user 0m1.481s
sys 0m2.809s
$ time for i in `cat top1000domains`; do host $i > /dev/null; done
real 14m14.926s
user 0m1.453s
sys 0m2.732s
$ time for i in `cat top1000domains`; do host $i > /dev/null; done
real 8m11.168s
user 0m1.466s
sys 0m2.780s

Google beat It seems like when I tried Google’s DNS when it was first made available, it was inferior to but that appears to no longer be the case.

But OpenDNS (which I threw in for the hell of it) beat them both. They do show ads for non-existent hosts, which works my nerves. But maybe since they’re for profit, they’re able to be quicker.

(Not that this was very scientific.)


Web-Hosting a Github Repo

If you’ve got a project on github that you’d like to web-host at (that is, it has an index.html in the project root, perhaps documenting or demonstrating the project, or which is the project), the procedure is much simpler than the procedure for setting up GitHub Pages branch with entirely separate content from the source.

Starting with a clean repo (nothing pending):

0. If you’ve already checked the “GitHub Pages” box on the project’s Admin page, get rid of the gh-pages branch that has been automatically created like so:

$ git checkout gh-pages      # pull in the gh-pages branch
$ git checkout master        # back to the master branch
$ git branch -d gh-pages     # delete the default content
$ git push origin :gh-pages  # also remove it from the server

1. Otherwise, it’s as simple as creating a branch called gh-pages:

$ git branch gh-pages        # now gh-pages is just a clone of the master
$ git push origin gh-pages   # put it up on

2+. Now each time you want to update the GitHub Pages page with new stuff in the master branch:

$ git checkout gh-pages
$ git merge master
$ git checkout master
$ git push


Minecraft Sign-Grinder Science


Design your sign-based grinder floors as 1-wide strips with 2 spaces between them. Or possibly a grid of 2×2 blocks.

Not too long; do read.

I’ve done some analysis of sign-based mob grinder design in Minecraft. The results surprised me, so I’ll give them here.

For background on the kind of thing I’m talking about, watch this video, but the basic idea is to build surfaces for mobs to spawn on with signs placed on the edges, which tricks the mobs into walking off and falling to their deaths.

In that video, the spawning surfaces are laid out as 3xL strips (where L might be 14, at a guess), with 2-wide gaps between them. What I’ve done is try to compare the efficiencies of various alternative layouts. The layouts I’m considering are 1) a grid of NxN blocks with 2m between them, and 2) arbitrarily long N-wide rows of blocks with 2m between them. For both cases, N = 1, 2, 3 and 4 are considered.


The simplifying assumptions I’ve made for this analysis are:

  1. A 2m gap is sufficient to allow mobs to fall
  2. Mobs move in each of the cardinal directions with equal likelihood
  3. Mobs can spawn on a single block (e.g. spiders don’t require a 2×2 surface)
  4. The surfaces are infinite; effects at the walls of the grinder are ignored
  5. Mob movement can be modeled as a series of independent steps in a random direction. (This is kind of a big assumption.)


Here are the calculated values of:

  • d = density: spawnable surface per unit area, affecting spawn frequency
  • T = average number of steps taken before a fall on a randomly chosen spawnable block
  • F = T/d: inefficency (T, considering density) the layout with the lowest U should drop the most mobs)
  • s = sign density: signs required per unit area
  • U = F*s: sign-usage weighted inefficiency (lower is better), for builders who want to use the least signs. These things use a lot of signs.

Layout d T F s U

1x1 11% 1 9 44% 4

1x∞ 33% 2 6 67% 4

2x2 25% 2 8 50% 4

2x∞ 50% 4 8 50% 4

3x3 36% 6 16.67 48% 8

3x∞ 60% 6.67 11.11... 40% 4.44...

4x4 44% 4.833... 10.875 44% 4.785

4x∞ 67% 10 15 33% 5


The 1x∞ layout drops the most mobs per unit space (has the lowest F value).

If the best efficiency per sign placement is paramount (placing the signs is truly tedious), all the 1x and 2x designs are tied.

Mobs tend to move in a single direction for some period of time, so the assumption that mobs move randomly from block to block probably gives an unfair disadvantage to the NxN designs. Thus, it’s not unlikely that the 2×2 design is the most efficient in practice.

The Nx∞ layouts have the additional advantage that they are easier to build.

Perhaps peaceful mobs might require only a 1-wide gap to fall, which would allow for more efficient designs.


I’ll give the calculation of the values for the 3x∞ case as an example.

Let A be the average steps before falling for the middle row, and B be the same for the edge rows. so the grinder layout looks like:

...              ...
...              ...
...              ...
...              ...

A step in each direction is equally likely, so falling will take 1 more step than a step from each neighbor. Thus:

A = 1 + 2/4 A + 2/4 B
B = 1 + 1/4 A + 2/4 B + 1/4 * 0


A = 8
B = 6

Spawning is on a B block 2/3 of the time, and an A block 1/3 of the time, so

T = (A + 2B) / 3 = 20/3

Also, the repeating pattern is: space, block, block, block, space, with two signs, so

d = 3/5 = 60%
s = 2/5 = 40%


F = T/d = 6.66...
U = F*s = 4.44...



I wanted to see something translated into everything, for some reason; the code below does it okay. You need a UTF-8-capable console like Terminal on OS X, or redirect to a file and view it in a browser. Example:

$ CLASSPATH=.:google-api-translate-java-0.8.jar java Panslate "unbelievably interesting"
sq: unbelievably interesante
ar: المثيرة للاهتمام
bg: невероятно интересно
ca: increïblement interessant
zh: 令人难以置信的有趣
zh-CN: 令人难以置信的有趣
zh-TW: 令人難以置信的有趣
hr: nevjerojatno zanimljiv
cs: neuvěřitelně zajímavé
da: utroligt interessant
nl: ongelooflijk interessant
en: unbelievably interesting
et: äärmiselt huvitav
tl: unbelievably kagiliw-giliw na
fi: uskomattoman mielenkiintoista
fr: incroyablement intéressante
gl: incrible interesante
de: unglaublich interessant
el: απίστευτα ενδιαφέρον
iw: מעניין שלא תיאמן
hi: अविश्वसनीय दिलचस्प
hu: Hihetetlenül érdekes
id: luar biasa menarik
it: incredibilmente interessante
ja: 信じられないほど面白い
ko: 엄청 재미
lv: neticami interesanti
lt: neįtikėtinai įdomūs
mt: unbelievably interessanti
no: utrolig interessant
fa: unbelievably جالب
pl: niesamowicie ciekawe
pt: incrivelmente interessante
ro: incredibil de interesant
ru: невероятной интересно
sr: невероватно занимљиво
sk: neuveriteľne zaujímavé
sl: Neverjetno zanimivo
es: increíblemente interesante
sv: Otroligt intressant
th: น่าเหลือเชื่อ
tr: inanılmaz ilginç
uk: неймовірною цікаво
vi: không ngờ thú vị

You’ll need google-api-translate-java. Here’s the Java code:


public class Panslate {
  public static void main(String[] args) throws Exception {
    PrintStream out = new PrintStream(System.out, true, "UTF-8");
    for (Language target : Language.values()) {
      if (target == Language.AUTO_DETECT) continue;
      String translatedText = Translate.execute(args[0],
      out.println(target + ": " + translatedText);


GHWT & Rock Band MIDI Filter for Drums

Mildly unsatisfied with my earlier, more obvious solution for using an electronic drum kit to play Guitar Hero World Tour (that is, just changing a few MIDI note settings), I’ve put together a solution I like better – a microcontroller which filters the MIDI signal between the drum kit sound module and the GHWT controller.

The advantages are these:

  • The hi-hat pedal serves the proper function in the game, in that the pedal, rather than velocity, distinguishes an open from closed hi-hat hit.
  • No need to mess with the MIDI settings of the drum sound module (so it’s more portable & flexible, and less invasive).
  • Cuter

The drum sound module (Roland TD-3 in my case) feeds into a MIDI IN circuit connected to an Arduino microcontroller, which adjusts the MIDI data appropriately, then sends it on to MIDI out, where the GHWT controller is connected. This “appropriate” adjustment to which I refer is just the remapping of certain MIDI note numbers so that, for example, the yellow pad can be triggered by both the edge and the bell of the hi-hat. In addition, the velocity of just hi-hat hits is replaced with a value based on the position of the hi-hat pedal. The details of the necessary mappings are evident in the code below or in yonder spreadsheet.

Three AAA batteries provide power (held together with electrical tape, with heavy oven pan foil providing the electrical connections – changing the batteries will be a bit inconvenient). I was hoping it could be powered just by drum sound module through the MIDI IN connector, but there doesn’t seem to be enough current to power the circuit and the MIDI OUT. Or very possibly, I didn’t sufficiently isolate the MIDI IN circuit from the rest of the circuit; but this goes beyond my electronics knowledge. However, I did use the MIDI IN power to toggle a relay to switch on the battery power, thus saving me the trouble of switching it on, and, worse, forgetting to switch it off. As long as it is plugged into a switched-on drum module, it’s on. You just plug it in and forget it and that works beautifully.

The Arduino clone I used is an RBBB from Modern Devices, which is small enough to fit. I power the Arduino directly on the +5V bus (albeit with only 4.5V); thus the power jack and voltage regular can be omitted and trimmed off the board. I also left a bunch of other stuff off – all that was needed were the two 0.1μF caps, the 10kΩ resistor, the resonator, the reset switch, the programming header, and the microcontroller chip (sans socket, to save room). This is connected to the other (MIDI, LED & relay) circuitry via the programming header (plus one wire to pin D3).

As is traditional with DIY electronics projects, it is housed, after some effort to miniaturize, in an Altoids tin. I did spray paint the tin orange for aesthetics. Also, it’s actually a Hershey’s Cacao Reserve tin, which is the same size, but doesn’t have “Altoids” stamped into the top, and has better tasting contents. A slightly larger container would be better, since with this one the MIDI cords have to be awkwardly plugged into the bottom of the tin.

One LED shows that the board is powered up – I used a biggish 2.2kΩ resistor to dim it. Another LED indicates when note on/off messages are received, which is helpful for troubleshooting and looks cool. The brightness is proportional to the note velocity. One could add 6 LEDs in the appropriate colors to indicate notes on each controller pad, but I didn’t.

Here is a schematic:

(the resistor I forgot to label off of D3 is 220Ω.)

And here’s the Processing sketch (why in hell are they called “sketches” rather than programs?) that makes it all happen:

// Read MIDI messages from a TD-3 drum cotroller, modify them for use with GHWT,
// and pass them thru
// Hookups:
// - MIDI in circuit on pin RX/D0 (& +5V & Gnd)
// - MIDI out circuit on pin TX/D1 (& +5V & Gnd)
// - LED on pin 13 and/or 3
// GHWT MIDI note numbers
// kick 	36  purple
// snare 	38  red
// hi-hat 	46  yellow
// hi tom 	48  blue
// ride 	49  orange
// low tom 	45  green

void setup() {
  Serial.begin(31250);  // MIDI uses this odd serial rate
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
  pinMode(3, OUTPUT);
  digitalWrite(3, LOW);

// MIDI messages received are decoded into these globals (which isn't kludgey;
// it's the right thing to do, I hereby declare)
int midiStatus = 0;           // most recent status byte
int midiMessageOffset = 999;  // offset from status byte
int midiChannel;              // channel given in status byte
int midiMessageType;          // message type given in status byte
int midiNote;                 // note number in most recent note on/off

// Hi-hat velocities are determined by the pedal being open or closed, since
// that's usually what this represents in the game (but if velocity is
// zero, leave it alone)
int SOFT = 63;   // Half strength
int HARD = 127;  // Full strength

void loop() {
  if (Serial.available()) {

    int midibyte =;


    if (midibyte >= 0x80) {
      // Status byte
      midiStatus = midibyte;
      midiMessageOffset = 0;
      midiNote = 0;
      midiMessageType = midiStatus >> 4;
      midiChannel = midiStatus & 0xF;
    else if(midiStatus == 0x99 || midiStatus == 0x89) {
      // Percussion note-on or -off

      if (midiMessageOffset & 1) {
        // Note number
        midiNote = midibyte;
        switch (midibyte) {
        case 22:  // hi-hat clsd, edge
        case 26:  // hi-hat open, edge
        case 42:  // hi-hat clsd, bow
        case 52:  // crash 2 edge
        case 57:  // crash 2 bow
          midibyte = 46;
        case 40:  // snare rim
          midibyte = 38;
        case 41:  // tom 3
          midibyte = 45;
        case 51:  // ride bow
        case 53:  // ride edge
        case 55:  // crash 1 edge
          midibyte = 49;
      else {
        // Velocity
        if (midiMessageType == 0x9 && midibyte > 0) switch (midiNote) {
        case 22:  // hi-hat clsd, edge
        case 42:  // hi-hat clsd, bow
          midibyte = SOFT;
        case 26:  // hi-hat open, edge
        case 46:  // hi-hat open, bow
          midibyte = HARD;



    // Update an LED to show notes when we see the velocity byte
    if (((midiMessageOffset & 1) == 0) &&
        (midiMessageType == 0x9 || midiMessageType == 0x8)) {
      // Light up the traditional pin D13 to show activity
      digitalWrite(13, (midibyte == 0 ||
                        midiMessageType == 0x8) ? LOW : HIGH);
      // ...and use pin D3 to indicate velocity by brightness
      analogWrite(3, (midiMessageType == 0x8) ? 0 : midibyte * 2);

I’ll mention that due to my poor soldering skills, plus the fact that I didn’t realize I had poor soldering skills, made this sucker take me a long time to put together and debug. Once I got in there with a loupe, the problem was evident. “Problems”, I should say.

Comments (2)


I’ve got this blog right here. No one reads it. No one writes it. But I do get bots posting spam, which turns into notification spam, and which I must moderate away. So I installed wp-spamfree! Here’s hoping it works.


« Previous entries