Captain's Log: Stardate 79603

I mentioned in my last post that I've begun working on a marketing plan for Anukari. I'm feeling pretty optimistic that it will be possible to get a steady trickle of sales going, and I also think it's possible that something more than a trickle could happen at some point. Fundamentally I just want enough sales to fund my continued development of Anukari, but I'd obviously be open to more sales, which could lead to further interesting possibilities.

Either way, I like to plan for success, and so one thing I've been working on is fixing a few small customer support headaches, so that they don't become big headaches in the event of lots of sales.

Long term the biggest thing will always be making sure Anukari performs well and is compatible with as many machines as possible. That is feeling pretty good right now.

Now that the product is not generating so many support requests, the next biggest support issue is with account emails failing to be delivered to users. The chief issue here is that occasionally a user won't receive the email containing their license key after they purchase Anukari.

This is immensely frustrating for the customer. The normal flow is that when they checkout via Shopify, they will receive a receipt from Shopify, and in that email, it says "you'll get a second email with the license key." Obviously I'd prefer for these to be one email, but that's not really possible at this point, and it's not that big of a deal.

But some users get the email from Shopify, and then never get the second email. I am the only customer support person, so this means that if someone buys Anukari right after I got to bed, even if they email to complain, they won't get their license key for at least 8 hours. Awful! Imagine it's Friday night, you're stoked to finally have a few hours to play with some new VSTs, you spend your hard-earned money on one, and then no license key comes until tomorrow. Ugh. I'd be super annoyed. (That said, evidently my customers are saints, because they have all been super understanding.)

Email is a tricky thing. Spam filters exist, and also things like IP reputation are really complicated. I have worked on spam/fraud prevention, so I know how difficult some of these problems are.

When email delivery fails, my first question has always been "did you check your spam folder." Curiously, this has almost never been the case.

The main reason that I've had emails fail to be delivered is that Resend, my email provider, simply chose not to send the emails as requested, due to their global email suppression list. This is a list of email addresses spanning across all Resend accounts, that have hard-bounced or been flagged by providers. If a customer's email somehow ends up on this list, Resend will simply not attempt any email delivery. Resend's help page says that a user marking an email as spam could be a reason for them to be globally suppressed. That means that if another Resend user sends a spammy-email to someone, it might block you from sending email to them later.

I've contacted Resend support about this several times. At one point I was told that I could remove addresses from this global suppression list myself. At other times, the Resend customer support folks had to remove the email address for me. The GUI for suppression seems to have changed a couple times, right now it doesn't look like Resend users can actually request removal from the suppression list. In my case, the GUI stated that the email address that failed delivery had already been removed from the suppression list; however I retried sending the email and it was suppressed again.

Over the course of several contacts with Resend support about this global suppression list, it became clear that Resend sees this as a feature, not a bug. And again, I understand that they have a difficult problem to solve, maintaining good deliverability with multiple users, some of which surely are spammers trying to abuse Resend's platform.

The thing is: to me, Resend has exactly one job, and it is to attempt deliver email when I send it. And sometimes, Resend simply chooses not to even attempt delivery. On purpose.

The email addresses that Resend has suppressed are totally normal, just everyday people, typically on GMail accounts, nothing weird. Shopify's emails invariably get delivered without issue, and then my emails from GMail to respond to their support requests also work perfectly. Perhaps there was a one-time delivery hiccup, or another Resend user sent out some spam. Either way, Resend is being super aggressive about suppression in a way that impacts all their users.

IMO the global suppression list is an incredibly bad design, especially with how heavy-handed Resend is being in populating it. I can verify firsthand that it causes plenty of grief. It's a difficult problem, but there are many approaches to managing reputation for shared email IPs. This one is no bueno.

So after several complaints to Resend without a solution, I migrated anukari.com completely off Resend, to Postmark. Postmark has a very good reputation for high deliverability, which again, is the only thing I actually want from an email provider. As far as I can tell, Postmark does not have a global email suppression list, but instead has per-account per-stream lists, which makes way more sense. Here's hoping that this leads to fewer frustrated customers!

Captain's Log: Stardate 79584.2

Some NAMM Ramifications, or NAMMifications

I've been quite busy (in a good way!) the last couple of weeks, with some of the connections that I made at NAMM bearing fruit in various ways.

One thing I've been working on is some setup for collaborating on a demo video with a popular MPE controller that I won't yet name. This is super exciting since the video will have broad reach, so I am working hard to iron out any remaining wrinkles in Anukari's MPE implementation. And I'm really stoked that a sound designer whom I met at NAMM, Jake Siders is cooking up some amazing MPE presets for the demo.

Also I have engaged the help of a marketing expert, Chris Hayzel. We met at NAMM and immediately hit it off. Anukari is a kind of weird product, and I have some extremely strong opinions on how I want the marketing to look. A huge thing for me is doing marketing in a way that I feel good about, so no used car salesman stuff, no misleading hype, no lies, basically. But also, hey, I think Anukari is pretty cool and I'd like to tell more people about it, and explain it in a way that's fun to learn about and not a bunch of dry technical talk (my forte). So it was important to me to find someone who I felt I could trust with this vision. This is in the early stages, but it's likely that this website is going to undergo a significant metamorphosis in the coming months. I'm excited.

Polishing, polishing, polishing

A lot of people at NAMM were surprised that Anukari is still in Beta, given that it seems like a completely functional product. I think it's almost ready to be called 1.0, but there remain a few small things I want to polish first.

First, there were still a couple of crashes/hangs that I was aware of from user reports.

One hang only happened in Apple's AU validation, only sometimes. This turned out to be a weird issue where if you pass too long of a work cycle time to Apple's Core Audio workgroup feature, the thread won't be created. JUCE has some comments to this effect, and has a supposed workaround, but it didn't work for me. I implemented my own workaround and it fixed the hang. This issue appeared when the AU validation set the plugin up with a huge block size (4096 samples), so the estimated time to process the block went above 50ms, which appears to be the limit where Core Audio loses its mind.

For the crash report, I only really knew that it happened on AMD hardware. So of course I prayed that I could find a way to reproduce it on my AMD test machines, and thankfully I was able to. The biggest hint was that my user said that originally Anukari worked perfectly, but later it crashed on startup. I guessed that they had changed a graphics setting, which was persisted to the preferences file before causing a crash. So then it crashed forever. I had the user delete their preferences file and things worked again! So I went through all the graphics settings and toggled everything until I found that the Reflections feature crashed. I tried to find the root cause, but the Vulkan code involved is so complex that I gave up and filed a bug with the Google Filament folks. Here's hoping they can help.

One improvement I made based on this crash report is that Anukari now waits a couple seconds before persisting preferences changes to disk. This way, if a change crashes Anukari, hopefully it won't be persisted, and Anukari will work when it's restarted.

Some of the other polish work includes audio quality improvements, such as adding a bit of smoothing for LFO retriggers to avoid pops.

MTS-ESP Support

As of the 0.9.25 testing release, Anukari is fully compatible with the MTS-ESP protocol for microtuning using an MTS-ESP control plugin such as (MTS-ESP Mini](https://oddsound.com/mtsespmini.php). This protocol lets users tune all their MTS-ESP-compatible plugins to whatever scale they want, in sync, so they all play in tune. The control plugin can import .scl files, so there are thousands of tunings to play with. People have been asking me for this support for a long time.

Given that I've been busy with NAMM follow-ups and polishing Anukari into a 1.0-ready product one might wonder how I fit in the work for MTS-ESP. I am also surprised! Basically what happened is I ended up with a few hours free where I didn't have enough time to really start a new big task, and was finished with my last big task. And right at that moment I got another email asking for MTS-ESP support. So I just said screw it, let's just see if I can bang that out this afternoon and that way I can say "yes" to the email.

The MTS-ESP site says you can integrate the library in an hour. I was skeptical, but it's mostly true. I had things working at a basic level in less than an hour. I did spend several more hours after that making it work really well, ensuring some of the optional features worked, and writing tests and GUI stuff to make it all professional.

So far users are reporting back that it works great. I tested it myself, and despite not being a big microtuning geek, it was surprisingly fun to try out different scales. I'm glad to have been able to sneak in this feature!

Captain's Log: Stardate 79553.2

NAMM was amazing, but also super exhausting! It took a while for me to feel rested, but finally the idea of writing about NAMM sounds appealing. I'll probably write a few smaller posts with stories.

Today's story concerns a votive candle.

I've been working on Anukari for almost 3 years now. Ever since the very early days, I've been referencing Dr. Julius O. Smith III's CCRMA home page, which is a gold mine for audio processing knowledge. For almost any topic in the DSP/modeling/audio math world, Julius has written something about it. When I browse around his home page, my mind is completely boggled at the breadth and depth of his work. It is truly amazing what Julius has contributed to the audio processing world.

Pretty early in those 3 years, I started referring to Julius as one of the Patron Saints of Anukari. Anukari now has several patron saints, but as far as I remember, Julius was the first. Evidently I enjoyed joking about this enough that Julius O. Smith III became a household name, at least in my household, which is to say that my wife Meg was aware of his name.

For my birthday last year, Meg had a votive candle custom-made for me with Julius' face on it:

I found this gift completely hilarious, and it's been on my desk ever since. It occurred to me to email Julius, but I wasn't sure whether he'd find it funny or extremely weird, so I didn't contact him.

Fast forward to NAMM. The Anukari booth had a ton of traffic, and we enjoyed talking to lots of people and giving zillions of demos. Interspersed with general foot traffic, Clifton Cameron would occasionally bring someone by to take a look at Anukari.

Clifton is a fascinating person. He contacted me over email early after the Anukari beta was released, and has been super encouraging. He's been involved with synths and the synth community forever, and seemingly knows everything and everyone. He's obviously super passionate about synths, music, education, and particularly about the community. It was a pleasure to get to meet him in person.

Clifton is such a nice guy, and he really knows what people are into and what they might find interesting. So when Clifton says, "hey, you should come check out this booth," or, "you should meet so and so," people listen.

So as I said, Clifton brought over a number of very special guests to say hi. Included among them was the illustrious Nicholas Porcaro, of moForte and CCRMA, and more. Nick was super curious about Anukari, and we had a really fun conversation about audio software.

From left to right: David Landin, Clifton Cameron, me, Nicholas Porcaro

From left to right: me, Nicholas Porcaro

At some point Nick said something about a "Julius." My ears perked up. I clarified... was it the Julius? Yes! It turned out that Nick and Julius work together and know each other super well.

So of course I had to show Nick the candle. I dug around on my phone for what seemed like an awkward eternity, "just wait, you have to see this, I swear it's amazing..." Finally I found a photo of the votive candle and Nick cracked up. Immediately he had to send it to Julius, and later he sent their colleague Pat Scandalis by to see the photo (and Anukari).

It turns out that I had been referencing work by all three of them for years, but only Julius' name had stuck in my head. Maybe Julius, Nick, and Pat are the Patron Saints of Physical Modeling, and not just Anukari.

Given that Nick and Pat found the candle funny, I finally worked up the nerve to email Julius himself, to show him the photo and also thank him for all his contributions to the field. He also laughed, and commented on the photo as "alternate-universe Julius" due to the uncharacteristic mustache. (Meg chose this picture because it was the highest-resolution one she could find!)

All in all it was an absolute honor to meet these friendly titans of the physical modeling world, and to have such a silly interaction centered around the votive candle.

The world really is a funny place. I never would have guessed that my offhand joke about Julius as a patron saint would ultimately blossom into a hilarious conversation at NAMM with a friend of Julius!