Last year was a really exciting year for Elementary: we saw the announcement of Elementary v1.0, the Discord community grow to over 650 members, awesome community projects spring up like @bgins’ Coincident Spectra and @vewilya’s Pluviat Delay, and uptake from some really exciting companies and teams like Arpeggi.
The end of last year was also a great opportunity for reflection, and for me to clarify my goals with this project. Much of my work in 2022 included efforts to find a sustainable strategy for funding Elementary’s continued development while still enabling new users to pick up the project and evaluate it before committing to any fees. That’s what prompted removing any fee structure around using the library itself, while pairing it with an attempt at building a marketplace for selling paid add-ons.
After reflecting on this past year, my conclusion is that these attempts have also built a sense of hesitation for new users and larger companies– to name two prominent factors: an unfamiliar proprietary license, and no visibility into the core framework to aid in evaluating whether it’s the right fit for certain projects. These hesitations are totally valid, and ultimately they stand in contrast to one of my guiding theses that removing barriers to entry for those users will be a key factor in Elementary’s success.
As I made these realizations, the path forward became clear, and now I’m excited to share that Elementary will be made open source under a permissive license within the next few weeks. This is a huge step for the project, and one that I hope will invigorate our industry and the amazing community that has already formed around Elementary Audio.
Making the move to open source also reveals Elementary’s true potential by enabling a broad set of integrations that have so far been unavailable. This provides opportunity to reposition Elementary in terms of the problems it really solves. With access to the native engine, Elementary can be integrated anywhere you have a set of float buffers to process or write– plugins, mobile apps, desktop clients, embedded devices, etc. It can provide your entire audio processing step or just a slice of it if you already have an existing stack. You’ll even find an API to extend the Elementary native vocabulary with custom C++ audio processing nodes for those cases where you need careful performance tuning, where pure function composition is not the right fit, or to pull in existing DSP that your team has already committed valuable time to building.
With these features available, I want to encourage custom native integrations rather than prebuilt integrations– the node-renderer and plugin-renderer in particular become perhaps more limiting than they are valuable. For example, a long-standing discussion in the Elementary community has been adding MIDI support to the plugin-renderer. Elementary’s core native framework has long been capable of supporting such a feature, but making the integration involves considering tradeoffs for which there’s no one right answer– tradeoffs that should be evaluated and decided upon by the team responsible for each product and each integration.
To cover all of this, I’ve been focusing intently on facilitating a seamless native integration, which comes with a small set of breaking changes. We will therefore mark Elementary v2.0 at the time of going open source, accompanied with updated documentation and a migration guide for existing projects built on v1.0. In short, Elementary v2.0’s breaking changes will include:
node-renderer and plugin-rendererweb-renderer and offline-renderer packages will remain officially supported to continue supporting web projects via npmel.fft and el.convolve from the core native engineoffline-renderer and web-renderer, which offers a convenient demonstration for extending the core framework with custom native processing nodesweb-renderer and offline-renderer. Nodes like el.table and el.sample will no longer accept a path property that points to a file on disk; instead they will expect to find a named resource in the shared resource map by the value given in pathel.tapOut node will no longer accept a size property; all feedback loops impose an implicit delay of one block size, which can be tuned by configuring the engine with various block sizes.This year has been an amazing opportunity, and the energy from the community has been such a great motivator. I want to end this update with a sincere thank you to everyone who has supported this project along the way, and an eager, excited nod to the Elementary Audio community: I can’t wait to open up this project and see what you build with it!