Captain's Log: Stardate 78738

In my last update I wrote about how I had gotten the website mostly ready for accepting payments for the public Beta. Since then, I have spent most of my time working on Anukari itself.

Demo mode

Anukari now has a working free demo mode. When there's no valid paid license, it operates normally with all features available, except that periodically the output sound is significantly ducked and some white noise plays, so that you can try everything out and hear how things sound, but can't really use it for anything productive.

Originally I started with just adding periodic white noise, but what I found was that on different speaker configurations, the same level of white noise varied from "not that motivating" to "shockingly loud." When Jason first tested the demo mode, the white noise was so loud that it startled him. That's no good! So the new mechanism where the gain on the plugin output is ducked is much better. The white noise can be a lot quieter in an absolute sense white still being loud relative to the plugin signal.

In addition to the periodic noise, the demo mode shows a little "DEMO MODE" panel with a "buy now" button and a button to register if you already have a product key. This panel pulses brightly during the white noise periods, to hopefully make it super clear that the noise is related to the demo mode, and the plugin's not just broken or something.

First-launch flow

For users that have paid for Anukari, I don't want them to always have to go through the free demo mode to unlock it, which seems mildly annoying to me. So I added a first-launch dialog flow where you can choose to launch the free demo, or you can just directly enter your product key and skip that.

I've wanted this flow for a long time, since it does some other nice things. One really important part is that it prompts you to pick an initial 3D visual theme. Our 3D artist, Amfivolia, made a ton of cool skins and skyboxes, and we were debating what the best default was. I came to the conclusion that this is not a one-size-fits-all scenario, and the best thing is to let the user pick the starting skin. This also serves to let the user know that the 3D graphics can be customized, which might not be otherwise obvious.

Preset chooser

Jason has been working to create a bunch more presets, and at this point he's as much of a power user as I am. He brought to my attention how annoying it was to audition presets by going to File > Open > Factory > click for each preset, and he also pointed out that the lack of folders for organization was a pain. He suggested adding a simple preset chooser widget.

I was a bit reluctant to add any feature with the Beta so close, but I decided to hack together a quick version of the chooser, and immediately I realized that it was very worth including this as a feature in the Beta. It makes it dramatically easier to try a bunch of presets, which is exactly what I want people to do for the free demo.

I've spent a lot of effort over the last couple of years to make Anukari load really quickly, both at cold start, and when opening presets. And all that work paid off when I first started mashing the "next preset" button -- cycling through presets is virtually instantaneous, even for huge, complex ones. It is really satisfying.

Preset properties in the accordion

Another thing that Jason pointed out was that the "Options > Preset properties" menu was a little bit buried. This menu contains the settings for the polyphonic instancing mode, global pitch controls, MPE settings, etc, and it was pretty hard to discover. And despite the name of the menu, it was still a little unclear that it was preset-specific.

Again, I was hesitant to slow down the Beta by changing this, but the fix I had in mind involved some noticeable visual changes, and Jason is working on tutorial videos as well as screenshots for the user manual, etc, and especially for the videos I wanted to get any big layout changes done so that the videos aren't out of date immediately.

The big improvement here was something I'd wanted to do for a long time but was never certain about until now: I moved the "Master" panel with master gain, etc, which used to be a fixed rectangle in the lower right of the window, into the property-editor accordion. So instead of a fixed box taking up a bunch of valuable pixels, the Master panel is now a "Preset Properties" panel that can be fully-collapsed.

This has two major advantages:

1. Since the Preset Properties panel is in the accordion, it can now scroll, and so the stuff that was formerly buried under "Options > Preset preferences" is now directly available from the main screen.

2. The Preset Properties panel can be hidden completely, and thus the entire vertical real estate on the right-hand side can be opened up for editing other objects. Especially for objects with a lot of properties, like Mics or Oscillators, having all this space available to see the properties is really nice.

What's left for the Beta?

The website and Anukari itself are both pretty much ready for the Beta. There are a couple of small bugs I want to resolve, but nothing big.

So now the remaining pieces are mostly non-engineering details. Jason is going to finalize the new factory presets, which should bring us close to shipping with 200 presets. He's also working on tutorial videos and a first-time walkthrough video.

And I am starting to work on the Beta launch video for YouTube. My plan is to make something similar to the original "Introducing Anukari" video from 2023, but updated to announce the Beta, and show off all the stuff that Anukari is capable of now.

So... we're getting close. :)

Captain's Log: Stardate 78612.4

I was pleasantly surprised to find that getting Anukari working as an AAX plugin was pretty straightforward. I mean, I would have preferred if Pro Tools would just support VST3 instead of this ridiculous song and dance of having their own custom plugin format. But it could have been a lot more painful, so I shouldn't complain too much.

There were some moderately annoying logistics around getting an iLok key, and getting the right licenses/certificates from PACE to be able to sign the AAX plugin. It all felt faintly silly, because I'm already signing all the DLLs and .exe files with OS certificates on both Windows and MacOS, and one might imagine that PACE would just work with the OS certificates. But I guess PACE wants more control over things than that.

Overall my biggest takeaway from my interaction with PACE/iLok is that things are what you'd expect from an anti-piracy company that sells software: the anti-piracy seems to be the main feature and the fact that you actually receive software that does something music-related is just an accidental byproduct. I guess I can understand why pro shops like the iLok, since it allows for a uniform licensing solution with offline access, but from a consumer perspective it is massively overcomplicated.

Ranting aside, it does seem that JUCE really does deliver on the promise of seamlessly producing plugins in each of its supported formats. I don't think that I ran into any case where a problem showed up in the AU or AAX version of Anukari that was JUCE's fault, which is pretty impressive.

One nice thing about the AAX port is that it helped me find a couple of lingering bugs that also affected VST3 and AU, but we're easy to reproduce in any of the 15 DAWs I've been testing against. Pro Tools does things in a way that JUCE's APIs do document correctly, but I had just never really accounted for. So the fixes for Pro Tools also fixed some issues that I've been having trouble tracking down in other DAWs.

With the AAX support looking good, now I really need to focus on creating more presets. I think that a good body of presets is currently the biggest blocker for starting to talk to distributors, which is pretty exciting!

Captain's Log: Stardate 78553.4

Stability

Since my last devlog update, one big thing I did was to just run the chaos monkey 24x7, fixing crashes it caused until it couldn't crash Anukari any longer. It found some highly interesting issues, including a divide-by-zero bug that has existed since probably about the 3rd week of development on Anukari, in the graphics code. In each case where it found a crash, I tried as much as possible to generalize my fixes to cover problems more broadly, and this strategy seems to have paid off as at the moment the chaos monkey hasn't crashed Anukari in about 48 hours of running.

AnukariEffect

In between solving new crashes from the chaos monkey, I continued to work on launch-blockers, one of which was finally creating a second version of the plugin that allows it to be used as an effects module in a signal chain (rather than as an instrument). This is a bit annoying, because the VST3 plugin actually is perfectly capable of being used in either context, since it dynamically determines how many audio inputs it has, etc. But most DAWs simply don't support plugins that can be used either way.

So now there is a second AnukariEffect plugin. This works great, and it's really nice to be able to just drop AnukariEffect into a track as an effect without having to do complicated sidechain stuff to use it that way. I made a couple of initial effect presets, and already it's producing some extremely cool sounds. I'm very excited about this.

A bunch of small work remains to make AnukariEffect nice to use. For example, the GUI needs to have some subtle changes, like adding a wet/dry slider, hiding controls that have to do with irrelevant MIDI inputs, etc. Also, because it doesn't receive MIDI input, AnukariEffect will only do singleton instruments and not voice-instanced instruments, so I need to put some thought into how to handle edge cases like what to do when the user loads a voice-instanced instrument in AnukariEffect. I think it will likely get converted to a singleton with a warning message to the user. But I need to experiment a bit to find what feels right.

CPack

The introduction of a second VST3 (and AU) plugin necessitated some changes to the installers. Also, separately I am working on getting an AAX plugin up and running. So I realized that now is the time to really get the installers working correctly, allowing the user to e.g. install only VST3 and not AAX, etc.

I had originally used CMake's CPack for generating the installers, using the INNOSETUP generator for Windows and the productbuild generator for MacOS. This seemed really convenient, because I didn't want to learn how to use Inno Setup / productbuild directly, and it looked like CPack could generate the installers without me having to get into the weeds.

In the end, I really wish I had never tried using CPack's generators for this. They are horrible. Basically the problem is that both Inno Setup and productbuild have fairly rich configuration languages, and CPack's generators expose perhaps 10% of the features of each one in a completely haphazard way. So it seems convenient, but then the second you need to configure something about the installer that the CPack authors did not expose as an option, you're completely hosed. Originally I tried to work around the CPack limitations with horrible hacks, such as a bash script that wrapped pkgbuild and took some special actions. But this was a complicated mess and didn't work well.

So for both Windows and MacOS, I decided to just bite the bullet and learn how to use Inno Setup and productbuild/pkgbuild directly. And as it turns out, in both cases, it is much simpler to just go straight to the nuts and bolts without the CPack generators. It resulted in less config code overall, with less indirection, no hacks, and I was able to configure the installers exactly how I wanted.

Frankly at this point I can't see any argument for why anyone would want to use CPack. It's substantially more complicated/obfuscated/indirect, limits you to an eclectic subset of each installer's features, and it truly was harder to learn how to configure CPack than to just figure out Inno Setup and productbuild/pkgbuild. The documentation for the installer tools is way better than CPack's documentation, and anyway, to use CPack you kind of have to understand the installer tools anyway.

So the end result of rewriting the Windows and MacOS installers without CPack is that they both work how I want now, and will be a lot easier to maintain as I continue to get closer to release, adding the AAX plugin and so on. I'm very happy that installers are now a "solved problem" -- one more box checked for the launch.