OpenAudio: a catalog whose Type and Framework columns record what the submitter wrote

The repository is a data file and the TypeScript is the generator

Everything a reader sees is built. The top level holds `README.md`, a `data/` directory, a `generator/` directory, `_config.yml`, a `CNAME` file, a `.vscode/` directory and a contributing note, and the language on record for the repository is TypeScript. That combination is what a static site setup looks like: `CNAME` beside `_config.yml` is how a custom domain gets served, and the site is at openaudio.webprofusion.com. So the list is a build product with the same content expressed twice, once as markdown for readers on GitHub and once as a site. Two things follow. The rows live in `data/`, which means a fork that edits the README by hand will lose its edits the next time the generator runs. And the repository has no GitHub releases at all, so there is no version to pin: the artifact is the page, and it changes whenever someone files an issue that an editor accepts.

Contributions arrive as issue templates, not pull requests

Adding an entry is not a pull request against the markdown. The contributing section says to fill out the issue template, and that the change will be prepared automatically and reviewed by an editor, with the issues page of the repository given as the place to do it. The pipeline is therefore: a person files an issue, something turns that into a row, and a person checks it before it is published. That explains the `data/` and `generator/` directories sitting as a pair, and it puts an editor between a submission and the published list. What the page does not say is what an editor rejects. No turnaround time appears, no criteria beyond the general intent, and no way to tell from a row whether it was added recently or has been sitting there for years. For someone maintaining an audio project, the practical consequence is that an accepted listing depends on a review step rather than on your own merge.

The Type column disagrees with its own descriptions

The plugins table has four columns, Plugin, Description, Type and Framework, and Type comes from a short vocabulary in which Effect, Instrument and Misc all appear. The descriptions do not always agree with it. Airwindows is typed Instrument while its own description reads various small and experimental effect plugins, so the mismatch is inside a single row rather than a judgement about the project. ampli-Fe is typed Misc and described as a cross-platform VST2 plugin written in Rust, which is a plugin with no better slot in the vocabulary. Those two rows show what the column is: a rough fit applied by whoever edits the entry, not a taxonomy. For anyone filtering the list, Misc means uncategorised rather than something specific, and Instrument sometimes absorbs an effect. The Description column, by contrast, is written per project and is where the actual information sits.

The Framework column records N/A as often as a name

JUCE dominates the Framework column, appearing on nearly every row that names anything at all. The alternatives are scattered across the alphabet: Rust VST for the plugin written in Rust, GTK for amsynth and for Calf Studio Gear, whose description adds LV2 and Jack audio plug-ins, DPF for Automatic Double Tracking, NIH-Plug for Autokit, and VSTGUI for Breathalyzer. N/A fills the rest, and it does so for projects that plainly have a framework, such as Axiom, described as a node-based realtime audio synthesizer originally designed for size-constrained environments such as PC intros in the demoscene. The column therefore records what the submitter wrote rather than what the project uses. Plugin formats are a separate matter and live in the descriptions instead: VST, VST2, VST3, AU, CLAP and LV2 all appear there, and several rows name more than one at a time.

Link targets alternate between repositories and project pages

The Plugin column is a link, and where it points is inconsistent in a way that matters for a reference list. Most rows point at a GitHub repository, but BlackBird goes to a project page on a github.io address and BORIS Granular Station goes to another one of those. Beatrice 2 is stranger: its Plugin cell points at a repository while its description carries a separate link to the vendor site, so the row has two destinations with no marker telling them apart. Automatic Double Tracking embeds a second link inside its own description cell, pointing at a Wikipedia page, and nesting a link inside a table cell is what produces rows that render as raw markdown in some viewers. Nothing in the table marks a row as unmaintained, archived or commercial. A row is a claim that a project is open source and worth looking at, and everything after the click is on you.

ÆLAPSE sits between ADLplug and Aeolus, so the sort folds Æ to AE

One row settles how the whole table is ordered. The visible run of names goes 3HSPlug, 8ridgelite, ADLplug, ÆLAPSE, Aeolus, Airwindows, Ambience, ampli-Fe, amsynth, AnalogChannel, ANATOMY, andes, Argotlunar, Audible Planets, Audio Effects, Autokit, Automatic Double Tracking, Axiom, BeatCrafter, Beatrice 2, Bespoke, BinAural VST, BiRR, Biztortion, BlackBird, Blackheart, blocks, BORIS Granular Station, Breathalyzer, C1Bitcrusher, Calf Studio Gear. ÆLAPSE appearing after ADLplug and before Aeolus means the ligature is folded to the two letters AE before sorting, because a plain code point sort would place Æ after every ASCII letter rather than in the middle of the A run. Digits sort ahead of letters, which is why 3HSPlug and 8ridgelite come first. Small detail, and a useful one: a list this size is navigable only by its ordering, and the folding decision is invisible precisely because it works.

Six sections are promised and one of them is visible in full

The table of contents promises six sections: Audio Plugins, Collections, Audio Apps, Software Development Libraries, Code Samples and Open Data Resources. Only the first is visible here, and it stops partway through the C rows, where the final line is a bare table pipe followed by an opening bracket and nothing after it. So a reader gets thirty or so plugin rows and no example at all from a collection, an app, a library, a code sample or a data set, which is where the less obvious entries would sit. The stated filter for inclusion is that a project is either fully featured or a useful example with non-trivial features, which is a soft criterion and one an editor applies by hand rather than a rule you can check an entry against. The repository itself is under CC0-1.0, a public domain dedication, which suits a catalogue and says nothing about the licences of the projects it points at.

Editorial conclusion

OpenAudio is worth keeping open as a discovery page rather than as a dependency list. Nothing here is installable, the repository has no releases, and the useful part is the breadth of a catalog that someone else curates on your behalf through an issue template. Two cautions before you act on a row. The Type and Framework columns are recorded from the submission, so Misc means uncategorised and N/A means nobody wrote it down rather than that a project lacks a framework. And no column records maintenance, so check whether a linked repository still builds before you plan around an entry. If you maintain an audio project yourself, the contribution path is an issue template rather than a pull request against the markdown.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. Project website
4. README
5. webprofusion/OpenAudio on GitHub