Today I finished adding an on-screen tuner. This is something that I've wanted for a long time, but always put off because it was easy enough to use e.g. the Ableton tuner or even my guitar tuner app on my phone, etc. But both of these solutions are somewhat annoying in different ways.

I really did not want to become an expert on pitch estimation algorithms, so I researched a bunch of libraries that provide pitch estimation and systematically went through and evaluated them. One annoying factor was that over half of the libraries out there, especially the ones written by academics, used the GPL3 license, which means they're a no-go for a commercial project such as mine. (This is fairly annoying because I'd guess many of academics didn't realize they were hugely restricting who could use their sample code.)

That said, most of the academic pitch estimation code is total shit, so it wasn't the biggest loss. I'm sure the algorithms are amazing, but calling malloc() 8 times per sample buffer when it could very easily be avoided is just stupid.

In the remaining group of actually free -licensed code (MIT / BSD mostly), a lot of it was also total shit. There are a bunch of projects that are evidently hobbyists who had fun implementing pitch estimation papers. Which is fun, but also not useful.

Some of the projects that looked sort-of OK just didn't work. The best MIT-licensed pYIN estimator I found was unable to detect frequencies above about 2.7 kHz (and that was after a bunch of tweaking).

Anyway, I finally settled on https://github.com/cycfi/q. It's well-implemented, easy to use, has a good cmake configuration, and best of all, their pitch estimator works extremely well. It's super fast and stable.

Here's what the tuner looks like.

DAW/host parameter support is finished, including golden tests, etc. Everything works how I'd like it to.

The golden tests were slightly interesting. Since, obviously, a MIDI file can't contain host automation, it wasn't immediately obvious how to write golden tests for this. My first thought was just to hard-code a few automation events and do the tests that way. But what I came up with was a little config parameter that lets the golden tests request that specified MIDI continuous controller #s be translated to host automation inputs.

So, in Ableton, I created the test preset and set up some automations in two lanes. Once I got this working how I wanted, I copied and pasted the automation lanes into MIDI CC 1 and 2, and exported the MIDI file. Then in the golden tests, I mapped CC 1 to automation lane 0 and CC 2 to automation lane 1. The golden test produced exactly the output it was supposed to. This gives me a lot of flexibility in how to test this kind of thing.

Aside from finishing the host automation stuff, I tracked down and fixed a bug where undo/redo worked, but the right-hand side panel didn't update to reflect the changes from undo/redo unless you cleared the selection and re-selected the entities. This ended up being a nasty bug in the subscriptions code, which caused (a) some subscribers to see irrelevant changes, and (b) some subscribes to miss changes intended for them. Strictly speaking, #a was a problem with the subscriptions code, and #b was a misuse of the subscription API. But even the API misuse was because the API was bad. Both of these are fixed, and tested.

I made huge progress in the last couple of days on adding support for DAW/host parameters to Anukari. These are the host automation parameters that flow through VST/AU/etc directly, instead of being transported to the plugin via MIDI.

Overall this has been fairly straightforward, based on all the work that I got done to make the MIDI control plane complete. There were some slightly tricky issues regarding thread safety, since it does not appear that many (any?) guarantees are made about which threads can call into the plugin to notify it that an automation value changed, or when. And the documentation around what kind of parameter name strings all the DAWs will accept is frustratingly sparse. So I imagine that even after this is all working perfectly in one DAW, I'll have to do a bunch of testing in other DAWs as well.

But challenges aside, it's working in a basic way. I can create automation in Ableton and it is wired up to modulators in Anukari that change parameters. And you can change the name of the modulator in Anukari and have that new name show up in Ableton.

The way it works is that there are a fixed number of automation "slots" (32 right now), and at startup Anukari always notifies the host that there are 32 parameters with generic names like "Param1". By default these don't do anything. But when a user creates a Modulator and sets it to the "Host Parameter" sub-type, they get to pick which "slot" it's associated with. So if they pick slot #1, that Modulator will pick up values sent by the DAW to Param1. Then the user can edit the name to something better than Param1.

This goofiness is the best way I've come up with to guarantee that the mapping between the DAW and Anukari is perfectly stable in all DAWs, because DAWs do not support dynamic creation/removal/reordering of parameters.