nih-plug: maintenance mode in the first line, a release tag called latest-builds, and a crate version of zero

The readme opens by sending framework users to a community fork on another forge

The readme opens with a notice before it says anything about the project. It states that the plugin framework is in maintenance mode, and that anyone interested in the framework rather than the plugins should look at a community fork instead. The fork is hosted on a different forge entirely, not on the same one as this repository. So the author's own recommendation for new framework users is somebody else's repository, which is a strong signal about the project's trajectory and the single most useful sentence on the page. It is also the only place the maintenance status is stated, and it appears above the table of contents rather than in a status section. The notice draws a distinction worth keeping: it points people at the fork if they want the framework, and says nothing about the plugins, which are still listed below in full and still being built. The last push to the default branch is dated 2026-09-03, about a month before this writing, so maintenance mode here means the plugins are still being touched, and the plugin section that follows is the longest part of the file. Nothing else in the readme mentions the fork again.

Nothing in the repository is versioned, and the package manifest fixes the compiler floor and the edition but leaves the version at a placeholder

The release history has one entry. Its name is the word for latest builds, and so is its title. The readme links to it as the place to get development binaries for three platforms. A rolling tag is the opposite of a release: every push to it moves the artefact, so two people downloading it on different days get different code with the same URL and no way to go back. Alongside that, the package manifest carries the version zero point zero point zero, which is a placeholder rather than a version. So there are two independent confirmations that this project does not do semantic versioning, and a consumer pinning a plugin from it has no version to pin to. The manifest does at least declare the things a version would normally constrain: an edition, a minimum compiler version, a licence, and a repository. The rest of the root is small and deliberate: a bundler configuration, a toolchain directory, a formatting configuration, a changelog, and a committed lock file, which is what you would expect from a workspace full of binaries rather than from a single library. The declared minimum compiler version and the edition are both stated, which is more than many audio plugins bother with. The licence is the permissive one the manifest names, and it covers the workspace as a whole rather than any individual plugin.

The default feature set builds one of the two supported plugin formats, and the manifest comments explain what each switch costs

The manifest declares two plugin formats as supported and the readme explains that you get both by adding the corresponding export macro to your plugin's library. The feature list then complicates that. The default feature set enables one format and not the other, so a plain build gives you one export and the second is opt in.

default = ["vst3"]

assert_process_allocs = ["dep:assert_no_alloc"]

A third feature, for standalone executables, is documented as disabled by default because it requires building additional dependencies for audio and MIDI handling. So a first-time user following the readme's macro instructions may add the macro for the second format and get an unexpected result if they assumed defaults covered both. The comments in the manifest are more informative than the readme on this point, which is a recurring pattern worth noting: the feature list explains the cost of each switch and the prose does not, which is the pattern worth internalising about this manifest: read it rather than the readme when you want to know what a build will actually contain, and read the feature comments rather than the feature list when you want to know what a switch costs you. The manifest also pins the workspace dependency resolver to its second version, which is the current one, so there is no old resolution behaviour left in the build.

An opt-in feature makes the audio callback terminate on allocation

One feature is worth pulling out because it addresses the failure mode that matters most in audio code. Its comment says that enabling it will cause the plugin to terminate when allocations occur in the processing function, and that this applies to debug builds. The comment then adds the caveat that makes it usable rather than merely annoying: panics may also allocate if they use string formatting, so the feature may need to be temporarily switched off while debugging a panic in signal processing code. That is a real engineering trade-off stated plainly rather than hidden. A runtime of this kind also carries a typed asynchronous facility for background work from inside a plugin, and the visible text describing it is cut off mid-word, so the type-safety claim is made but not explained. One design note in the same list is the closest thing to a positioning statement: the framework is described as stateful, and as behaving mostly like a well-known C++ audio framework without the boilerplate. That comparison is doing real work, because it tells you what a plugin written with this will feel like to author, which is a deliberate borrow rather than a claim of novelty.

Parameters are declarative, their identifiers are explicit strings, and state migration is an option rather than an afterthought

The parameter system is the part of the framework with the most detail, and the detail is all in the list of what the derive macro removes. Four parameter field types are available, covering floating point, integer, boolean and enumerated values. Each field carries an attribute assigning a stable identifier as a string literal, and a derive on the parameter struct does the rest. Non-parameter state is persisted separately, using any field that a serialisation library can handle plus a persist attribute naming the key. Parameters can be nested into groups, and nesting also lets you use several copies of the same parameter, including in arrays. There is optional support for migrating state when parameters change in breaking ways, which is the hard problem in plugin development, and there is an escape hatch where you implement the trait yourself for parameters generated at compile time. The readme also points at a project template for starting a new plugin quickly, and its table of contents promises sections on building, on plugin formats, on example plugins and on licensing, none of whose text appears in what is visible here, since the file stops inside the features list. The one place the readme does commit to a workflow is the template, which is the shortest path from nothing to a building plugin and the only end-to-end route the readme gives.

Nine shipped plugins, twelve example crates and three GUI toolkits in parallel, all of them workspace members of one manifest

The workspace manifest is a better map of the project than the readme. It lists seven framework and tooling crates, including a derive crate, three separate GUI integration crates, and two task-runner crates. It then lists twelve example plugins and nine shipped plugins, so every plugin named in the readme is also its own workspace member and therefore its own crate. The GUI story is the widest part of the layout: three toolkit integrations, each paired with a gain plugin and a bring-your-own-GUI example, giving three parallel integrations and two integration styles. The examples cover the two integration styles three times over, and they include a synthesiser and a MIDI example rather than only the gain plugin the three toolkits are paired with, plus a transform and a system-exclusive example, so the workspace covers effect, instrument and utility plugins rather than effects alone. The shipped plugins are described honestly, including one whose readme says outright that it is a joke and one whose description asks a rhetorical question and answers it. Three separate GUI toolkits maintained alongside a framework in maintenance mode is a large surface for one person. The documentation lives on the author's own domain rather than on a shared host, and the platform gatekeeping caveat sits in the plugin section rather than in an install section, because there is no install section, so the platform caveat is easy to read past, and it applies to every binary on that page rather than to one of them.

Two plugins derive from named commercial work and the strength of the credit tracks how close the derivation is

The plugin descriptions name their sources, and it is worth reading how differently they are handled. One is described as a straightforward port of a named commercial plugin, with the reason given as the author liking the distortion and wishing it had oversampling, and the credit given explicitly to the plugin's author. Another is described only as inspired by a video about a distortion effect, with no further attribution. A third is positioned as an alternative to a named competing product's multiband device, with the claim being cleaner crossovers and a linear-phase option. So the catalogue contains one acknowledged port, one acknowledged inspiration from a video, and one direct competitor reference, and the strength of the credit matches the closeness of the derivation. None of the three appears to be declared as licensed under anything other than this repository's own terms, and the file lists one licence for the whole workspace, so there is no per-plugin licensing note to check and no way to tell from the repository whether a given plugin may be redistributed separately from the rest.

Editorial conclusion

nih-plug suits someone who wants a small, explicit Rust audio plugin rather than a framework with a runtime, because the whole model is a macro on your library and a derive on your parameter struct, and because the allocation-checking feature makes real-time mistakes fail loudly in debug builds rather than silently on stage. Verify five things first. The readme's first line sends framework users to a community fork on a different forge, so check which repository you are actually depending on before you read anything else. There is no versioned release, only a rolling tag that is overwritten, and the crate version is a placeholder zero. macOS users have to switch off the platform's own gatekeeping to run the binaries. The default feature set builds only one of the two supported plugin formats. And several plugins in the catalogue derive from named commercial work, so read the credit lines before reusing an idea or shipping the result.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. robbert-vdh/nih-plug on GitHub