I’ve been working on and off with Blinkinlabs’ BlinkyTape and pixels, which means also with their nice little app PatternPaint, which lets you create little light shows to download to their LED strands without all the annoying number-fiddling that is LED images on Arduino.
But when you have an LED strip with controller built in you have a few obvious potential problems. First, each of those LEDs can draw up to 50 milliamps when cranked up full, so about 3 amps for a 60-chip tape. Put the wrong pattern on there, and good luck talking to the controller chip over a standard USB port while it’s trying to draw all that current. Second, you need a really reliable USB protocol that can handle transmitting and receiving data while the microcontroller is running flat out handling the pretty blinky part. Third, some computers’ USB drivers and hardware are rock solid, others (many macs, for instance) are garbage.
So start by splicing extra power connectors onto the back of the blinky tape (extra points for avoiding ground loops) . Then find out that the usb connection still works only a few percent of the time, for various reasons including serial-driver bugs in the version of the Qt framework it’s built with. Here’s where it gets interesting, in the sense of the curse:
The latest version of PatternPaint is supposed to have improvements to the USB stack, including a fixed serial driver and a protocol that is more willing to retry when things go wrong. But the appImage of that latest release segfaults when run on all of the machines I have access to.
Yes, you read that right. The format that’s supposed to have all the bits and pieces its app depends on nicely built in to a custom file system leads to an executable that segfaults. (But not on all machines, because it wouldn’t have passed its release testing.) So it turns out that appimages do rely on a bunch of libraries in the underlying operating system, and in the couple of years since PatternPaint was actively under development some of those libraries have gone away or moved or been altered in some incompatible way.
So it’s time to start building from source. Download a current version of Qt and fire up the compilation script. No luck. Apparently the dependencies on a previous version were real. (or not, as we will later see) The version specified by the Blinkinlabs instructions isn’t even on the list of recently-obsolete versions you can download, but it is in the Qt archives.
Still no luck. But a few searches on the error messages tell me that some libraries that used to be present by default in Debian/Ubuntu are no longer present in recent versions, hence also not in the debian-derived BunsenLabs OS that I’m using here (because it’s what we’ve got at the school where I hope to deploy this insanity at some point.) Download the right version of mesa-dev and jasper, and try again. Still a failure. Turns out I’m supposed to have installed linuxdeployqt in the same directory as I’m compiling from.
So now everything chugs through endless pages of messages, and success is announced! I even get the request to post my appimage so that everyone else can use it. But no. right after that there’s an error message that tar cannot stat something for some reason and the whole process has failed. And the only way to figure it out is to start digging into the guts of the linuxdeployqt appimage or its source.
I’m about to declare defeat — or at least post an issue — when I decide to look into the build directory and see if I can at least figure out what tar was trying to package up. There’s a PattenrPaint.blah.blah.tar that’s empty — sad! — and there’s a file called PatternPaint.2.4.1.blahblah.appimage.
What the heck. Yes, I click on it and it’s a perfectly good appimage. Doesn’t segfault, brings up the splash screen. Talks to blinkytape on machines where the previous version wouldn’t. I have what I need, I just have this really uncomfortable feeling that that final error message is really supposed to mean something and I should find out what.