The random software projects thread

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.

Writing a Morse code keyboard was not the most productive thing I could have done tonight, but at least it was fun.

All I need to do now is an app to buzz texts in Morse code in my pocket, and the cycle is complete.

Wow, this is a great thread! I haven’t worked on a random project in a while though. A decade ago I could have posted a lot of stuff.

That’s really cool!

Came across this the other day:
https://morse.withgoogle.com/learn/

Which in the install directions instructs you to install the Morse keyboard set on Gboard which is the default keyboard on Android. So, look at that, Google comes with a Morse keyboard ready to go!

Anyways, it reminded me of your project and I wanted to share. I don’t know the alphabet so the little learning tutorial there was kinda neat.

So I want to start learning 3d rendering (but from the ground up with software rendering first). That requires me to learn a bunch of math that I’ve never done before, and some that I’ve done but a long time ago. I picked up what seems to be a good math book that approaches the mathematical concepts from a programming perspective.

So I started following along but got distracted because writing code → compiling → rerun for minor mathematical concepts (such as vector or matrix operations) sucks and breaks the learning flow.

So long story short, I spent the last 2 weeks creating a program that allows me to write code in any text editor I want (like VS Code) and every time I hit save it automatically updates the screen by plotting the results on a graph (that can be moved around, zoomed, etc…). I originally created it to support C# but I added Javascript and Python support as well (cause it was easy).

Code is at GitHub - KallDrexx/SharpPlotter: Application to allow 2d plotting in real time using code if anyone is interested.

I’m actually really happy with how it came out and was a fun little project. Of course, now I don’t have any excuse to get back to actually learning the math stuff I originally wanted to…

So I hang out in a small game dev community and one pain point that always came up was particle effects. Specifically Unity, Game Maker, etc… all have WYSIWYG particle editors that work well but there’s not a good generic one that can be plugged into other engines. The community I hang out with mostly delves in Monogame and Javascript.

Anyways a few months ago something piqued my interest and I decided to take it to make a particle engine suite. It has a nice little editor to quickly prototype and iterate on effects and code generation for high performing c# code (~200 particle emitter takes about 9 microseconds to generate particles and update existing ones per frame) that can be plugged into a monogame game pretty easily.

I have plans for Javascript code generation support sometime in the future as well.

Since there are some small game devs here I figured maybe some here might be interested. If so you can check it out Welcome To Parme | ParME (Particle Manipulation Engine)