My two main life activities are software engineering and guitar playing.
You can view my professional resume here .
I also have a musical resume here.
Software has been a serious hobby for many years (in addition to being my main profession). I've worked on countless small software projects and tools over the years. This page describes a few of the projects that I've recently worked on:
I also maintain several web sites for past and present bands that I've performed with (as guitarist):
Riff (Ray's Interactive Fiction Foundry) is an interactive fiction game interpreter using XML-based input files following a proposed standard format called "IFML" (which I am also developing).
IF (aka text adventure games) is something I've been interested in for years; in fact, they were instrumental in my becoming a software developer. Over the years I haven't had the time to remain involved in IF (or even play the games much) but my interest in developing the software for IF games has remained a constant, but not well-fed, hunger. I have started work on various engines and tools many times in the past but never brought anything to fruition nor public view.
I came the closest around 2002 when, while temporarily unemployed, I decided to teach myself Java and chose to develop an IF library for writing games using Java (which I called "JIFLIB" for Java Interactive Fiction Library). That project reached a point of near-completion but then I started a new job and my work on it stalled. In addition to the new time constraints, I had also become turned-off to Java due to certain technical limitations (namely, lack of static data structures, enumerations, and no ability to put a terminal into 'raw' mode; some of those things have changed since, however).
Some years later I decided to port it to C++ and to simultaneously develop an XML-based format for defining game content along with an interpreter to play the games. JIFLIB would have required game authors to write Java code to create games but the new tool allowed games to be developed completely in XML. IF uses large amounts of text and (as aptly demonstrated by HTML) XML is very good at packaging text. This effort also reached a point of near-completion but work on it was interrupted when I decided to externalize a scripting language that I had started developing for Riff.
The new scripting language was called goo and I had decided to externalize it so that I could use it in other projects. After developing goo for awhile, however, I realized that its evolving design had moved too far away from the requirements that I had set for Riff and that it would be better to keep the two projects separate, preserving the original design principals of the Riff scripting language (which I have now named "IFScript"). Work on both projects stalled for a bit due to "life" and more time constraints.
I have recently (Summer 2018) resumed work on Riff but I've decided once again to port it to a different language, this time Python (I know, this is getting ridiculous, right?! ;) But this decision actually will save me a lot of time and effort in the long run because Python provides lots of useful stuff for this project right out-of-the-box (it's natively cross-platform, doesn't require compilation, provides a single cross-platform packaging solution, has native internationalization, and all this without requiring any external libraries or tools!). I've also decided to develop the XML format into a standalone proposed standard to be called "IFML" (which includes IFScript), with Riff serving as the reference implementation. This effort is now in full swing but still has a lot of work to go.
It is said that one always writes a program "better" the second time around and that has certainly proven to be true with Riff! Through both re-writes the design has improved and the current version is starting to feel really good.
I plan to release Riff (eventually) under the GPLv3+.
Argent is an RSS feed reader that can search feeds for specified patterns and send the results via email. The name derives from the phrase "RSS Agent". Argent is a Python script which uses a SQLite backend to track which feed items have been seen so that duplicates aren't sent. The input is an XML file that describes the options and feeds to be processed. Argent is designed to be used on a server and driven by cron.
I am presently using Argent to scan craigslist musicians feeds and it is working quite nicely. The benefits of this approach is that I receive notifications of new posts almost immediately (dependent mainly on the frequency that Argent is invoked via cron) and I am guaranteed not to miss posts if I forget or am unable to check the feed manually. Of course, immediate notification also depends on your access to email; but at least you won't miss any. Having a smartphone helps considerably.
Argent's filtering capability also means that I only get notified about items that meet my search criteria. This, of course, works only as well as your search criteria: you will very likely get false positives and you could miss some items that your filters didn't capture. You will likely end-up needing to make a compromise to find the right balance (but at least you won't get inundated with junk you're not interested in).
A good example of this is something I encountered with craigslist feeds. I wanted to exclude "services" ads so I added "services" as an exclusion term. Turns out, however, that this excluded ALL feed items because craigslist inserts a boilerplate footer in many items that says: it's NOT ok to contact this poster with services or other commercial interests. Oops.
I do not expect to be able to test Argent myself on a wide variety of feeds and so I will be very interested in beta testers to help with this. If you think you may be interested please drop me a line (codemonkey AT interthingy DOT net).
The Argent project is hosted on SourceForge.
Stomper is a virtual pedalboard for guitar, using commonly-available audio effects plugins in a user-defined arrangement and MIDI for switching. It is optimized for on-stage use and intended to replace traditional effects processors and/or pedalboards.
The Stomper project is hosted on SourceForge.
Rex is a fairly simple utility to process text using regular expressions. It was originally a proof of concept for some goo runtime library elements and I decided to make it into a formal project. It provides two basic useful functions:
The rex project is hosted on SourceForge.
Brisk is a text editor inspired by the script-centric design of the old Brief text editor from the late 1990's and, in some ways, the current Vim text editor.
I use Vim constantly (I'm writing this with it now!) but I have a love/hate relationship with it: I love it's functionality but I hate the modal editor concept.
Back in the late 1980's, when I was working on DOS-based software, Brief was the go-to programmer's text editor. It had the very unique characteristic that much of its functionality was written in its own scripting language and the implementations could be freely edited, thereby allowing programmers to customize it at a very deep level as well as create completely new capabilities.
During one of those times when I was feeling frustrated with Vim I hatched a plan to write my own editor. My plan is to take many of the good features in Vim (and, no, modal editing is NOT on the list! ;) and to create a design based on Brief using Python as the scripting language.
I already have a basic proof-of-concept working (in C++) with full Python integration (thanks to Boost.Python). I am currently working on some infrastructure stuff with a short-term goal of having a basic editor working (more fancy features will be added later on).
The design consists of a small set of core functionality which includes:
The design allows for multiple user interface implementations but the initial UI will be curses-based. A UI is responsible for interfacing with the underlying display system and input devices and it uses the keymapper and dispatcher to execute commands based on user input.
Brisk will provide a set of built-in commands and users will be allowed to remap input events to commands that they write in Python. All but the most basic functionality will be implemented in Python. A typical command will use the Editor class to access the current View and, if needed, its Buffer, and then carry-out operations on the Buffer. An operation may simply manipulate the View (e.g. move the cursor in some way) or change the text.
Full undo/redo will be provided as well as easy search & replace with (and without) regular expressions, clipboard support, and all other basic editor features (and hopefully many advanced ones, not unlike Vim).
The infrastructure that I'm currently working on includes buffer and view management as well as word-wrapping and rudimentary (regular expression-based) syntax highlighting (I'm working on these early-on because I consider them important and they both impact the design of the rendering sub-system significantly).
I plan to release brisk under the GPLv3+ once my short-term goal of a basic editor is realized. I hope that some other folks will like the concept and help to build-out the more advanced features.
Doki is a document authoring markup language and rendering tool which is mainly intended for producing technical documentation (especially for software projects). The doki markup language is an amalgam of wiki syntax and older meta-command-based tools (e.g. troff and family). The reasons for creating doki are expressed within it's design goals:
Doki is a reaction to existing tools which I found to be too tedious to work with because of violating one or more of the design goals iterated above. Many current tools (e.g. DocBook) use XML which I personally find to be very unfriendly to mere human authors (it is fine and well-suited for our future cybernetic overlords and for structured data but not so much for things such as human-authored narrative text). Other tools have some interesting ideas (e.g. QuickBook's use of square brackets in a Lisp-like manner) but most just seem too tedious to work with. Wiki syntaxes tend to be closer to an ideal solution but often get overly complex, employ unusual markup or are too weak in some areas (e.g. tables). The closest I've found to my ideal is reStructuredText and indeed I have used it for one of my employer's projects. However, it has some sub-optimal markup and a serious issue with the markup for designating section headers. (Briefly, it requires authors to use arbitrary symbol characters that have no inherent order, which forces authors to not only manage the markup but to design their own scheme and remember it! This makes it difficult to keep track of where in the document you are. Additionally, the markup is structured in such a way that supporting things like color syntax highlighting is difficult or impossible in some third-party tools.)
Doki is being written in Python and development work is well underway. It can already produce simple documents very well but a little more basic fucntionality is required before it is unleashed upon the masses. The initial versions of doki will support output in HTML and plain text formats (including an option for plain text with ANSI terminal code-based typography).
I plan to release doki under the GPLv3+ at some point.
Goo is a scripting language written in C++ and designed to be easily embedded in C++ applications. It started out as a scripting language in my Riff game engine and I decided to externalize it so it can be used elsewhere. The original design goal was to make a language that would be friendly to non-programmers and part of that was to minimize the syntax requirements. The result appeared to have little structure (at least to someone used to programming in structured languages!) and that was the origin of the name 'goo' (as in a gooey substance lacking structure). It has evolved somewhat since that time but I think it is still easy to use and read and the syntax requirements are still very minimal. The biggest change is that it now requires curly brackets for code blocks (which I felt was a beneficial trade-off). Most of the basic language features are implemented and working well. I'm presently finishing some runtime library elements and I'm considering adding user-defined classes and modules. I am also experimenting with an extensible parser system that would allow host applications to extend the language for their own purposes.
I plan to release goo under the GPLv3+ when it becomes somewhat stable and a bit more useful as a stand-alone scripting language (it is actually already useful for some things).
Heat is a somewhat ambitious project to design and implement a new software build tool. It came about because of my frustration with existing build systems. Much of the design is complete and, I think, very promising.
The project, however, has been on hold since I decided to base it on my goo scripting language. I want to get goo into a reasonably stable and complete state before I begin implementing heat, which will embed and extend goo (and effectively act as a test case for doing so).
I plan to release heat under the GPLv3+ when it becomes somewhat stable and useful.
Tagtools is a set of Python scripts for managing tags (meta data) on audio files. Some devices (like my droid2) prefer to manage a music collection using the meta data, or 'tags', and if the tags are not correct and consistent the result is a big mess. (Prior to my droid2 I used various music players running the Rockbox open source firmware, which manages music based on the directory structure, which I prefer. Nevertheless, it is a good idea to keep the tags in reasonably good shape.) When I moved to my droid2 I already had a large music collection and fixing the files manually is beyond tedious. So I've written a number of scripts over the years to process the music files. I'm currently working on a Python script called taglint which will detect many different kinds of errors and I decided to package it along with a few other useful tools. taglint will have the ability to fix some errors (but probably not all) and I'm considering a GUI to allow interactive repairs.
I've so far selected one other tool for inclusion in this package. It is a command line-based tool called tagcp which copies tags from one file to another (including across file types). This can be a real time saver when transcoding files and I was quite surprised to find that virtually no other tool did this. tagcp currently supports OGG and MP3 formats.
I plan to release tagtools under the GPLv3+ at some point in the future.