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.

Read more…

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.

Read more…

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.

Read more…

There's something I've needed to do for a while.

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?

But then I found out about the Holman Prize via my friend Chris Hofstader, who writes a prominent blog on accessibility. it's up to $25000 of funding.

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.

Read more…

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.

Read more…

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.

Read more…

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.

Read more…

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.

Read more…