Model or dataset
mikeoliphant/neural-amp-modeler-lv2 avatar
mikeoliphant/neural-amp-modeler-lv2

neural-amp-modeler-lv2: NAM Amp Models Without a GUI

Neural Amp Modeler LV2 plugin

536 stars56 forksC++GPL-3.0

At a glance

What is it?
An LV2 plugin that runs Neural Amp Modeler and RTNeural amp models through the NeuralAudio engine. It has no custom user interface, so model selection depends on your host supporting atom:Path parameters.
Who is it for?
Adopt it if your host supports atom:Path parameters, you already have 48kHz NAM or RTNeural models, and you are willing to follow the plugin with a cabinet impulse response. Do not adopt it if you need a graphical model browser or you run at a sample rate that is not an even multiple of the model rate.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 11 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem: playing trained amp models inside a DAW without a standalone app

Training an amp model is one half of the workflow. Getting that model to run at low latency inside a DAW session is the other half, and it is the half that usually forces a compromise. Standalone model players mean leaving the session. Plugins that ship a fixed model set mean you cannot use the capture you trained yourself. This plugin takes the direct route: it is an LV2 plugin that loads a model file from disk and runs it in the host's audio graph, so the model sits in the same signal chain as your other effects and can be automated or reordered like anything else. The intended user is a Linux or macOS guitarist or producer already working in an LV2 host, who has a .nam file or an RTNeural keras json model and wants it inside the session rather than beside it. The README points to Tone3000 as the recommended source of models, and notes that the model handling itself lives in the separate NeuralAudio repository, so this plugin is largely a host-facing wrapper around that engine.

What the plugin actually exposes to the host

There are four controls, and the README lists them plainly. Input is pre-model gain in dB. Output is post-model volume in dB. Quality applies only where the model format supports it: for NAM A2 models, a value below 0.5 selects the lite variant and a value above 0.5 selects the full variant. Model is the file path to the .nam file. That last one is the whole reason the plugin has compatibility caveats. Because there is no custom user interface, choosing a model means handing a file path to the plugin through the LV2 atom:Path parameter type, and the host has to be able to do that. The README names Reaper as of v6.82, Carla, and Ardour as hosts that support it, and notes a separate open issue affecting the current stable Carla release. For any host that does not implement atom:Path, the plugin will load but you will have no way to point it at a model. That is a hard dependency, not a rough edge, and it is worth checking before you build anything.

Model formats and where the processing code lives

Two model families are supported. The first is Neural Amp Modeler, both the A1 and A2 architectures. The second is RTNeural keras json models, which the README describes as the format used by Aida-X. That second format matters more than it might appear, because it means models trained for a different plugin ecosystem can be loaded here without retraining. The README defers all detail on model type support and performance to the NeuralAudio repository, stating that the model handling code lives there. That is an honest division of labour but it also means this repository's README is not a complete reference for what will and will not load. If you are evaluating whether a specific model architecture works, the answer is in NeuralAudio, not here.

Sample rate is a correctness constraint, not a preference

The README is explicit: to get the intended behavior you must run your audio host at the same sample rate the model was trained at, usually 48kHz, because the plugin does no resampling. This is the kind of constraint that produces confusing results when ignored. Nothing crashes. The model simply runs at the wrong rate and does not sound like the capture it is supposed to represent. There is one exception, and it is a useful one. If your host runs at an even multiple of the model sample rate, the model is correctly oversampled. A 48kHz model in a 96kHz session is 2x oversampled and behaves as expected. The README also notes that if your DAW has its own oversampling feature, you can use it safely, at what it calls a significant performance cost, which can be worthwhile for reducing aliasing. Odd multiples are not covered by this exception, so a 44.1kHz session with a 48kHz model falls outside it.

Input calibration at 12dBu and the cabinet problem

Two practical requirements sit outside the plugin's controls. The first is level. The expected input level is 12dBu, and models that carry input level information are calibrated against that figure. If you know your audio interface's input level, the README's instruction is to adjust your input relative to the expected 12dBu so the model receives the signal level it was trained on. Get this wrong and a model that sounds thin or muddy in isolation may just be under- or over-driven at the input. The second is the cabinet. For amp-only models, which the README calls the most typical case, you need to run an impulse response after this plugin to model the speaker cabinet. The plugin does not include one. That means a usable chain is at least two plugins, and the order matters. This is a design boundary rather than a defect, but it changes what a session template looks like.

Building it, and the two CMake options worth knowing

The build is a submodule clone followed by CMake. The README gives: git clone --recurse-submodules -j4 https://github.com/mikeoliphant/neural-amp-modeler-lv2, then cd into build, then cmake .. -DCMAKE_BUILD_TYPE="Release" and make -j4 on Linux or macOS. Windows uses cmake.exe -G "Visual Studio 17 2022" -A x64 .. followed by cmake --build . --config=release -j4, with the note that you change the Visual Studio version if yours differs. The output lands in build/neural_amp_modeler.lv2. Two options are documented. -DUSE_NATIVE_ARCH=ON enables processor-specific optimizations on a relatively modern x64 CPU. -DSMART_BYPASS_ENABLED=ON bypasses model processing when the input has been silent below -100 dB by default for a sufficient number of samples, where that number is determined by the model's receptive field size. The README also notes that NeuralAudio's own CMake options can be passed through this plugin's cmake invocation, which is how you reach engine-level settings without touching the submodule.

Where this plugin is the wrong choice

The absence of a GUI is the obvious limitation and it is worth stating without softening. If you want to browse models by ear, click through captures, or see a waveform while you audition, this is not the tool. The README itself points to alternatives: brummer10's neural-amp-modeler-ui for Linux and Windows, the version shipped with the MOD Desktop App, and the author's own Stompbox digital pedalboard. The distinction is architectural rather than cosmetic. Those projects put a model browser in front of the same kind of engine, while this one deliberately stays a headless LV2 node and pushes model selection into the host. A second limitation is the sample rate rule described above: if your session runs at 44.1kHz and your models are 48kHz, this plugin will not resample for you, and no CMake flag changes that. A third is the Carla issue the README links, which affects the current stable release of a host it otherwise lists as supported. Anyone whose workflow depends on Carla should read that issue before assuming the plugin will be selectable there.

Maintenance, licence, and what to check before adopting

The repository is GPL-3.0 licensed and has not been archived. Recent releases are close together: v0.2.1, v0.2.2, and v0.2.3 arrived within roughly a month of each other in mid-2026, with the last push to main in early September 2026. That cadence suggests active work, though the version numbers also indicate the project is still pre-1.0, so interface details can move. The GPL-3.0 licence is the practical consideration for anyone embedding this in a distributed product; the plugin links against the NeuralAudio engine, so if you plan to ship something built on it, the licence terms of both repositories are what you need to read. This is not legal advice, and the interaction between the two licences is a question for someone qualified to answer it. For a personal setup the licence is a non-issue. The concrete checks before you commit are the three named in the conclusion: atom:Path support in your host, a way to reference your interface input to 12dBu, and whether -DUSE_NATIVE_ARCH=ON earns its place on your machine.

Editorial conclusion

Adopt it if your host supports atom:Path parameters, you already have 48kHz NAM or RTNeural models, and you are willing to follow the plugin with a cabinet impulse response. Do not adopt it if you need a graphical model browser or you run at a sample rate that is not an even multiple of the model rate. Before committing, verify three things on your own system: that your host exposes the Model parameter as a file path, that your interface's input level can be referenced to 12dBu, and that a build with -DUSE_NATIVE_ARCH=ON actually improves your CPU headroom rather than just moving the bottleneck.

Official sources

  1. Issues
  2. License: GPL-3.0
  3. mikeoliphant/neural-amp-modeler-lv2 on GitHub
  4. README
  5. Releases
Community notes

Community notes