fogbound.net




Wed, 2 Jan 2019

Using Makefiles for Teensy Development on Mac OS

— SjG @ 9:24 am

Even if you don’t want to use the Arduino IDE for building your application, or want to do fancy things that only the evil, convoluted syntax of Makefiles can provide, you can do Teensy development on the Mac from the command line. While there are a lot of guides out there on how to do it, I hadn’t seen a complete step-by-step set of instructions.

So with no further ado, here are the steps for building Teensy applications on Mac OS using the Makefiles and the mighty command line.

  1. Download the Arduino IDE from https://www.arduino.cc/en/main/software and install it.
  2. Download Teensyduino from https://www.pjrc.com/teensy/td_download.html and install it.
  3. Download a “basic project template” for Teensy. The original is at https://github.com/apmorton/teensy-template but I’ve been using the fork at https://github.com/a-j-f/teensy-template which has been updated more recently and uses the Teensy CLI Loader for uploading to the device.
  4. Update the Makefile to set your Teensy model
  5. Type make to build, or make upload to install on your Teensy

If you’re wanting to monitor the serial console of your Teensy over USB, install a terminal program like CoolTerm. Alternatively, if you use Homebrew or MacPorts you can use a console-based terminal program like minicom. Once the USB connector is plugged in, your Teensy will show up as something like /dev/cu.usbmodem45504901. The communications settings will be 115200 baud, 8 bit, no parity, 1 stop bit.



Tue, 1 Jan 2019

WordPress Editors

— SjG @ 11:18 am

I have WordPress automatically updating itself and its plugins using a cron job that uses the magical Word Press CLI. Overall, I’m pretty happy with it. But then, one day, the latest version installed, and my “editing experience” has gone to the new Gutenberg editor.

Now, like all creatures of habit, my first response was “what?!” As I’ve written before, I resist changing things that are otherwise perfectly functional. But then I thought it was an opportunity to work on maintaining that brain plasticity and build some new neural connections. Instead of immediately installing the plugin that allows me to keep the old editor, I’d give the new one a try.

Initially, it did not go well.

I saw the new interface, but the little button to add blocks was grayed out. A single “Title” field and “Text” area appeared, and I could enter data into them, but I couldn’t add new blocks. The javascripty-pop-ups didn’t.

So I looked at the JavaScript console, expecting to see an error from a misloaded source file or some bug. Nothing. I clicked around the interface like an increasingly frustrated monkey for a while, and got nowhere.

Turning to the interwebs for support, I didn’t see much that was helpful. This thread and this one both talked about issues and solutions, none of which seemed to apply. My server is sending proper headers, I don’t have any weird plugins, etc. I checked my user profiles, and they were set to use “Visual Editor.”

It was this last item that was indeed the culprit, though. Unchecking the “Use Visual Editor” and saving my profile, then rechecking the “Use Visual Editor” checkbox and saving my profile fixed things. How fucking annoying. Get out of the car, get back in the car.

In any case, I’m getting used to Gutenberg. I can’t say I like it more or less than the previous editor.



Wed, 8 Aug 2018

Building Kannel 1.4.5 under CentOS 7.5

— SjG @ 1:05 pm

Well, it’s been a few years since I’ve had to build Kannel (see Compiling Kannel under CentOS 7.0), and a server migration required that I figure it out again.

You can find discussions on why Bison v.3.0 or later, standard with modern versions of Linux, prevents compilation from succeeding. Some discussions provide workarounds that I couldn’t make work.

Here’s how I downgraded Bison and built a working Kannel 1.4.5 binary on CentOS 7.5:


$ cd /usr/local/kannel
$ wget --no-check-certificate https://redmine.kannel.org/attachments/download/322/gateway-1.4.5.tar.gz
$ tar xzvf gateway-1.4.5.tar.gz
$ cd gateway-1.4.5
$ sudo yum downgrade bison
$ sudo ./configure --prefix=/usr/local/kannel --disable-wap --enable-start-stop-daemon
$ sudo make
$ sudo make install

In that downgrade step, Bison was rolled back to version 2.7-4.el7. If you’re doing this at some indeterminate time in the future, the downgrade may be to a 3.x version, in which case you’ll want to downgrade until you’re at a 2.7.x version (also, if you’re at some indeterminate time in the future, simply check your watch and it will be roughly determinate again).


Sun, 20 May 2018

Moving away from Aperture

— SjG @ 7:39 pm

I’ve finally moved away from Aperture.

I thought I’d share a few thoughts.

Back in the day, when I was still largely shooting film and occasionally scanning prints or negatives, I organzied things by directories. I’d have descriptive names like “hike_at_paseo_miramar”. Over time, this became unweildy, and I had the startlingly brilliant and utterly original idea of organizing by date as well, so I had a directory the looked like:

photos
-> 1997-08-02
-> 1997-08-04-pasadena
-> 1998
—> 1998-02-01-hike
—> 1998-02-07-beach
birthday_party
hike_at_paseo_miramar

You can see the problem. I found I could keep this going by using Adobe Bridge, but I needed a better system. For a while, I organized my pictures on a web server with a cobbled-together collection of perl programs. That was manageable for about two months. Eventually, I tracked down some novel software to organize photos: iView Media Pro. It used the now-familiar idiom of folders (which represented physically where they were on the disk), virtual albums for grouping, and keywords.

iView was great until it wasn’t. The company didn’t have the resources to support it to the degree it needed, and occasional bugs (like the one that wiped out keywords for a few thousand pictures) were frustrating. When the product was sold and the team migrated to Microsoft, I figured it was time to move on. I went with Apple’s $300 “Professional” product: Aperture.

I had to write some code to export my keywords and organization from iView into Aperture, but that left me with a system that worked. It served me well for ten years. For the last two of those years, a cloud hung over me. Apple end-of-lifed the product, and, while it continues to run, did not get any new features or bug-fixes. With each new version of Mac OS, there was the risk that I’d no longer be able to run it.

I did a trial of Capture One, and was impressed with the RAW processing and the workflow. Where it failed for me, though, was in the cataloging. At this point, I had about 55,000 photos in my catalog. Because I like to have them all “with me” at all times, I kept my library on my notebook. I realize this is a strange requirement for most people, but I like the ability to bring up a collection of pictures from a given trip or a given event when I get together with someone else who participated.

Capture One had a hard time keeping up with that many photos. I considered breaking the catalog into separate, smaller collections, but was still resistant to any little impediment to finding the picture I want at a given moment. Ironically, Phase One, the company who creates/sells Capture One has acquired iView Media Pro from Microsoft somewhere along the line. I contemplated moving back to it, but realized I’d need to get that, plus a RAW-processing package, etc, and decided against it.

The 10,000 ton elephant in the room, of course, is Adobe Lightroom. It dominates the photo processing/organizing space. I didn’t want to move to it because of the software subscription model. I don’t want to be beholden to Adobe for all eternity.

Still, after trials of several products, I have been forced to surrender. Lightroom is the only product I could find that worked as well as Aperture.

Lightroom will import Aperture libraries, but the non-destructive editing from Aperture does not come across. Some adjustments might, a lot of metadata will, but those painstaking edits do not. I invested in ApertureExporter, which helps the export process by building a copy of the catalog, and creating extra copies of edited images where it “bakes in” the changes. So you’re left with the original (in case you wish to re-edit), and a JPG or TIFF version with all your changes. I left to run all night, and the result was a nice clean export.

Importing into Lightroom was not difficult. It was interesting to see all the cores of the CPU go to nearly 100% utilization while LR generated previews. I opted for large previews (typical screen resolution). This allows me to have the versions to show off to people (as I mentioned above) while keeping the originals on an external drive that may or may not be attached at any given moment. LR has something called “smart” previews that you can even edit while offline. I didn’t think it made sense for me, but I may revisit this decision later.

I was graciously given a nice tutorial on the basics of using Lightroom by Tomas Fjetland, which helped get me up to speed.

Some observations. Some things in Lightroom are much easier than in Aperture. Lens correction is a single click, instead of requiring a separate plugin. Some things in Lightroom are harder. Having separate panels that you have to switch through for “Library” functions (cataloging and managing keywords) and “Developing” (adjustments and edits) seems unnecessary, especially as the switch doesn’t really result in more efficient use of screen real-estate. Tagging keywords requires a lot more clicking. An auto-completed keyword requires one hit of the return key to accept the auto-completion, and a second hit to apply it to the image.

I’m still pretty slow at the editing tools, and the paradigms are not identical. All that old muscle memory in my fingers is slow to retrain. Overall, I’m pleased with some of the results I’m getting, but it will still be a while before I’m as quick or adept at Lightroom. No doubt I’ll revisit this posting at some later date.


Sat, 9 Dec 2017

Laser Menorah

— SjG @ 6:49 pm

You know, this title is misleading. The reality is a whole lot more boring. Maybe next year, I should take inspiration from the title.

This is more of a lazy Saturday afternoon project. I wanted to use some designs that I’ve been kicking around. So I took a sea of hexagons and a tree in Affinity Designer and mucked about for a bit until I had something where I more or less liked the look.

Next, I grabbed a slice of poplar (available in 8″ x 24″ x 0.25″ slabs at Home Deport, as “Hobby Poplar”) and drove over to CRASH Space. While it’s mega-take-apart-day, I scurried over to the laser cutter. I converted the design to PDF, loaded it up in Corel Draw, used the Epilog printer-driver, and sent it to the laser cutter. The poplar cuts very nicely.

Here’s a link to the PDF of the laser-cut portion, if you want to cut a copy yourself.2017-12-09-hexonorah-cut.pdf

I brought the pieces home, sanded lightly, drilled a few holes, and mounted the vertical piece onto the base, carefully mis-aligning it with the major axis of the elliptical base. Ah well.

I drilled holes where I would mount the candle holders themselves (after all, poplar is pretty, but not ideal as a holder for things on fire). For the actual sockets, I used some nice quarter-inch brass compression caps (also from Home Depot). I drilled a center hole, pushed through a brad, and then soldered it with a torch.

Next, let things cool, dried off the sockets, and put it all together.

The final result is not as attractive as I had imagined it. It’s a little … I dunno, squat? Perhaps the next iteration will have more dramatic tree-like branches emerging to hold the candles.

OK. Next year, forget the design. We’ll just go with lasers.