Archive for Busywork


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.)


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.)


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.


Real(ish) Drums for Guitar Hero World Tour

I jumped through a lot of hoops to try to use my Roland V-Drums in place of the Rock Band drum controller, with unsatisfying results. Guitar Hero World Tour makes it awfully easy though – the controller has a MIDI IN port. If you plug it, it will play, but it can also be easily be improved upon. In a nutshell, I mapped other pads so they could also be used, and, more importantly, mapped both the rim and head of each pad so you don’t have to hit a particular part to trigger.

I assigned the pads as illustrated here:

The perhaps controversial and/or innovative idea was to reverse the crash cymbals from the more obvious left-right configuration. I did this because orange is used for crashes when the right hand is on the hi-hat, and yellow is when the right hand is riding the ride, and in real life, you’d use the crash closest to hand. I’m trying to get as close to playing the actual drum part as possible here.

Whether to assign the middle tom to blue or green is matter of preference, I suppose.

To program my drum module, a Roland TD-3, I chose a kit I didn’t mind scrambling the MIDI numbers on, then hit EDIT > CONTROL and arrowed to the note number setting. The settings are summarized here:

Pad Color Instrument MIDI Note MIDI Instrument
red snare 38 SNR:H02 SNR:R02
yellow hi-hat 46 HH:H03 HH:R03 CR2:H10 CR2:R10
blue hi tom 48 T1:H04
orange ride 49 RD:H11 RD:R11 CR1:H09 CR1:R09
green low tom 45 T2:H05 T3:H07
purple kick 36 KIK:H01

Note that you have to keep your foot off the hi-hat pedal. (Or unplug it.) (Or assign to note number 50 and always keep your foot on it.)

Comments (3)

Beercan Volcano Kettle

I’ve been playing with making alcohol-burning volcano-kettle-style cooksets out of aluminum drink cans.

Kettle One>

Comments (1)

~1oz Backpacking Cookset

I made a solo backpacking cookset that weighs in at just over an ounce. Its the lightest one that I know of.


Theoretical Limits of an Alcohol Stove

I’ve been playing with different alcohol stoves (lightweight backpacking ones, that is). Building them, researching them, etc. My main goal is minimal fuel to boil one pint of water (using some lightweight cooking set). Boil time isn’t much of a concern for me.

The real competitor to alcohol stoves in terms of fuel weight are Esbit stoves; they’ll boil a pint using a 14 gram fuel tablet, and can probably be marginally lighter than an alcohol cookset. (The negatives are filthier burning and the cost of the fuel.) So it’s my goal to boil a pint with 14g of alcohol (by which I mean ethyl alcohol). Ethyl alcohol (aka ethanol) has a density of 0.789 g/cm3, so that’s about 0.63 fluid ounces by volume. Quite doable, I’m sure, but I haven’t done it yet.

That got me thinking about the theoretical limit for a 100% efficient cookset. (And let me say right off the bat that I am not a chemist of any sort.) Alcohol burns per the reaction

C2H5OH(g) + 3 O2(g) → 2 CO2(g) + 3 H2O(l)

releasing −1409 kJ/mol. Once calorie is 4.184 J, and the molar mass of ethanol is 46.06844 g/mol, so that’s 7310 cal/g of ethanol burned.

Meanwhile, a pint of water is 472g. A calorie is (by definition) the energy need to raise one gram of H20 one degree Celsius. Let’s assume we’re at NIST standard temperature, or 20°C (68°F). At sea level, water boils at 100°C; higher up, boiling point goes down, but so does the starting temperature around dinner or breakfast time, broadly speaking, so we shouldn’t be too terribly far off from what might happen up in the mountains.

In any case, to raise 472g of water 80°C will take 37760 cal. A 100% efficient alcohol stove then would need 37760 cal / 7310 cal/g = 5.17g of alcohol fuel. The stove I’m looking for (which will burn 14g), then, would be 37% efficient. Stoves that consume 1 fluid oz of alcohol, or 23.3g (a fairly common case), are 22% efficient.

There you have it – if you can boil a pint of water with 1/4 fl oz of ethanol, you’ve got a hell of a stove on your hands that’s getting close to the theoretical maximum efficiency.

(One minor wrinkle in all this is that the water produced by the combustion is liquid. I suspect that that water is inevitably vaporized during combustion, so that might need to be subtracted out of the energy produced by the combustion. If so, the heat of vaporization of water is 0.65 kJ/mol. Each mole of alcohol burned produces three moles of liquid water, so the net energy produced my burning ethanol would be 1409 kJ/mol – 3 * 0.65 kJ/mol, or 1407 kJ/mol. It’s pretty much a non-issue.)


« Previous entries