I'm going to cut straight to the chase. I'm no longer able to actively maintain Libaudioverse. I'm currently in the process of refunding all GOFundMe donors, but this isn't automated so it will take some time.

When I started the GoFundMe, I thought that there was a reasonable chance of reaching the goal, but this sadly proved not to be the case. I also thought that I would have time nonetheless, and could finish important funcionality regardless.

But then my life got complicated.

In July, a job opportunity I couldn't pass up came my way. I now have a 6-figure salary and a 40-hour work week. After accounting for self-employment taxes and GoFundMe's fees, what I'd get is equivalent to less than I make in a week. Consequently, taking a few months off isn't going to happen.

In October, I found out that someone who is all but family had cancer. This was then followed up by learning what it's like to help someone through Chemotherapy. This wasn't as bad as it could be and we're past the scary parts, but it went through Christmas and is still ongoing.

In addition to all of this, I'll probably be moving within the next 6 months.

I keep waiting on my life to slow down, intending to work on it then. But this is not going to happen.

Everything that has to be done to get Libaudioverse to 1.0 takes a week. There's more than a few. I need 2 months.

I'm not going to get 2 months.

So what does this mean for the future?

I expect everything in Libaudioverse that currently works to continue working. What exists is relatively stable, and Microsoft rarely changes the underlying APIs. They've only done it once in the entire history of Windows, and even then old software still works but with more audio latency.

I am going to maintain it as I'm able. If I have the time and desire, there's a bunch of stuff I still want to do to it--and some of it is stuff I haven't seen done before, most notably a much better parallelism design.

As my life becomes more stable and predictable, I'm going to try to begin focusing on smaller projects outside work.
If I find stuff that can be done in a few days, I can find a few days to do it. Libaudioverse is an order of magnitude bigger than most of the dependencies of the Python web stack, and also written in C++. C++ is maybe the hardest programming language to get right, possibly tied with C.

There's longer term projects I can do that are a bunch of smaller pieces that are individually useful, for example my pipe dream of writing a parallelized graph database in Rust (which requires 4 or 5 libraries, possibly including Fastnet if I want to go there). Small doesn't mean meaningless.
I also want to get back into contributing to the Rust compiler and standard library. I can't do something on the order of struct field reordering, but there are lots of smaller but important issues.

There's also a lot I can blog here. This blog has been sorely neglected. For one thing, writing up how some of Libaudioverse works and what needs to be done might let someone else maintain it. On that note, if you're interested in maintaining Libaudioverse and have good C++ knowledge, I can walk someone through a lot of it.

I want to close on this note. When I started Libaudioverse, the only other real option for HRTF that didn't cost a lot of money was OpenALSoft. There weren't many options for production-quality audio synthesis--just research-oriented tools. Now, every platform but Linux has multiple good implementations for this sort of thing, and you can even get it in the web browser.

This means that, for a while, I was ahead of everyone. If I ever need another job, I get to claim that I independently designed most of what's in WebAudio on roughly the same timeline and as an individual. Though I can't finish the project, I think this is still a major personal win.

If you don't already know about Libaudioverse, the short version is that it's basically desktop WebAudio in terms of functionality, though not in terms of API.
The point of this post is to provide information and answers to people already using it.
I'm going to do posts aimed at a more general audience once I finish the in-progress HRTF refactors and the bindings generator cleanup, so watch this space.

If you are using Libaudioverse, 0.9 is live, and I suggest everyone upgrade. I've also got some important information on the GoFundMe timeline and the future of Libaudioverse's development.

Note: The optimization described here is now in Rust stable as of 1.18.

Anyone who knows me knows that I've been spending a lot of time working on the Rust compiler, to the detriment of all my other projects.
I'm glad to say I'm done.

The 2000-foot version: Rust structs, enums, and tuples are now automatically smaller in some cases. It's possible for the compiler to work with types whose in-memory field order doesn't match that of your source code. And a minimal debugging framework for future optimizations is in place.
This work has already had some real-world impact on Servo.
In the rest of this post, I'm going to lay out the problem and detail what I did.
This sounds like a very insignificant feature, but it actually took a lot.

If you'd prefer to just look at pull request threads, see:
#36151,
#36904,
#37429,
#38483,
#38523,
#39595,
and #40377.
There's also a related discussion thread of some note here, from which the initial design of optimization fuel emerged.

This is my first completed Rust project, and I certainly intend to do more.
The community was amazing, the Rust compiler itself is some of the best open source code I've ever worked with (and they think it actively needs to be cleaned up--well, let's talk about open source DSP sometime), and all tooling is accessible.
In fact, the accessibility point deserves special emphasis: everything is command line, and I've been drawn into more than one discussion because I'm possibly the only blind Rust developer. In particular, a deciding factor for this RFC is that it's unfriendly to blind devs.

Before we begin, a brief moment of self promotion. I'm looking for part time remote work, preferably in the open source space and extra preferably with Rust because I like Rust.
I'll probably be able to do full time and/or in-person in the next 6 months, but i'm still sorting out some personal stuff that takes time and makes me hesitant to move.
My resume is here.
I'm also trying to fund development on an audio synthesis library with a ton of applications that I started 3 years ago and have been developing continuously since, so if you like this maybe check out Libaudioverse's GoFundMe and donate $5.

I'm trying to fund development on Libaudioverse, my large library for audio synthesis and pet project for the last 3 and a half years. One of the things I need to do is justify it.
So I took a week and made Audiograph, a graphing calculator prototype for the blind that people are already finding useful and contributing to.
It is my hope that this will help fund Libaudioverse, and potentially be a fundable project in its own right.
You can find more information on Libaudioverse itself here and the GoFundMe is here.

now for actual details.

Update: It occurred to me after the fact that I'm not making this very clear. Anyone can donate any amount to the GoFundMe. Got $5? That helps. 100 people donating $5 is $500.

Libaudioverse is a massive digital signal processing project, and it is the nature of digital signal processing that much of the debugging process would go much more easily if I could examine data. But I can't because I'm blind and the tools to let blind people do so do not exist.

All we have at the moment are graphing calculators. Input an equation, output a graph. This is nearly useless for anything but high school mathematics. The real world is not made up of homework polynomials, nor are you finding where it crosses the y axis over and over.

Fixing it is time consuming. My plan was to take Libaudioverse as far as it can go without, then write the bare minimum for my personal use. This may have been useful to others, but it wouldn't have done much outside the specific domain of DSP. Also, documentation? What documentation?

Suddenly, producing useful, documented tools with convenient UIs for a whole variety of domains is on the table. Digital signal processing? Definitely. Machine learning. Economics. Weather data. The list goes on and on. We can't access any of these conveniently. It's not impossible, but no one has written the tools to do it. I don't know why this is--I suspect a general lack of funding for anything past the K-12 age group--but I have the chance. I want to take it.

You can help me by going to my 90-second video pitch and liking it, then sharing both the video and this blog post as widely as possible. The LightHouse for the Blind and Visually impaired in San Francisco is explicitly monitoring social media, and one way to win it is to have the most Youtube likes. If I can secure the funding, this project will have a nearly immediate and amazingly large impact on every blind person in STEM. If you aren't blind or in STEM, that's okay: you can still do both of these, and it may very well help a whole bunch of people who are.

The rest of this post goes into technical details, what I think I can do, and generally how I plan to do it if I win. Before putting on my scientist/programmer hat, let me just close by saying that this will be free and open source software. Using it will cost nothing, and anyone who knows programming and needs more functionality will be free to help add to it.

Libaudioverse is my attempt at making 3D audio for native apps, something which is currently lacking in the typical indie price range.
There are other systems with fully featured content management pipelines, but these are often overkill for small projects, especially in terms of budgets.
If you know Web Audio, you are already basically familiar with most of the core concepts.
While there are differences, general architectural experience should be broadly transferable from one system to the other, and Libaudioverse aims to solve many of the same problems as Web Audio.

That said, this post is primarily aimed at those already familiar with Libaudioverse.
I will probably have an entire series about what makes Libaudioverse relatively easy for one person to maintain at some point, but this post is about the short-term and long-term future.
It recently came to my attention that there are people outside my small circle of developer friends who might be interested in knowing where I stand and where I'm going, so I thought I'd write something up.

This post will proceed roughly by major feature, discussing the status of each. The short version is that Libaudioverse isn't something that I want to call stable, but I'm certainly interested in getting feedback at this point; it's working well enough to be useful and the API is pretty settled.

Update: I didn't realize there was a clarity issue, but the Hacker News thread made it clear that I should provide this clarification. I knew from the beginning of development that, no matter what I did, I'd need to support multiple backends. I had already written something like a third of the code that I would have to write by taking this route and, at some point, you just have to do it in the interest of actually moving forward. I am also developing a commercial library. To this end, some options that would otherwise be options are closed to me; I cannot use any dependency that my end users may need to purchase nor may I entertain the option of bringing in monolithic app development frameworks. Anyhow, back to your regularly scheduled blog post...

I've not been blogging recently because of two factors. The first of these is that we still do not have an accessible solution by which I can include math equations, save for me instructing you to learn LaTeX and view the source code of my articles; It would be incredibly hypocritical of me to make my blog posts inaccessible. The second is that the things I have been working on are somewhere between the domain of programming and math textbooks, with a bit of art and a lot of trial and error thrown in, so I simply haven't had anything interesting to say that fits into a blog post.

the latter of these has fixed itself and I expect I shall actually be posting semi-regularly again.

Today I want to talk about the horror of the world of audio output and all the wonderful broken promises you run into when you try. For a very long time, this was the hardest part of Libaudioverse, and I have had to literally give up on software libraries and at least one nice feature. I'm going to talk about this primarily in the form of an enumerated list of all the things I've had to try, talking about what's wrong with each one; if you're not interested in a post about various audio libraries and their brokenness, you can stop now. This is long, but I think it is worth chronicling so that others do not fall into the same pitfalls, something which has both frustrated me greatly and wasted weeks of Libaudioverse development time.

Note: it was pointed out to me that I forgot to mention enum34 in the readme.
If you were getting errors about not being able to import enum, installing enum34 (not enum, enum34) will fix them.

I haven't spoken about Libaudioverse much, primarily because I find code much more valuable than articles on a blog.
You can run the former.
You can use the former for cool games and technologies.
But Libaudioverse is now at the point where I can and should talk about it more.
So I shall.
And perhaps more importantly, I have something I can release.
It's not alpha-quality, thus the term preview.
But it can give you a feel for what this will be, and it has some cool example programs.
If you want to skip straight to the preview and not read the rest of this post, you can get the windows binaries here.

Lambdatask is a project that I was hoping to put off for a while. C++11 provides many useful thread primitives, but has major shortcomings. The most notable of these is the lack of concurrent and threadsafe data structures in the standard library. I'm not sure who thought it'd be a good idea not to seriously consider at least making std::queue threadsafe, but it's not and we get to live with that.

Unfortunately, among a bunch of features that Libaudioverse needs, threadsafe queues is one of them. More unfortunately, it needs them now so I can implement callbacks properly. I have identified three reusable things that it would be incredibly useful to have, the first two of which are surprisingly simple: a monitor, a threadsafe queue, and a library for the automatic parallelization of tasks with dependencies on other tasks. These libraries exist in various forms, but my research failed to turn up any that use only C++11 features. A library using only C++11 features will run on the 5 major platforms, and more are being added as we speak.

It is monitors that I want to talk about today. The code in lambdatask marks my transition from intermediate to advanced C++ developer. This alone isn't worth a blog post, but how the Monitor<T> works in Lambdatask is. The code here took me about 3 hours to work out, and I can thank here for the idea and this Stack Overflow question for the last piece of the puzzle.

In part 1 of this series, I gave a proposal for what a framework for implementing most types of games might look like. In that post, I promised a part 2 in which I attempt to quantify the size of MMOs in terms of the framework. Here it is.