Captain's Log: Stardate 78294.1

DAW Licenses for Testing

After releasing the pre-alpha version 0.0.8, I got feedback that Anukari was crashing as a plugin in Bitwig. This reminded me that I hadn't done a detailed check on DAW compatibility/stability in a while, so I sat down to do that.

The last time I did this was in the first week after starting the pre-alpha, and I did it by installing the free trials for a bunch of DAWs. Unfortunately, in the intervening 6-8 weeks, all of the free trials had expired. So, for example, I was hosed in terms of debugging the Bitwig crash locally.

So I decided to email the top 10 or so manufacturers for DAWs that I'd like to test against, and asked them if they would give me a free copy of their DAW for this purpose. I'm not sure exactly what I expected to happen here, but I definitely didn't expect for them to universally say "yes," which is what happened. So far, every manufacturer that's responded has not only given me a license key, but given me a key for their top-of-the-line product with all the extras. For example, Reason Studios not only gave me Reason 13, but also unlocked their entire line of plugins. Which is incredibly generous, and also unnecessary. But I won't complain.

It turns out this is a normal thing in this kind of industry, and there's even a special kind of license for it: "Not for resale" (NFR). Which makes sense; given the purpose of the license it would be ridiculous to go off and resell it.

Anyway, this is great news, as I now have 13 of the most popular DAWs installed on my Windows development machine, and after some work, have gotten Anukari working in all of them with no crashes. I haven't installed them on MacOS yet but I'll do that soon as well.

The Most Fun Compatibility Bug

The crash in Bitwig was somewhat interesting. What was happening is that Bitwig actually initializes the DAW GUI before it has created a native window for it to draw in, and my code was assuming that a native window would be available at that time. Fixing this just required using JUCE's parentHierarchyChanged() method to watch for changes until the native window became available.

The more fun bug was the crash in Cakewalk Sonar. Pretty quickly I figured out that the crash was happening when Anukari called SymInitialize(), which is a Windows API function that you can use to include symbols in crash logs, which makes them vastly more usable. This function has the user-friendly property that if you call it twice in a given process, it crashes on the second call. It's a bit surprising to me that Cakewalk is the first DAW I've run into that calls this function, since it's quite useful, but it is.

The obvious thing to do is for Anukari to somehow check whether SymInitialize() has been called and don't call it. But I read through the Windows docs and didn't find any way to do this, and Mr. ChatGPT stated very confidently that it was not possible. Still, I wasn't convinced and kept Googling, and eventually found this tweet from my programming hero Jonathan Blow (the creator of the amazing video games The Witness and Braid). His initial tweet summed up my frustration over the impossibility of the situation, but someone eventually replied with a solution, which is to call SymEnumProcesses ().

Now, this is a damn sight better than blindly calling SymInitialize(), which guarantees a crash if the DAW already called it (like Cakewalk Sonar). But... it's still technically impossible to do it safely. This is because calling SymEnumProcesses() concurrently from two threads is not safe, and of course Anukari has no way to know whether any other thread running in the DAW might call it. Still I went with this solution, because it is unlikely that anyone else is calling this function, and if they are, it's unlikely that it is concurrent with Anukari, and even if so, Anukari is calling it in a read-only kind of way, so maybe it wouldn't crash anyway. Hopefully. :)

Captain's Log: Stardate 78280.5

The last couple of days I continued to work through the various bugs that I had noted with the new Filament renderer. In particular, what I was looking at was that on MacOS with the Metal backend, if I changed the render quality settings enough, eventually I could pretty reliably get it into a state where there were weird graphical glitches like the one below.

I was able to get other weird glitches as well, like everything becoming green-tinted. At first I thought there was some specific configuration that caused it, but eventually I realized that it was kind of random, and really difficult to pinpoint exactly how to reproduce it. Sometimes things would work fine until I moved the camera around a bit, and then it would go corrupt.

The first thing I tried was to strip down my renderer to the absolute basics, getting rid of any code that wasn't absolutely necessary to reproduce the issue. This was disconcerting, because I was able to remove nearly all the renderer code and still get glitches.

The next thing I tried was to reproduce the glitches in one of Filament's demo apps, the gltf_viewer. I tried and tried and nothing I did would cause the glitches.

I started looking for any difference between how the gltf_viewer and Anukari worked. The way we set up the CAMetalLayer is different, so I transplanted my CAMetalLayer code into gltf_viewer, and it worked just fine.

Next I started from the other direction: removing things from gltf_viewer one by one until something weird happened. It took quite a bit of trial and error, but I found that when I removed the code that configured the renderer to clear the pixels before a render pass, I could get weird corruption to happen.

This is pretty weird, since in a 3D renderer when you have a skybox, clearing the color channel is unnecessary since you'll be overwriting the entire thing with skybox pixels anyway. But I went back to Anukari and turned on clearing, and it completely fixed the problem. I don't know what the bug is in the Filament Metal backend exactly, but there's definitely something wrong with it.

Anyway, there are no more glitches in Anukari on MacOS, and I filed a bug for the Filament folks to see if they'd like to fix it: https://github.com/google/filament/issues/8229.

Captain's Log: Stardate 78099.9

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.