Cambot is a project based on the Teensy development board. Cambot creates an infra-red “trip beam” that triggers a pre-focused Nikon D90.

To create an IR beam and detector that work in direct sunlight, Cambot pulses the IR source every 10ms, and compares detected signal between the on and off states. If it’s greater than a threshold, it’s considered a valid signal. The sensor also has a vary small aperture which is additionally shielded with a filter to reduce the ambient IR. When powered on, Cambot goes into calibration mode, which lights up an LED when it detects a good signal. This is critical for lining up the IR sources and detector — once a good signal is sustained for 3 seconds, Cambot goes into “armed” mode. When armed, breaking the beam will turn off the IR source, half-press the camera’s shutter for 10ms so the camera can compute exposure, and then fires off a burst of pictures before re-arming itself.

While there’s nothing in Cambot that couldn’t have been implemented with, say, 555 timers, counters, and gates, having the ability to drive digital logic with C code makes things much more flexible. When trying to determine the proper threshold values for arming and triggering, the ability to output hex data over the USB connector to a host computer was invaluable.

Here’s Cambot’s first run, when the trip-beam was positioned over a tempting milkweed blossom in the back yard.

If there’s any interest, I’ll post a circuit diagram and source code.

Well, now, over the weekend was the 10,0000th download of our Royal Flutter font from dafont.com (the original distribution site). Of course, any free font distributed on dafont.com is copied and distributed through dozens of other sites such as MaxFonts, FontRiver, FFonts, Fonts2U, WebToolHub, and more.

I wonder what percentage of the downloaders actually use the font. I know there are plenty of font collectors out there. It can be addictive, looking at all the type faces, and thinking “yes! I could use that some day!”

Work progresses on a new (commercial) font which will likely be called Lunatrix. It’s a techno/space font, and will be available in five weights. Something more for the collections!

At last, a cure may be available for this terrible disease. Expect to see this ad in print magazines everywhere.

Click for Larger Image.

Printable size available. Inquire within.

As much as I like some of the new crop of young adult fiction, I can’t help but wonder if this phenomenon isn’t just rooted in publishers being squeamish and authors being lazy. The category allows — no, encourages — writers to be less nuanced, paint with broader strokes, and, of course, avoid sexuality altogether.

Then again, the YA Fiction phenomenon may simply be symptomatic of “non-young adults” non-reading.

I’ve played with the Javascript interface to Photoshop for a couple of years. Conceptually, it’s great — a simple, powerful, interpreted language like Javascript, with an API to interface to one of the best image-processing packages available. In practice, it’s not as good as it is in concept, but it’s still pretty good. The API doesn’t include all of Photoshop’s functionality directly, and there are a lot of things you need to execute as fairly obscure event actions. These event actions aren’t documented, but can be determined by activating a plug-in which logs everything that you do using the Photoshop GUI — you can then read through these logs, and copy the actions you need.

Still, there are some real advantages to using this Javascript interface, as opposed to something designed for the purpose like, say, Processing. You can use the Photoshop UI for controlling inputs to your script (set foreground colors, select portions of the image, select specific layers, etc.), and output your manipulations directly into Photoshop layers.

I’ll be posting here shortly a library I’ve created for easily building dialog panels for setting script options. I find that most manipulations I want to do have a set of variables, and I’d rather not tweak the code each time I want to change them.

This library was originally written under Photoshop 10 (aka CS3). Under version 11 (aka CS4), it was less stable. Sometimes it would crash out at odd places complaining that I was referencing properties of undefined objects. Because there have been memory leaks and other issues with the Javascript interpreter, these seemingly random failures were annoying but not too surprising. When it came to version 12 (aka CS5), I was rarely able to run my scripts at all. What made it frustrating was the apparent randomness of the crashes. I could print a variable to the console, and the very next line would crash out with an “undefined object” error when referencing that variable.
To make a long story short, I was able to track down the issue. It turns out that in iterations, declaring variables matters. That is to say:
for (i in someCollection)
{
$.writeln(i['someAttribute']);
}

will cause random crashes, but
for (var i in someCollection)
{
$.writeln(i['someAttribute']);
}

runs beautifully. Now, I “knew” that the var keyword is optional and used for specifying scope, but I never had any idea that there could be an issue within the scope of a simple loop. Obviously, Javascript didn’t know that I intended i to be a variable on each iteration — perhaps it thinks I meant for i to be a 1957 Chevy Belair on some iterations.

In any case, having cracked the code as it were, I have proceeded to enhance and add to my library. After a little more testing, I’ll be posting it here or on GitHub.