Simon Gladman's Apple Pencil Synth ∞
AudioKit Turns 1-Year Old Today ∞
I wanted to write a blog post about everything that has happened with AudioKit in its first-year available as an open-source project, but I realized that all that is well-documented by looking at the blog, or by looking at the Release log. So instead of going over it all again in detail, I want to write about a few of the lessons learned along the way.
But first, it’s good to take a moment to reflect on the stats from the last year.
There have also been 8 major releases, 4 versions of 1.x and 4 versions of 2.x. We have made 2402 code commits and 498 web site commits since 1.0. That’s a 300% increase from all of the commits that led up to our launch!
Every major release had something really important in it: Tests, Sensible Defaults, Xcode Templates, Rate-Agnosticism, CocoaPods Support, Example Projects, Live-Coding with Playgrounds, Syntax Refinements, Dynamic Tables, Static or Dynamic Dependencies, Switching to the MIT License, Travis Continuous-Integration, Embedded UI Tools, Plots, Sensible Presets, SoundFont Support, tVOS Support, and New Operations. Phew!
Thankfully this was not all on my shoulders, AudioKit got 12 new contributors this year, most notably Stephane Peter who as of March really has been a primary force in AudioKit development, quickly earning him a place on AudioKit’s core team.
Okay, okay, let’s get to the fun part, the lessons learned along the way!
Lesson 1) Open-sourcing a large private project is not easy
With AudioKit 1.0 we learned a lot about what it really means to open-source a piece of code and get things working and well-documented enough for public consumption. Although this work didn’t technically happen in the last year, it is worth noting the monumental effort that Nick Arner put in to make this happen.
Additionally, building a web site for an open-source project can be harder than writing the code.You have to put yourself in the shoes of someone who has never heard of your project and that is challenging for a developer whose deep into the code.
Lesson 1a) Even after launch it doesn’t get much easier
You might think that once you release your work is done for a while, but actually now that eyes are on you and people are trying to use your code, you’re about to learn about all the things that you didn’t even know were broken. Here’s Github’s timeline for my last year (it’s 99% AudioKit):
Lesson 2) If you build it they may not come
This is not me complaining about how many users AudioKit has. I am actually really surprised by how big our community has become. We have 1,190 stars on Github, with 158 forks. We’ve had countless demo apps created, 5 apps released on the App Store, and quite a few schools have adopted AudioKit to teach audio programming to high-school students all the way up to graduate students. So, while the adoption rate is great, I’ve learned that even though I might think a feature is amazing, I really never got much feedback from people after that feature is released. The lesson however is to not be daunted by this fact and not rely on positive feedback to make positive improvements to the code. A good example of this is Testing and Travis Continuous Integration. These were huge undertakings that in general no one is ever going to care about. But they are so important to the future development of AudioKit! Being able to accept/reject code based on tests and having that automatically happen behind the scenes on Travis is one of my favorite accomplishments of this last year.
Lesson 3) Open-source with the right license…
When we first released AudioKit, it was under the LGPL license. We had to do this because of our libsndfile dependency is licensed under the LGPL. However, we received lots of questions and comments about how the LGPL was not appropriate for closed-source iOS apps on the App Store. With the addition of a dynamic framework, we were able to re-license AudioKit under the MIT license. Ideally, we would have done this work before we first released AudioKit and we probably would have had more initial users.
Lesson 4) Love everyone, because they might become your core team
When I look at the core team of AudioKit developers, I am struck by the fact that I still remember when they were completely new to AudioKit. I could have been dismissive of their interest or abilities, but if I had been a jerk like that they would never have wanted to work with me and make the contributions that I value so much now. I’ll mention Nick again because literally AudioKit might still be in procrastination mode if it were not for him. Stephane has made improvements to AudioKit that I just would have not thought of or been able to implement on my own. But, the best example of this lesson is Simon Gladman. His first project using AudioKit may not have been all that great, but since then every AudioKit project he has built has been better and more interesting than the last. His latest AudioKit-powered Metal Particles project is absolutely gorgeous and this trajectory has no sign of decreasing either, so I can’t wait to see what comes next.
Goals going forward
Perhaps the main lesson learned is that you can’t really predict the future of an open-source project, you just have to be ready to react to whatever happens next. That being said, we do have a lot of work planned and improvements in the works. Thanks to everyone for the great year we had, and here’s to another great year ahead.
Announcing Version 2.3 with tvOS Support! ∞
We are proud to announce the release of the latest version of AudioKit, v2.3.
Version 2.3 keeps AudioKit up-to-date with Xcode 7, Swift 2, iOS 9 and also adds tvOS support for the brand new Apple TV. We also include binary libraries including Bitcode for both iOS and tvOS.
Summary of the changes in this release follows:
You can write audio apps for the AppleTV with AudioKit as easily as you could for iOS and OSX. There is an included HelloWorld example to help get you started. Most classes are available on tvOS, with a few exceptions like MIDI support (AKMidi) and user interface elements based on sliders.
Xcode 7, Swift 2.0, and iOS 9 Updates
The internals of AudioKit were updated to take advantage of new features such as generics, null specifiers, etc. This makes AudioKit even easier to be used with Swift. Bitcode support means that you can now submit AudioKit apps with Bitcode for iOS and tvOS (it is actually a requirement for the Apple TV).
Daniel Clelland was busy improving AudioKit's FFT library with the new AKFilteredFFT, AKMaskedFFT, AKTableReader, and AKTableWriter operations.
There is also a beat clock implementation in AKBeatClock that can be used to write looper apps as well as a new AKCompressorExpander that is a bit more intuitive than the powerful yet a bit cumbersome AKCompressor.
We also included a few more bug fixes, including a performance issue that should make CPU usage in AudioKit significantly go down on iOS in this release.
We still have more cool features coming up in the next versions, including support for a proper AudioKit framework, expanded Sound Font support, and more!
Matthew Fecher's Swift Radio App Open Sourced! ∞
Matthew Fecher just open-sourced his very cool and very well executed Radio app written entirely in Swift. This app doesn't use AudioKit per se, but Matthew is a contributor to AudioKit and this code deserves some publicity!
- Swift Radio Pro on Github: https://github.com/swiftcodex/Swift-Radio-Pro
AudioKit Chapter in New Csound Inside Book ∞
The 3rd International Csound Conference was this weekend and Richard Boulanger announed that a new Csound Book is in the works called "Csound Applied / Csound Inside" and that there will be a chapter dedicated to AudioKit in it. Pretty awesome to have a book chapter written about our little audio toolkit. We would like to encourage Richard to take a second look at the proposed table of contents however. Instead of teaching the reader about basic programming concepts like the MVC pattern and how to translate Csound to AudioKit, we suggest a tutorial that follows preferred AudioKit best-practices. We're really looking forward to Rory Walsh's and Paul Batchelor's chapters though. Those at least, look excellent.