Things are going good with the Windows pre-alpha release. The installer works properly now, and the new distinction between "factory" and "user" presets (you can't overwrite the factory ones) works well. There's a bunch of tiny small new features like an About menu. The docs for the changelog, known issues, and 3D controls are all done. And I fixed a bunch of small bugs that I introduced recently; for example the VST plugin was crashing hard at startup, since I hadn't tested it in a couple weeks.

MacOS is next, and it's in decent shape but there are more issues there. Some weird things have cropped up, like weird visual corruption when the file chooser menu is launched (no other dialog menus do it). And when it runs as an AU plugin in Ableton on MacOS, switching to the plugin GUI and back to Ableton leaves the system main menu bar in a weird state. I think have have leads on what to do about both of those, but I also suspect a couple more things will come up. On the plus side, vcpkg did just magically work on Mac, so at least I didn't have to wrangle the new libraries. Actually it worked so well that I think I'm going to lean on it more heavily, and move some of what I currently have as git submodules to vcpkg dependencies.

But also, I need to create the MacOS installer. Sadly I don't think I can release as a .dmg file, which would be much easier, because I need to put VST3 and AU files in their correct system locations (which a .dmg can't do). So I need to learn about the MacOS package building tools. Doesn't seem too bad, but it's just another thing to get done.

Getting there... the website now can do all the mailing list management that I have thus far done through substack. I like substack, but it's just not the right tool for what I'm doing, as it's focused on newsletters that make their money via subscription revenue. Plus, substack annoyingly doesn't have APIs, so I can't have a little checkbox on account creation for "sign me up for the mailing list," nor can I have a checkbox on the user's profile page to change the subscription status. So I'm doing it through mailerlite now, which lets me do all that.

In doing that, I discovered that in my typescript code there was a bug where I called an async function (which returns a Promise) without calling "await." This is a horrifying bug. Eventually I found that it is possible to configure typescript-eslint to produce errors about this and other terrible things that you can do with async functions to completely screw yourself. Once I got those lint errors up, I found about a dozen awful bugs from this. My honeymoon period with typescript has worn off -- it is definitely helpful and better than raw JS, but they did not go NEARLY far enough and left lots of footguns lying around waiting to go off.

The next thing I'm musing on is whether I should code up a quick blog for the site. After about an hour of work, I think the answer is "yes," it will be easier to just write my own blog platform than to remember how to use wordpress, style it appropriately, hook it up to my site, figure out their subscription model, ... etc. Of course my blog platform will have almost zero features, and that is fine with me. Just a simple form to edit a post via markdown, and a quick way to view it.

This is making me wonder if I should move this devlog to the website. I think I probably want to -- it has long bothered me that it is not discoverable, and that you need a discord account to see it. I'd much rather that it was out there on the web.

Today I worked to finish some of the website cleanups that I want to finish before going back to the product code.

The biggest thing I did was create some tooling to create the database indexes and schema from TypeScript code, instead of through the MongoDB Atlas GUI. I want this so that it can be in version control, and also so that I can trivially apply the schema to a fresh database when bringing it up. This was simple to do and now the database is looking good.

While working on this, though, I discovered a heinous bug in the next.js server actions handling, which is that if any middleware returns a HTTP error or throws or whatever, the result from the server action function call will be "undefined", instead of an error being thrown. This is really horrible because depending on how your server action works, "undefined" might look a lot like null meaning "there was not an error." The next.js folks don't seem super-motivated to fix this, so I just changed all my actions to return a positive "success" message which solves the issue (because undefined can't ever be mistaken for a positive success like it can for a null).