Chris McCormick

My first app of the year is out, hooray! \o/ It's a simple app to sync pocket operator devices. It outputs a sync signal from your phone which you can plug into your pocket operator's left input to drive it using a 2.5mm male-to-male stereo audio cable. It works well with the p0k3t0 Sync Splitter.

You can get it for Android and iPhone:

• PO Sync for Android
• PO Sync for iPhone

This was a fun app to build. I made it because somebody left this review on one of my other apps on Google Play:

Using this for the PO sync feature. I like that most; everything else is okay... I think a great idea would be to make an app with just the PO sync feature and a tempo slider or wheel, plus an on/off

So I knew there was at least one person who wanted this app. It was simple to implement and I got to use my favourite programming languge, ClojureScript. I love it when people need software that I know I can put together quickly. You can get the source code here:

https://github.com/chr15m/PocketSync

2023 is going to be the year of pocket operator apps for Dopeloop and I. I hope to make at least 4 new music apps. I'll post back here when I release them (and also to newsletter + Dopeloop subscribers).

2022 was a fun year for side projects. My indie apps made $2500 USD. I also hacked on a lot of open source code, doodled a fair few drawings, and started a new sci-fi lo-fi beats music project. \o/

Here's a spreadsheet of income from different software I made:

All of the revenue came from projects that I barely worked on. The "Git days (2022)" column shows the number of days for each project on which I made a git commit. On average this works out to something like "part time days of work". As you can see the vast majority of the income came from work I did in previous years. That's the very definition of "passive income"!

The mobile music apps continued to grow from last year despite no work.

Roguelike Browser Boilerplate steadily made one sale per month. I didn't touch the code or do any marketing.

Hosted Gitea gained a surprising number of customers this year. This is likely due to the articles I wrote at the start of the year which helped a lot with SEO. I have been putting some dev time into Hosted Gitea again recently. I owe it to the current customers to turn it into a product I am proud of. In 2023 I expect it will make double what it made this year. I donated the 2022 profits to the Gitea open source project and I hope to donate again next year.

Jsfxr Pro was the for-profit project that I put the most work into. I only just turned it live. Signups have been gradual but I have had good feedback so far. The TODO list is long and I am going to take a break while I figure out priorities and see how it grows organically in the coming months.

The most interesting/useful numbers from the spreadsheet are RPM and RPTD.

RPM = "Revenue Per Mille". It measures the revenue per thousand visitors. It's basically a measure of marketing leverage. How much is it worth to point 1000 people's eyeballs at the product page for each app? A high RPM means I don't have to do as much marketing because a small amount of marketing gets a relatively larger amount of revenue. Low RPM means a lot of work on the marketing side to get enough eyeballs to make it worth doing.

So high RPM means more coding and less marketing, which is what I want.

RPTD = "Revenue Per Total Days". It measures how much revenue the thing made this year, divided by the total number of days on which a git commit was made ever. So it shows how much bang-for-buck in terms of my own dev time I get from that particular thing each year. If something has a high RPTD it means I got more revenue for less work. Note that for most of these projects I did no work this year so they have a yearly revenue-per-git-day of infinity!

Looking at these numbers helps me plan for 2023 and keep the motivation up. In the past couple of weeks I made a lot of updates to Hosted Gitea. I've got it to a good place for 2023. I'll do some more work on it in a couple of months time once I see how those changes go.

Right now I'm focusing on new pocket operator apps. First I am building a new free pocket operator app for Android and iOS. I got the idea from a review somebody left where they asked for an app that simply creates a sync signal for pocket operators. So I am working on that and it's almost done.

Once PocketSync is done I'm going to work on some kind of synth or chiptune app. A simple little app you can use with your pocket operator to add synth lines and melodic texture. That app will be paid and open source. I'm hoping to have both of these apps out by the end of January.

Two other things I am doing in 2023. First I am drawing one doodle per day to keep the drawing muscle fit. Second I am open sourcing any new projects I start. I am going back to my old open-source-by-default way of working.

I'm looking forward to another fun year hacking on this stuff!

Mastodon is a real breeze to develop for. I was able to use nbb (Clojure scripting on Node.js) to post an image using the API in a few minutes. Here's how.

Step 1: Create a new Mastodon app.

Go to Preferences -> Development -> New Application, or visit /settings/applications/new on your Mastodon server.

Step 2: Store the access token

Once that is done copy the "Access token" and your server's URL. Put them in an env file:

export MASTO_ACCESS_TOK=...
export MASTO_SERVER=...

Get these into your current environment (or use direnv etc.):

. ./env

Step 3: Set up nbb & libraries

echo {} > package.json
npm i nbb masto

Step 4: Create the code

In a file called post-image.cljs put the following code:

(ns post-image
  (:require
    [promesa.core :as p]
    [applied-science.js-interop :as j]
    ["fs" :refer [readFileSync]]
    ["process" :refer [env]]
    ["masto" :refer [login]]))

(p/let [masto (login #js {:url (j/get env :MASTO_SERVER) :accessToken (j/get env :MASTO_ACCESS_TOK)})
        attachment (j/call-in masto [:v2 :mediaAttachments :create] #js {:file (readFileSync (last argv))
                                                                         :description "Test image"})
        status (j/call-in masto [:v1 :statuses :create] #js {:status "Hello this is a test!"
                                                             :visibility "public"
                                                             :mediaIds #js [(j/get attachment :id)]})]
  (js/console.log status))

Step 5: Test it.

npx nbb post-image.cljs some-image.png

Congratulations, you now have an nbb script which can post images to Mastodon. Enjoy!

It's been a while since I posted an update. So this is it! The tl;dr is I'm working on a sound effects generator micro-SaaS and I am nearly ready for launch.

In February this year I was working on the iOS port of one of my music apps when I decided to pivot. Safari iOS bugs were taking a lot of time and really dragging me down. I decided to focus back on pure web based music applications. I love the web and I love making web audio apps.

I decided to convert one of my online web audio apps to a subscription micro-SaaS business. To do this I had to build a bunch of infrastructure. I was tinkering with server side ClojureScript and my new web framework, Sitefox (here is an interview I did about Sitefox on the ClojureStream podcast: https://player.fm/series/clojurestream-podcast-2504492/e75-sitefox-with-chris-mccormic).

I really wanted to build everything on top of this highly productive stack. So I made a plan:

1. add authentication to Sitefox (ClojureScript backend web framework).

2. make it easier to integrate Stripe (new library).

3. use those two pieces to convert some existing apps into micro-SaaS apps.

4. 🌱 open source as much as possible.

I've been carrying out this plan since February. I've added authentication to Sitefox and I've also made a Stripe integration library. Now I am in the process of doing #3 - converting an existing web app into a micro-SaaS app.

The app I have chosen to convert is a sound effects generator called Jsfxr. This is a wonderful little piece of software written by Eric Fredricksen. I started contributing to, and eventually maintaining this public domain codebase some years ago. At one point I put it up online under the domain sfxr.me. Some years later I checked the stats of the site and it was getting more than ten thousand hits per month. Wow!

Software developers generally hate marketing. We just love to build stuff. But it's difficult to get people to use the thing you have built, without resorting to all kinds of unpleasant shenanigans like telling people about what you built, and communicating with other human beings.

So discovering my existing site already had traffic was exciting. All I have to do is build something that the visitors might want. So that's what I've been doing - I've been working hard on a Pro version of Jsfxr. It's going super well. It has been really fun to work on this codebase using an all-ClojureScript stack, and I am just about ready for launch.

If you're interested you can read a log of the development process in this Twitter thread. I will post an update when it's ready for launch.

Thanks for tuning in!

Dear YouTube,

What the actual heck? Here I was, innocently demonstrating how to install Nextcloud on a Linux VPS server. I just want to help other people liberate their data. Nextcloud is super cool and powerful and I want to share the good news. My video got a bunch of views and people seemed to find it really useful. Hooray!

Then suddenly, without warning, you can cancelled my completely innocuous video. I appealed, and you rejected my appeal with no explanation at all. You say my video contains "harmful and dangerous content". Really? What exactly is harmful and dangerous in this video? No reasonable person could find anything in this video that could be construed as "harmful".

Is this really about protecting viewers? Or is it about protecting your parent company? In the opening frames of my video I spoke about replacing proprietary services like Dropbox, Google, and Apple. Was my video cancelled because it's dangerous to users, or because this idea is dangerous to your parent company?

The only remotely harmful and dangerous thing here is that people might switch away from centralized services like those provided by your parent company, to Free, Libre, and Open Source Software provided by awesome hackers working in the public good.

Of course, I have no recourse now. Your interface does not allow me any way to speak to a human being about this. I feel completely powerless to do anything about it.

I've read about this kind of thing happening to others, many times on Hacker News. I always thought it was just bad luck and that will never happen to me. I have also read this exact thing from people this happened to previously.

Here is the original video, hosted on Vimeo, just so everybody can see exactly how innocuous it is. It's literally a how-to video for installing Nextcloud on an Ubuntu VPS.

So if you're reading this and you host videos on YouTube, I implore you, please make sure you take backups. Make sure you have a second copy of your precious videos. Make sure you have a plan for hosting elsewhere in case you get cancelled too for no good reason.

If somebody from YouTube is willing to un-cancel my video and remove all strikes from my account, I will update this post.

Update: after engaging @TeamYouTube on Twitter the original video has been restored. I did not receive further correspondence from them. To migate against this happening again in future I will mirror my videos on multiple platforms.