The random software projects thread


Nice project! And yeah, sqlite is awesome, though it’s designed to be used on a local filesystem.


Android uses sqlite as its default database provider. It’s a nice piece of software. All of of these sound really cool, although I also relate to the ‘need more free time’ thing.

I did spend most of my Saturday morning working on podcasting setup, which has a software angle—I have two good USB microphones, and through the magic of JACK, managed to come up with a setup which allows me to record both on the same computer, as two channels of the same input device, with real-time monitoring. Four hours ago, I thought that was impossible.


JACK is amazing. I remember its early days, when good, low-latency multimedia work on Linux was but a wet dream. I wish I had free time to do more multimedia things on Linux. :)


I must be the only one who hasn’t had a great experience with sqlite. Several years ago I coded a computer metric logging system that would constantly log any metrics it could find (cpu temp, core speeds, fan speeds, gpu temps, etc…) and also what processes were running. The point of the app was so I could use a WPF tool to generate graphs that allowed me to see things like “how has the average CPU temperature changed while playing Borderlands” (so I knew if my computer’s temperature was starting to rise over time).

Every once and a while the database would just empty and restart. I never did track it down though so I guess I don’t know for sure if it was sqllite’s fault or my own.


For the record, I once used sqlite embedded in a network analyzer software to track VoIP statistics in real-time, with no significant issues (and no data loss ever).


Yeah who knows. To be fair when I said I never tracked it down I really mean I never tried to track it down. By the time I noticed it happening I realized I never really cared about that data anyways so I never bothered to look into it more.


Update: I was arrogant, and I have been brought low.


That xkcd is awesome.

Even though I do 100% .net development at work I got annoyed with windows and put Linux on my work laptop. For the most part it went fine until a week or so later I got some error saying that some signature didn’t match and I couldn’t boot. I kept booting off of live cds trying to futz with it to fix it and kept failing until I realized the error message was coming from Dell’s secure boot. Turns out it just lost the boot signature and couldn’t verify it so I had to turn secure boot off. By that point I already messed with the system too much and it was too late to salvage, and a reinstall was in order. That whole ordeal wasted 3/4th of my day.


I spent last weekend on Linux low-latency audio stuff. Eventually, I gave up, made a little 32gb partition, and installed a distribution suited to low-latency audio work. It does all its recording etc. to my larger data partition, and works with two microphones running through Ardour (I want to do some noise-gating, so I don’t get my own breathing sounds as much). The process was annoying, but the results are pretty cool.

Now that I’m done with that, I’ve been getting back to my reading for Random Carrier Battles, a project I announced in the Grognard Wargamer thread a few months ago. I have a copy of a book by Norman Friedman on the design and development of US Carriers; among all the pretty line drawings and blueprints are some doctrinal facts that mean I have to do a bunch of rewriting of the code. My view of aircraft handling (and of carrier design) was insufficiently detailed—American practice in the interwar years, for instance, frequently led to hangars which were not large enough to contain the entire air wing. Some planes would have to be parked on deck, and because that obviously presents problems for aircraft recovery, American carriers usually had arresting gear at the bow and provisions for running at high speeds astern. You’d leave the aircraft parked at the back of the flight deck, run the engines up to back full, and land whatever you had to land over the bow.

Anyway, I’m not sure how much of that I’m going to expose to the player/admiral, but I think I will have to do some extra simulation of flight deck space and takeoff rolls to more accurately get at the difficulty of getting a strike in the air in a coordinated fashion. In any event, I’m waiting until Godot 3.0, because the single-precision-only in GDScript is killing me.


Today at lunch, and then a little after work, I plugged the adaptive speed bits into my Morse engine. Since I’ve found that most Morse teaching tools are bad at teaching the spacing in between characters and words, I set it up so that the engine listens for three speeds: one between words, one between characters, and one inside characters. Some example statistics are in order:

Part:      Avg. Time: (actual  /  system wpm)
Dot:         65.11 ms (18.43wpm/16.67wpm)
Dash:       248.45 ms (14.49wpm/16.67wpm)
Intermark:   83.83 ms (14.31wpm/16.67wpm)
Interchar:  425.49 ms ( 8.46wpm/14.46wpm)
Interword: 1071.60 ms ( 7.84wpm/11.65wpm)

Note that the dot, dash, and intermark (i.e., the space between dots and dashes inside a character, supposed to be one dot in length) system speeds are all the same—it tracks the average speeds for each part separately, but combines them all for the speed it listens at. The interchar and interword speeds are the other two I mentioned, between characters in a word (three dots or one dash), and between words (seven dots).

After I sent a short sample message (.–. .- .-. … …/… -./… .–. .-. … -. --. PARIS IN SPRING), the engine adjusted my speeds from starting settings of 12.5 wpm (inside characters)/12.5 (interchar)/10 (interword) to 16.67/14.46/11.65. There are limits on how much slower than the intra-character speed the other two can go, so although my intra-word and inter-word delays were way slower than my intra-character speed, they’ve still been adjusted upward. (This puts some pressure on the Morse operator to send a fixed speed he knows he can manage, rather than going full bore on an easy sequence like PARIS IN SPRING.)

Next on my list is a fallback decoding mode, for cases where the operator is much faster or much slower than the target speed. There’s a reasonable amount of tolerance built in—I went from the ~15wpm in the example stats above to 10wpm without any decoding failures—but especially in the case where the operator is faster than the target speed, I run into problems. There’s a hard threshold below which a noise is a dot, and above which a noise is a dash. If all the noises are below that threshold, the engine reads everything as dots, even if the noises are of highly varying lengths. I think I can probably do some analysis on a given chunk of code, and if I see that signature (dots of varying lengths), attempt to adjust the speed based on dot/dash length and decode again, at the cost of real-time feedback.

I’ll probably be able to release the Morse engine soon, although the follow-on projects (a teaching/skills maintenance game, and an Android input method) will likely take some time beyond that.


Great idea…in fact, shut up and take my money!

In the same vein, I bought a network attached device a few years back thinking it would be nice to put all my digital media in one place, but started realizing what a hassle it is to collect all of it plus any online stuff, go through the effort of downloading or converting it, then organize and catalog it.

Games are like that too…Got stuff everywhere (Steam, Humble, etc) and whenever I want to buy something I have to go through each and try to make sure I don’t have it already. In the beginning it wasn’t too bad but now that I’ve been buying bundles for a while, the Humble library search has gotten really clunky handling the load.

So very interested in your project.

As for me I’m mostly a boring SQL programmer with some PowerBuilder and C# at work. You can laugh, but that stuff has put food on my table for a long time and I’m darn glad to have it. Like a lot of guys here I’d love to make a game someday but just don’t have that much time now.

I did do a project with the NAS unit. It has a really lightweight version of Linux on it and I hacked together some scripts to make it connect over the net with vpnc to a friend’s server, run some MySQL jobs to copy over some data to my NAS. I was essentially his off-site second backup. I was pretty amazed at what you could do with the NAS’s modest hardware.


I got entirely out of the iPod ecosystem a while ago when someone nicked my iPod classic. Since then, I’ve really missed “useful” smart playlists, and I’ve settled on the Ampache media server to provide them across all clients. I’ve made some updates to Ampache (PHP). This led to wanting a better Ampache client for my Android phone; I have some Android development experience with this VNC client (which actually has millions of downloads from the app store) and I’ve put that towards the music player Patchy AMP– just been playing with it since New Year’s, so it is pretty much in alpha.

My most serious, long-term project is Browse-by-Query, which is a special-purpose query language for code browsing, which works on Java and C# projects and which I use in my day job as well as on my personal projects. It has plugins for Eclipse and Visual Studio, and since Android development has moved to IDEA, I’m going to have to do a plugin for IDEA as well. Unfortunately, the packaging for Browse-by-Query has fallen behind and I think I’m currently the only active user.


When it’s updated for IDEA, let me know. That sounds amazing.


More Morse progress. The engine can now send Morse, either in purely standard form or imitating another source. In this clip, the engine sends PARIS IN SPRING with the standard Morse timings, then I send the same text, then the engine imitates me.

I’m not doing everything I could on this front. My ultimate goal is to allow the system to track a given user over time, and record his or her style per letter. I understand that experienced Morse operators can tell two senders apart by the way they send certain letters—the dashes in P (.–.) might be shorter than the dash in R (.-.), for instance. Generating that sort of profile for a given Morse sender will be important for some of the uses I have in mind for this library, too.

Last night, I finished removing the LGPL beep generator I had been using, so soon I’ll be able to do a release under some license I prefer more.


Over the long weekend, I banged out a few new features for OpenTafl, my hnefatafl* engine project. Most notably, I’ve moved slightly further from the original command-line ethos, so you can move pieces around on the board with the arrow keys and spacebar.

The modern history of tafl games starts with fairly recent reconstructions based on notes from Carl Linnaeus’ 1732 expedition to Lapland (the Saami people still played a descendant of hnefatafl then). As far as I know, the first published English rules date to the early 20th century. In the past two decades or so, it’s seen something of a renaissance, and in xkcd fashion, the number of rules variations exploded. OpenTafl, being the only extensible tafl engine in existence, has been able to capture almost all of those variations since the early days, but in this release, I finally got around to adding an editor to OpenTafl. Now it’s accessible to anyone, as opposed to those who go to the trouble of learning the OpenTafl rules notation (so just me).

*The Norse board game unfairly displaced by chess.


I’ve taken a break from my 10-min game jam project to make a game for my daughters. It’s a good opportunity to learn Unity, too. So far, Unity is frustrating b/c I know exactly what I want to do but you have to drag shit all around the UI and make resources and prefabs and whatnot in order to be able to instantiate things in code. It’s really weird. I guess it’s not really meant for people who want no UI. I decided to use it because I thought it would be easy to create Xbox 360 controller mappings for the game.

I created some templates that they can fill in with their drawings so that the various pieces tile together. Here’s an example of a ground layer and proximate background layer with some programmer art. Next up is to work on parallax background layers. While I’m aware that there are free asset store packages for doing this, I wanted to code it myself.

The concept: somewhere between Mario and Bit Trip Runner, but you can move infinitely in either direction. Levels are timed. There are three levels. That’s about as far as I’ve gotten. :)


In the beer thread, I talked about my latest hobby, homebrewing. There’s lots of brew tracking software out there, and a good bit of wireless hardware, but in many cases the software does more (or less) than I want it to, and the hardware doesn’t look like it’ll fit in my brewing setup.

Remote data is doubly important to me. My brewing is a joint venture with a friend, and since he has a basement and I don’t, the beers-in-progress live at his place. I’d like to be able to check up on them. Mostly what I want is a system to measure specific gravity over time. For the hardware side, I plan to crib heavily from the iSpindle, which measures the density of the fermenting beer by measuring the tilt of a cylindrical float with a weight at the bottom. (I would build an iSpindle without modification, but it’s too wide to fit through the neck of my carboy.) There’s a popular little wifi-enabled microcontroller with deep-sleep capability which is common in these sorts of applications.

On the user-facing side of things, I plan to have a Go web app as a back end and a Vue.js front end. I’ve been doing a lot with both at work lately, so I figure there’s no reason to reinvent the wheel. (Besides all the wheels I’m already re-inventing.) As projects go, I’m really looking forward to this one.


Well, Godot 3.0 is finally out!


Wow. Those shots from the new renderer are pretty amazing.

For that matter, the feature list as a whole is pretty incredible. I look forward to diving back in once the dust settles from our recent move.


I look forward to checking it out, though they kind of hint that 3.1 will be the real 3.0.