So this is… Week? Month? Four? Issue? Serial?
Post #4
Things continue, life, time, stream, gaming, all of it (even unfortunately, high-tension world politics).
I’m not going to pretend I’ve cracked the code on regular posting. What I have worked out is that “week two” was never going to happen and that beating myself up about it was costing me more time than the writing ever did. So: this is post four. It covers roughly a month. If the next one lands in a fortnight, brilliant. If it lands in five weeks, you’ll get a title with more question marks in it and we’ll both cope.
What I can say is that this month has been the least scattered one in a very long time. Not the most productive by raw output, necessarily, but the most deliberate. Fewer projects on fire at once. More things actually finished. A schedule that I’m cautiously optimistic about (more on that at the bottom, it’s the bit I’m most curious to hear opinions on).
Multistreaming and content creation
I’ve now expanded my content/streaming footprint (as you may have noticed) onto some extra platforms, multistreaming to YouTube, Kick and X. As I continue getting back into regularity - trying a new schedule to see if that one can stick better - I will also be looking for clips to edit and put up as shorts for TikTok/Facebook/YouTube.
The multistream side of it has settled down a lot since last post, when it was still mostly held together by hope and a mixer I didn’t trust. It works now. Titles are actual titles. Levels are actual levels. The links in the footer of this site point where they’re supposed to point.
The bit I haven’t solved is the clipping workflow. Right now the plan is !clip in Twitch chat to drop a marker while I’m live, then go back on my off day and pull those markers into something short and vertical. That’s the theory. The practice is that editing is a completely different skill to streaming, and I know full well that “I’ll edit it later” is the exact sentence that has killed about forty of my previous projects. So it’s going on the schedule as an actual named task rather than a vibe, and we’ll see whether that’s enough to make it real.
If you’re watching and something funny happens, !clip it. Genuinely. You have better timing than I do, because I’m the one distracted by whatever caused the funny thing. Also, you don’t need to edit or name it, I set that command up to effectively just mark the VoD so I can find the moments later in Twitch’s editor.
VPS
I got myself a server.
Not a “server” as in the old tower under the desk with a fan that sounds like a hairdryer with a grudge (though, respect, I’ve had a few of those). An actual rented VPS - a virtual private server, which is a slice of somebody else’s very large machine in a very cold room, that behaves for all intents and purposes like a Linux box I own. I SSH in, I install what I like, and it stays up when my PC doesn’t.
Why not just use the managed services?
The honest answer is that I priced it up and got annoyed.
The thing that pushed me over was game server hosting. If you want to run a modded server for you and your friends, the friendly managed hosts will absolutely sort you out, and they’re genuinely good at it - one click, a nice web panel, done. But you’re renting one game server, priced per slot, per game, per month. Want a second game? That’s a second subscription. Want to keep both around so people can bounce between them? Now you’re paying for both, permanently, including all the weeks nobody touches either of them.
For roughly what one of those costs, I can rent a general-purpose box and run several things on it. Not because the VPS is magically cheaper per-game, but because it isn’t sold per-game. It’s just compute. What I put on it is my business, and the moment a server goes quiet I can stop it and put those resources somewhere else, without cancelling a subscription and losing the world save.
There’s also a quieter cost that never shows up on the pricing page: with a managed host, the moment you want to do something slightly unusual - a mod loader they don’t support, a custom start script, a scheduled backup to somewhere you control - you’re either paying for a higher tier or you’re out of luck. On my own box, “slightly unusual” is just Tuesday.
Privacy and control (the actual reason)
Cost was the excuse. Control is the reason.
I’ve been quietly uncomfortable for years with how much of my stuff lives on platforms I don’t own, under terms that change while I’m asleep. It’s not a tinfoil-hat thing. It’s that I’ve now got a decade-plus of projects, notes, half-finished ideas and design documents, and I’ve watched enough services get bought, pivoted, enshittified or simply switched off to know that “it’s in the cloud” and “it’s safe” are not the same sentence.
So the big one for me: my code now lives on my own git server. Everything - every project in the workspace, all the design documents, the whole tangled lot - pushes to a private repository hosted on that box, over an encrypted connection, on hardware I’m paying for directly. No public mirror, no third party scanning it, no terms of service update deciding my private work is now training data for something.
To be clear, I’m not anti-GitHub - the public projects (see below) will absolutely end up somewhere public, because that’s the entire point of them. What I wanted was a choice. Public because I chose to publish it, not public-by-default because that was the path of least resistance.
The other things it’s quietly good for:
- It’s always on. My PC gets rebooted, updated, put to sleep, and occasionally crashed by me doing something ambitious. A thing that needs to be reachable at 3am shouldn’t live on the same machine I game on.
- It’s a sandbox I can break. I can install something horrifying, watch it fail, and wipe the whole thing back to a clean image without touching anything I care about. That’s enormously freeing when you’re learning.
- It separates “my desktop” from “my infrastructure”. Which, if I ever want the AI projects to talk to each other across devices, is a distinction I’m going to need anyway.
The honest downside, and I want to say it out loud because too many people gloss over it: it’s all mine now. Updates, security patches, firewall rules, backups, certificate renewals, the lot. Nobody’s coming to fix it at 2am. The managed hosts charge what they charge partly because somebody else carries that pager. I’ve decided that trade is worth it for me right now, mostly because the learning is the point as much as the hosting is. If you just want a Minecraft server for your mates this weekend, genuinely, go pay the managed host and enjoy your weekend.
Development work
Here’s the awkward part of writing a dev blog for projects that aren’t public yet: the more real the work gets, the less of it I can show you. Last post I told you the impossible AI thing was running on a phone. This month is the sort of work that doesn’t screenshot well - plumbing, protocols, and the deeply unglamorous business of two devices agreeing on what’s true.
So, hints, in ascending order of vagueness.
The music player
The most visible progress is on the thing I keep calling “my mp3 player”, which is an insultingly small name for what it’s turned into.
The shape of it: my PC holds the real library and is the boss. My phone and tablet hold whatever subset I’ve told them to hold, and they’re managed children - they never go rummaging through the device’s storage, they only ever touch their own little sandbox. Everything talks over my own network, to my own machine. No cloud, no account, no subscription, no algorithm deciding what I want to hear next.
This month that stopped being a design document and started being a thing that actually works. The PC now runs a small server that the phone can find on the network by itself, and the two can go through a proper pairing handshake - a code appears on both screens, I confirm on both ends, and the phone becomes a named account with its own permissions. Not a password typed into a phone keyboard. Not a shared login. An actual “yes, that device, the one in my hand, showing that number.”
Which matters more than it sounds, because the whole point of the design is that multiple people can use one library and not step on each other. Your play counts are yours. Your ratings are yours. Same music, separate opinions about it.
My favourite rabbit hole of the month, though, was the volume slider. I’d been quietly irritated that the bottom fifth of the bar did basically everything and the top four fifths did nothing - drag from 40% to 90% and it barely got louder. Turns out that’s because the underlying control is a raw multiplier, and human hearing is emphatically not linear. Half the number is nowhere near half the loudness. So I ended up down a very deep hole reading about perceptual loudness curves, and the slider now maps to how loud something actually sounds rather than to a meaningless number. Halfway along the bar is now genuinely about half as loud. I also stole the colour bands off an OBS audio meter for it, on the grounds that I’m going to be looking at both while streaming and my brain should only have to learn one scale.
That is the most niche thing I have ever been proud of and I’m at peace with it.
The story engine
Progress, but the quiet kind.
Last post’s headline was that a real open-source language model runs entirely on-device, offline, in my hand. That’s still true and still the foundation. What’s happened since is that the rest of the system has started to take shape around it - the part that actually solves the problem I ranted about in the very first post, where an AI loses track of the fact you dropped your sword two scenes ago.
The bit I can say: the hard problem was never “make the AI cleverer.” It’s memory. It’s knowing what’s true, when it became true, and what should happen to the story when two things that are both “true” contradict each other. Most of my design time this month has gone into that model - how facts get stored, how they get retrieved when they’re relevant, and crucially how the system flags a contradiction for a human instead of quietly picking one and hoping you don’t notice.
And a lot of that groundwork is deliberately shared. The music player is, in a slightly ridiculous way, the proving ground for the story engine - two devices, one truth, syncing changes made offline, merging them without losing anything. If I can prove that to work reliably for play counts and playlists, where the risk is a wrong number in the UI, then I can trust the same patterns and extend them to a story where the risk becomes someone losing their manuscript.
That’s why the music player is first. It’s not a distraction from the big project. It’s the load-bearing rehearsal.
The public stuff, and an actual roadmap
The little public open-source tools I mentioned last time are still coming, and there are now a few of them queued up - all small, mostly unrelated to the AI work, all born from “I wanted a thing, the existing things annoyed me.”
One habit I’ve picked up that I’m weirdly pleased with: each of them ships with a process.md alongside the README. Not the code documentation - a plain-English record of how the thing came to exist. What the original problem was. Which existing tools I tried and precisely why I bounced off them. What questions got asked before a single line was written, and what the answers changed. Where the design was wrong on the first pass and what corrected it.
Partly that’s for me, because I have a documented history of returning to a project six months later with absolutely no memory of why I made a decision, and then re-making it worse. But partly it’s because I think that stuff is genuinely more useful to a stranger than the code is. Anyone can read the source. Almost nobody gets to read the argument that produced it.
The next step there is a public roadmap. Right now everything lives in my private design docs, which is great for me and useless for anyone who wants to know whether a thing is coming next month or next year. So I want a board - Trello is the obvious candidate, and I’ve used it before, but I’m equally tempted to just use the issue tracker and project boards that come bundled with the git server I’m already running, since that keeps it next to the code and doesn’t hand another company a map of everything I’m working on. (I’m aware that’s a slightly funny position to hold about a public roadmap. I contain multitudes.)
Either way, the intent is the same: a visible, honestly-maintained list of what’s in progress, what’s next, and what’s parked - including the things that have been parked embarrassingly long. If you’ve read this blog before you know I’m not short of items for that last column.
Schedule…?
I’ve somewhat landed on a new way to schedule myself, as task-switching is proving lets say, ‘Problematic’ on my ADHD meds and I was constantly feeling like one thing or another was falling by the way-side as a result.
The medication is working, to be clear. What it doesn’t do is make switching between three different kinds of work in one day free. If anything it’s made the cost more obvious - I can now feel exactly how long it takes to get back into something after being pulled out of it, and it’s a lot longer than I’d like to admit. So instead of fighting that, I’ve stopped trying to do everything every day and given each kind of work a whole day of its own. Three-day cycle, on repeat:
Day 1 - WORK DAY. Based on the plan I made in the previous Day 3. Target 8-12 hours of good production time, sometimes more IF I feel good about it. Make sure the VPS is properly working and updated ready for…
Day 2 - STREAM DAY. Check steam release updates, look at sleep schedule, decide live timeslot whenever makes most sense, consider buying a cheap game to check out. TARGET live window is ~6 hours between 1200 and 0000 UTC, but I might also extend the window a few hours either side depending on where my sleep is landing at the time (watch Discord for updates).
Day 3 - RECOVERY / ADMIN. Address issues found or ideas penned during stream on Day 2, look at any clips or markers (made with !clip in Twitch chat) for content I can edit into a short and upload to TikTok etc. Plan the next Day 1, chill, hang out in streams, play games, check finances and update my balance spreadsheet, update this blog (maybe even every ‘Day 1’). Easy day, decompression, IRL tasks etc etc, CHILL is the key here.
HOPEFULLY this schedule will be easier for me to manage, not trying to take on too much in one day, leaving ample casual time for me to do things ad-hoc. I feel like a minimum of 1/3 of my time on projects and another 1/3 on streaming, should make it feel like I’m not just forgetting them. It’s also not as if I HAVE to not do any work or content uploads/editing on the Day 3 either.
The two things I think will make or break it: the plan has to be made on Day 3, not on Day 1. If I wake up on a work day and have to decide what to work on, I’ve already lost two hours and quite a lot of will to live. Deciding while I’m relaxed and deciding while I’m supposed to be executing are completely different activities and I am much worse at the second one.
And the other: a three day cycle doesn’t line up with a seven day week. Which is either the best feature of this system or the thing that kills it stone dead, and I genuinely don’t know which yet. It means my stream day drifts across the calendar, which is terrible for anyone trying to remember when I’m live, and excellent for a brain that has never once respected the concept of Monday. The compromise for now is that the Discord gets told when the live window is landing. I do fully intend to try and cement my streaming days at some point in the future, but I honestly can’t yet predict when that might be.
Maybe? I’ll have something more specific and concrete to tell you in 3 days time? Perhaps 6, if not much happened or no new milestones have been reached.
TTFN o/