Set the charset in freetds.conf

I’m building an API in Laravel that has to interact with an MSSQL database. This requires that I use freetds as the database communication library.

The database contains years of data from all kinds of input sources, probably including copy/paste from MS Word, and some of the characters can’t be processed as JSON if taken “as is” without character set identification.

I discovered this when a new endpoint was crashing with a 500 server error. After xdebugging the problem right down into Laravel’s core, I found that the Response object, in building its output, was NULLing my data when trying to JSONify it in morphToJson(). So when this processed content gets passed to setContent(), it fails the is_callable(array($content, '__toString')) test and throws an exception.

I had already suspected this was an encoding problem, so I’d found the solution buried, and apparently ignored, here:

Quite simply, in your freetds.conf, in the [global] settings area, set client charset = UTF-8.

And done. The funky characters are correctly interpreted, don’t NULL the JSON, and don’t crash the API.

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

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:

Arduino MIDI Drum .001

I am an inveterate tabletop drummer, so when I firstĀ  heard about the Zendrum my gearlust fizzed, only to be decarbonated by the price of what is really just a bunch of piezo triggers mounted on a nice piece of wood.

So, now that I’ve got the Arduino bug (my first circuit used a potentiometer to control the brightness of an LED [chuff, preen]), all things seem possible and I think to myself, “self… we can do one of these.”

Having obtained a fistful of piezo discs and a MUX board, I’m now faced with the task of sampling the peak values of those discs faster than I can thwap them and converting their data to MIDI events.

Now, I’m obviously not the first person to come up with this idea (here, let me Google that for you), so I can vicariously consider the problems of peak detection, sample rate and so on, before I ever touch jumper wire to breadboard.

For now, I’m going to see if I can get away without external peak detection or sample/hold circuitry. I’m going to write a simple state loop with no delays and see whether it serves the purpose without ornamentation. Something like this:

The actual MIDI processing is dirt simple (actual I/O will be handled by another board), so it shouldn’t eat up a lot of time. And if either acquisition or output winds up being slower than I think, I can offload either or both processes to auxiliary microcontrollers.

If all this works reasonably well, then I can look at adding a ‘programming’ state (probably switched to by interrupt) which would allow me to assign MIDI key values, modify thresholds, etc.

I wonder just how much of this stuff you can cram into 32K anyway?