Why an API?

I was recently asked to provide some basic notes on what an API is and why one might want to develop or work with them. Having embarked on my own exploration of the topic only a few months ago, the following thoughts are probably naive and certainly incomplete. But they’re my current first-order approximation of an answer to the question, “why an API?”

Continue reading

Chronicle of a Lost Voyage

The following is the transcript of a strange, fragmentary journal found after the disappearance of a cruise ship on which a PHP conference was held in late July, 2016. The apparently doomed ship was last seen drifting northward, toward a strange distortion in the distant air that witnesses could only describe as a kind of portal. Despite the uncharacteristic uniformity of this description, it has been discounted as having any evidentiary value in the discovery of the ship’s final fate, on the grounds of being clearly fanciful and probably hallucinatory.

This journal, the only known surviving artifact of the cruise, was washed ashore in Delaware, and now remains locked in a cabinet in the Maritime History and Studies Department of Miskatonic University. It is bound in what appears to be some unknown kind of vellum, and emits a distinctly unpleasant odor of fish, cordite, and patchouli.

Here now are the disjointed and disturbing words of the only witness to that cruise’s final hours. While obviously demented, the poor author has left us a strangely compelling testament, the careful study of which may yet lead us to some kind of truth.

Continue reading

Beer Commercial

[Opening shot of the front end of a large truck. Camera dollies right, pans left and moves in, skimming past a well-known corporate logo on the side, and showing the last large pallet being forklifted on. Camera dollies forward into the loading bay toward steel double doors which open. Camera continues to move forward as a narrator steps into the frame from the right.]

“Hi there. Welcome to one of our breweries.”

Continue reading

Digital Musicbox 0.01

For a while now I’ve been thinking about building a programmable music box… that is to say, a device which uses a plucked comb to generate notes, but which is not limited by the number of plucking pins one can fit on a cylinder or disk. Up to now I’ve been focused on the idea of a modified cylinder system, dreaming up different ways of presenting pins on the surface of the cylinder.

It just dawned on me, though, that the best approach may be more analogous to an electric piano (the tines of which a music box comb is very like) crossed with a harpsichord.

Each tine of the comb would be faced by a small perpendicular rod, with a thorn-like projection for a pin. When the rod rises or falls, the thorn plucks the tine, and the tone is generated. All the actuating program would do is send a “toggle” command to the rod, ignoring whether the state of the rod is up or down.

One could thus program a complete arbitrary musical sequence, unconstrained by the limits of a fixed-diameter music storage device.

A larger version, plucking longer strips of metal or even tongues of wood, would be especially beautiful.

The idea is set, the problems defined. Now to work.

Marcus Welby Episode Schematic

welby2After watching the Snapping Turtle of Moralizing Medicine for years, my spouse has distilled the essence of the canonical Welby episode:

Happy person does a Thing. Thing is taxing to person, who tries to do said thing, feels faint, limbs shake.

Has checkup. Shows symptoms.
Welby purses lips. Suggests tests.
Person denies problem, leaves to do Thing.
Welby warns person, frowns.

Slightly less happy person does more Thing. Thing stresses person, who falls and passes out.
Welby runs tests, finds affliction. Welby lectures, scowls.
Person acknowledges condition but denies severity. Leaves to do More Things.
Welby hisses and snaps jaws.

Increasingly unhappy person does One More Thing, sees spots, has chest pains, collapses.
Unhappy person faces life-saving surgery.
Welby, smug and Right All Along, reveals character weaknesses to person. Person capitulates.
Welby touches person’s shoulder, displays understanding bedside manner technique #4.

Unconscious person has surgery. Welby paces, drinks coffee.
Conscious person, recovered from surgery and happy once more, resumes doing Thing, but accepts limitations.
Welby, smug, right, and now wealthier, smiles, eats lettuce.


Dreamachine 0.1

Being an old hippy, I’ve always wanted my own Dreamachine, the trance-induction device designed by William S. Burroughs’ compatriot, Bryon Gysin. Being a nerd, I’ve never been satisfied with the idea of a simple rotating flicker, but have felt that a more appropriate instrument for my own purposes would need to be… well, just more.

And now, with the ready availability of programmable LED strips, I’ve finally built my first version (which now wraps my cubicle at work) and am working out the details of the more sophisticated model to be installed in my meditation room at home.

The alpha model, code for which is shown below, is a simple strip of RGB LEDs hooked up to an Arduino. The code allows me to specify different waveforms, rates of change, and maximum values for each color channel, and push them down the strip in waves.

An Arduino is slow enough that actually ‘drawing’ colors across the strip would probably be pretty tedious, so all I really do is calculate the next value of each channel, assign it to the first LED, and then shift the whole thing forward one step. Holding the strip in memory – which you have to do forĀ  anything remotely interesting – turns out to blow the low memory of the Arduino pretty easily, so I couldn’t use a normal array processing routine to perform the shift… instead, I use C’s memmove, which performs the shift “in place” as it were.

The waveform I need to work on a bit more is the RAND, which needs some first-order smoothing and a slightly more sophisticated ‘colorizer’ than just the threshold.

I’ve gathered circular LEDs and illuminated rotary encoders to build the final version, which will allow me to control all the relevant parameters through a pretty little hardware interface. In the meantime, here’s the desktop model’s direct-control code:




Processing 001: Nabokov’s Butterfly

— applet display disabled, since java security is whack —

An early effort with Processing: implementation of a function demonstrated by a mathematician I know online only as fadesingh, which he originally showed here (it’s a big animated gif… give it time).

Some scaling factor appears to result in a rosette where he shows a butterfly, but it’s an interesting first step none the less.



Addendum: I’m beginning to see where my understanding of the idea behind this is faulty. More later, when I am sure of my corrections.

Arduino MIDI Drum .002

After several iterations I’ve come up with the basis for a functional trigger circuit.

The piezo element (across a resistor) runs into Arduino’s Analog 0 pin, and also feeds a comparator whose reference is supplied by a variable resistor (which is fed to Arduino’s A5 for monitoring). The output of the comparator drives an interrupt routine attached to Arduino’s Digital pin 2 (interrupt 0). That interrupt routine polls the piezo’s value at A0 then returns to the main loop- which does nothing right now, but is where MIDI and other processing will go.

The comparator is to provide trigger thresholding in the analog domain, relieving the Arduino of the overhead necessary to do it in software.

It turns out that the acquisition of the piezo value is fast enough that I can grab a significant series of data points into an array and print the array out to see how the thing actually responds to various events. My first discovery is that its first sample isn’t its peak and that it really does ‘ring’. This confirms my thought that a likely peak detection algorithm is to run the samples until I see a falling value, in which case the prior sample is the peak.

I tried printing the array of sampled values to Processing for graphing but am having port reading problems in Processing.

The other thing I saw is that, across a 1 megohm resistor, the piezo maxes out the Arduino’s input very fast under very small impacts, and that reducing to a 100k resistor brings the response to within a more reasonable range. This suggests that replacing this fixed resistor with a variable will allow me to adjust the overall sensitivity of the final instrument. But I don’t want to have a pot control for every piezo element, so I’ll use a set of digital potentiometers under control of a single rotary encoder. The comparators for each element can all use the same voltage reference, so only a single pot is still required for that function.

So, next steps: set up my first multiplexed piezo array, implement what I now think is the appropriate peak sensing algorithm, and collect the components necessary for my ganged sensitivity controller.

Thanks are due for my work so far to the following sources on Arduino drumkit building and basic comparator use: