-
-
Notifications
You must be signed in to change notification settings - Fork 3
Participating
If you are interested in Audio Plugins For Android, you are welcomed! Please feel free to take whatever we offer (along with our licenses). We highly appreciate contributions to AAP and the ecosystem too. There are many ways to get involved (from contributing code to sharing project websites etc.), and everyone would take their own approach.
This document is to describe what we can offer, what we would like to ask, what we are missing, and how we would fix and/or complete them, to get reduce mismatches between what you might expect and what we actually offer.
So far there are three parts:
- project status
- community bindings
We should come up with some high level webpage for that (like product introduction using carousel in 2010s). But so far, this "Are We Audio Plugins Yet?" Wiki page shows the list of current feature list: https://github.com/atsushieno/aap-core/wiki/Are-We-Audio-Plugin-Format-Yet%3F
As a grand goal, AAP (Audio Plugins For Android) aims to become a commonly used audio plugin format and ecosystem across multiple hosts and multiple plugins with rational set of features. It should be open to everyone on Android (and compatible platforms as long as supporting such ones is feasible).
It aims to become an open ecosystem, meaning that the plugins are not closed to certain products. But at the same time, any project or product that want to integrate AAP would like to keep the apps (plugins and hosts) maintained in backward-compatible manner (I have more words on it later). Thus, until AAP "version 1.0", those AAP plugin integration in the apps will be closed to each versioned ecosystem. You can take it like DAW-specific plugins.
AAP at this state is quite unstable in both API and implementation; AAP is fundamentally realtime unsafe (due to IPC Binder limitation), but even putting aside, each existing plugin is just a port which assumes desktop PC performance, which may or may not matter (up to the plugin). Therefore the usage scenarios would be limited to certain level. Things will evolve, but we cannot promise (more words on development sustainability later).
Is the plugin format useful? Hopefully to some extent. We have some usage scenarios:
(1) Using AAP as MIDI device: Android platform provides developers an ability to build a virtual MIDI device aka MidiDeviceService, and AAP already makes it easy to happen. Any AAP instrument plugin can be used as a MidiDeviceService with simple build setup (library and metadata). Since MIDI is a stable protocol, we can make incompatible changes in AAP itself while keeping MidiDeviceService compatible. Besides, the AAP internals are (at least as of early 2023) based on MIDI 2.0, so once Android platform supports MIDI 2.0 on MidiDeviceService we will be immediately able to catch up with it at little cost.
(2) Static audio processor: not all audio applications have to generate audio in realtime, and they would be happy as long as we generate reliable audio outputs. It is not as stable as MidiDeviceService and we would need some simplified but "somewhat stable" API for applying audio plugins. This does not exist yet beyond androidaudioplugin-ui-compose and aaphostsample.
For a plugin format, it is extremely important to establish a stable API. Otherwise those plugins and hosts will become quickly incompatible each other and the Tower of Babel will immediately collapse. On the other hand, it is simply impossible to establish a stable API without actual use cases and experiences. We will end up freezing the potential on the plugin format once it goes stable, unless the remaining improvements could be achieved by extensions. AAP at least as of 2023 is far behind that stage. The public plugin API is subject to changes.
We cannot promise when we will reach version 1.0. Once we reach version 1.0 then we will focus on version 2.0 which will be incompatible with 1.0. CLAP was announced in 2014 and it became stable in 2022.
We ask you to agree to the following terms:
- For code contribution to AAP projects such as aap-core, aap-lv2, aap-juce, and the existing plugins, we ask you to agree to provide your contributions in licenses that are compatible with the MIT license. We would like to preserve opportunity for anyone (including the maintainers) to build commercial products. If you don't agree with that, you could keep your own fork (but I'm sure it is annoying to keep things in sync with upstream).
- We have Community Code of Conduct and we ask you to follow it (!!!TBD!!! an idea is to reuse Contributor Covenant Code of Conduct).
There are some additional policies that you would anticipate:
- The code is ugly: Assume that we are all stupid and anyone could bring in stupid changes. Whoever has suggestions for better code, please send us improvements.
- We prefer preserving history over cosmetic changes: code formatting is often broken and there would be various typos, but we may not be taking cosmetic patches just for them, because preserving code history can be more helpful over those cosmetic changes. Excuse us if we don't accept them.
- Modification: We declare that your contributed code could be modified in any sense by any other contributors/maintainers.
- QA: we may ask to add tests. That could happen even if there is no existing tests.
- We are regressive: I'm sure we could happen to break any contributed code. We'd feel sorry but things happen. Please bear with us. You are encouraged to add tests to potentially prevent that.
- Incomplete fairness: we might look "unfair" when taking patches (we try not and we follow our Community Code of Conduct). It is up to whether we find them easy to maintain, error prone or not, we like them or not, how consistent the changes across code files, etc.
We expect application (plugins and hosts) developers to write code with somewhat stable API and/or framework, such as LV2, JUCE, DPF etc. We have aap-lv2 and aap-juce to help porting. LV2 and JUCE are the largest two SDKs (I'd say) at least on GitHub to actually provide audio plugins that are ready to build. (In other words, VST3, CLAP, AU or other APIs are not directly used much, no matter how they could be indirectly built. Therefore they are not very fruitful when we want to bring in more plugins to Android. But wrapper implementations are welcome if anyone can create them.)
The most important and difficult part of designing and developing audio plugin format is to achieve market acceptance. And there, the number of existing applications matters. If you are building a DAW, you don't want to support a plugin format that does not have many plugins. The same applies to plugin developers; you wouldn't like to build for a plugin format that no DAW in the market supports.
Porting existing audio plugins is an important task for us. As of early 2023, we have 6 aap-lv2 plugin projects and nearly 15 aap-juce plugin projects ported to AAP. Some of those projects contain various plugins (e.g. aap-mda-lv2 imports almost 50 instruments and effectors in total, and aap-guitarix is almost about 100 of those).
Porting is often very easy, sometimes very hard or just impossible, depending on how the code is structured and what kind of dependent libraries they use. It should be also noted that maintaining those ports costs us time and energy - usually @atsushieno spend like a week to make sure they build. If it involves more QA activity it would cost more. It is actually often a development blocker.
You can still write plugins for AAP API directly, but it would be unnecessarily exhausting process to rewrite your APP to catch up with the moving target. We have no hesitate to make changes to the plugin API until we reach "version 1.0". We warned you...!