Captain's Log: Stardate 77763.3

In the last couple of days I have been on a tear of making small improvements and fixing small bugs. A lot of these things were more in the "polish" category -- things that weren't horrible, but just weren't high-quality. For example, when you created a modulator, it didn't map it to a MIDI controller by default; you had to do it manually. Of course, this is not a big deal, especially since I added "sensing" so you just wiggle the knob to assign it. But for things like pitch bend, where the default channel could be set to "all channels," which will work 99% of the time, it was just stupid to make the user select that instead of providing a good default. So not big things, but small annoyances.

In other news, I hesitate to mention it, because I don't want to get anyone's hopes up, but I think I had a breakthrough in terms of figuring out how to make Anukari do easy polyphony. Today, every note you want to be able to play has to be manually added as an Exciter. This has its advantages -- you can create instruments where all the notes are connected, like a handpan, so hitting one part of the instrument creates a fundamental pitch, but also resonates with other parts. This is something unique to Anukari and really important.

But... sometimes you want to just create a little widget out of a handful of masses, and then you wish you could just play that with all 88 piano keys. Which today is a pain: you have to copy it, tune it, etc.

The breakthrough is that I realized that instead of doing crazy ML stuff to tune the 88 keys for you, I can probably just do polyphony by creating virtual instances of the physics model for each note and then using time dilation to get the right pitch for each one.

Anukari is fundamentally a stepwise physics simulation, or an Euler integrator for people who like fancy words. That means that for each audio sample, a time variable is stepped forward by, say 1/48,000th of a second (for a sample rate of 48 kHz), and the physics objects are moved forward in time by that amount.

But: what if for each 48 kHz sample you advanced the time step by 1/24,000th of a second? You'd still be computing 48,000 samples per second, but the simulated system would be advancing through its "pocket universe time" at twice the rate of real time. Which means the pitch it produced would be twice as high -- an octave higher.

This is extremely simple, and I think it should be able to reliably produce all the pitches based off a single system. Now, there are some edge cases to handle. For example, while the physics should use time dilation, you probably don't want to use it for, say, envelope timing. When the user said that the release was 1s, they meant 1s and not "1s relative to a dilated time reference." Another issue is damping: probably you want to change the damping proportionally to the time dilation, so that the higher notes ring out as long as the lower notes.

But the edge cases all seem straightforward to handle. If this works, it will make Anukari dramatically simpler to use for the simple cases. And it will be a configurable option -- "time dilation instanced mode" can be turned off if you wish to create a singleton contraption where everything is connected to everything.

Hopefully sometime soon I can verify that this all works how I expect. Very exciting!