Architecture "A2"

In quarter 1 of 2026, I plan to develop and release a new default architecture for snapshot NAM models. I'm going to name this architecture "A2". Here's the plan.

What's going to happen

Nothing is going away. The existing "standard WaveNet" and friends (now called A1-standard, A1-lite, A1-feather, A1-nano) will continue to be supported. If you have old models, they will still run in NeuralAmpModelerCore, and NeuralAmpModelerPlugin will load them. Your DAW projects that use existing models will continue to work with no differences. If you want to train an A1, that should still be possible without needing to access an older version of the code.

A2 will supersede the current default. Moving forward, I'm going to refer to the current WaveNet "standard", "lite", "feather", and "nano" architectures as "A1" ("architecture 1"). When you train a NAM using the Colab notebook, you will get an "A2" model.

TONE3000 is generously supporting development work on this project--thank you! When everything is finished, their online trainer will give you A2 models by default as well. TONE3000 will also re-train all A1 models that were originally trained on their platform so that you can have their A2 equivalents immediately in the usual ways (in your browser, via their API, etc). The A1 models will stay available.

If you want to help this work by participating in listening tests, sign up here.

The goal

The goal is for A2 to be...

1. a lighter, better, slimmable NAM.

2. Designed with input from the industry.

A2 will be industry-informed

When I first defined the "standard WaveNet", I didn't realize how broad its impact would be. Today, NAM is run on all sorts of personal computers with all three major operating systems (Windows, macOS, Linux), single-board computers like Raspberry Pi, embedded systems like on the DIMEHEAD NAM Player, and websites like TONE3000. Few technologies in audio are used in more places than NAM--the only that I can think of is impulse responses.

This means that any changes that are made to A1 are heavily-constrained. I take breaking compatibility very seriously. The way that I'd like to steward this responsibility is by getting technical information from folks in the industry who are building with NAM. If you have technical requirements for A2, then get in touch--I want this work to take your input into account.

The most constrained applications of NAM are hardware using embedded systems. These are also the ones that NAM adoption has struggled most with--at 13.8 thousand parameters, A1-standard is a very big chunk of compute by embedded standards.* With A2, I want to know exactly how much is too much, and respect that constraint in designing A2. More on this below--I need input for this part to work!

A2 will be better

NAM has a reputation for allowing people to get a better model of their gear than is possible any other way. But, there are a lot of different factors that matter--not just modeling accuracy. In this section, I want to outline everything that I'm thinking of.

Below are the main high-level criteria I'm thinking of. Get in touch if I'm missing anything, or if you think that any of the specifics should be tweaked.

Modeling accuracy

NAM is fundamentally solving a regression task. The simplest way to measure accuracy is by asking whether the samples outputted by the NAM match the samples that come from the original signal chain. A typical ML metric here is mean squared error; error-signal ratio (ESR) is just a normalized version of the same metric that factors out the level of the reference audio, and the null test is equivalent to the mean-squared error--just in decibels. However, the frequency content of the predictions (and targets) matter as well. To encourage this, A1's training recipe asks for the spectrograms of the predictions and targets to match.

Additionally, these metrics depend on what is being predicted on. NAM is a data-driven modeling technology, so the choice of data matters--both for effective training and for meaningful evaluation. My position is that musical content is more relevant for evaluation than test tones since it represents the actual context in which most NAMs will be used.** So, I plan to use guitar DIs (or DIs through common pedals) as the inputs that the evaluation cases will be based on. [The training data that yields the best results for those cases will be studied. More on that in a bit.]

Third, what works in one context often doesn't work in others. Among machine learning applications, NAM has genuinely surprised me for how reliably a single training recipe could tackle such a wide world of gear. For the time being, I expect that the recipe for A2 will remain "one size fits all". Specifically, the model architecture is what I'm most committed to holding constant. As far as evaluation, I intend to use a wide variety of gear to get a holistic picture of A2's behavior. The focus will remain primarily on guitar and bass gear pedals and amplifiers. Modeling speaker cabinets and microphones is sufficiently different that a different approach can be used to get good results far more efficiently.

Lastly, it's good to remember that the ultimate goal of all this is to make musicians happy. Therefore, I'm looking to conduct subjective listening tests to supplement the evaluation. If you want to participate, then fill out this form so that I can contact you when the time comes.

CPU usage

This is the most interesting avenue for improvement with A2. Based on my preliminary work, I believe that NAM can meaningfully reduce CPU usage while not regressing on accuracy.

There are two ways where A2 will simultaneously explore this. The first is via typical hyperparameter optimization--the number of layers, number of channels, etc, can be varied to get models with different accuracy and CPU usage (see: lite, feather, nano, and a variety of other models that members of the community have come up with). With A2, I intend to do a more thorough, principled investigation to make sure I'm making the right decision versus A1, which was mainly designed based on my intuition with neural networks.

The second tool I plan to use for A2 is slimmable NAM, which allows a trained model to trade off CPU for accuracy. I plan for the full-size A2 to be comparable to A1, and for slimmed A2 to be an attractive solution for more compute-constrained applications, enabling NAM to be run "natively" in more situations (instead of as the reference material for conversion to another modeling engine).

This is where I need stakeholders' input. In order to make sure that the new model uses an acceptable amount of CPU, I need quantitative data from target hardware platforms. More details on how I propose to do that below.

Training time

To my knowledge, training an A1-standard NAM on TONE3000 is the fastest of any currently-available "batteries included" neural training recipe. GPUs cost money to run, and keeping training times short is key to making simple training resources accessible. Minding this and what seem to be the developing norms in this space, I intend for the above accuracy to be achieved under a compute constraint of 10 minutes on a reasonable computer. I'm going to be ironing out those details, but my point for now is that I consider this to be an important consideration.

Recording time

It also matters how long you need to spend reamping your gear to get the data needed. I feel that keeping to a limit of about 3 minutes seems like a reasonable constraint to take.

How you can help

If you're building with NAM, then I want to hear from you. Here's how I propose to tackle this project.

Stage 1: New core DSP features

I'm going to add a number of features to broaden the flexibility of NeuralAmpModelerCore. These will help me explores some opportunities where my intuition tells me there's juice to squeeze. A2 might or might not use all of them; the immediate goal is to define the limits of the search space. Once it's done, I'll be releasing NeuralAmpModelerCore v0.4.0; you'll be able to get it from the releases page.

Stage 1 should be complete in the next few days.

Stage 2: Implement support for features

In order for you to give me information about CPU usage, you need to implement NeuralAmpModelerCore 0.4.0 on your hardware. The focus will be on the WaveNet architecture, so you can prioritize that. Any products that run NAM currently should expect to update their code to run NeuralAmpModelerCore v0.4.0 in order to be compatible with A2 when it's announced. I expect it will be about 2 months after the release until A2 is finalized.

Stage 3: Collect CPU usage data on target devices

I will develop a set of models; I'll need you to run them on your hardware and tell me how much CPU they use. I'll also need to hear how much is too much for you (presumably NAM won't use 100% of the available CPU). This information will help me understand the relationship between various architecture hyperparameters and how much CPU a model of that size would require on your hardware.

Example

Suppose I gave you 4 models--an A1 standard, lite, feather, and nano. You would put them on your hardware and measure how long it takes to process one second of audio, then tell me the result. If I do this on my laptop using the benchmodel tool in NeuralAmpModelerCore, I get these results and plot them against the number of channels in their first layer array. I can also say that perhaps I want to keep it under 60 ms to process 2 seconds of audio (3% CPU usage):

Based on this information, I can tell that something like a "feather" would work--and maybe something a little bigger--but not a "lite".

This is a simplification of how the analysis works in practice, but hopefully gives you a rough idea of how this data can help me check my work.

I should have the set of models complete a few days after the completion of Stage 1. I hope to have your Stage 3 results by early February.

Stage 4: Optimize A2

At this point, I'm going to get to work running experiments trying out different architectures. Everything I try will be within the "span" of what NeuralAmpModelerCore v0.4.0 can do, so any "answer" I come up with should be compatible with the code you already have. This is the point at which I figure out exactly how to achieve the above objectives will meeting your requirements.

Stage 5: Final evaluation

After figuring out a solution in Stage 4, we'll do final evaluations--ensuring that the model meets the CPU constraints it needs to, and doing subjective listening tests to verify the results. Expect this to happen at the beginning of March.

Pending successful final evaluation results, we'll lock it in, and we'll have a new default NAM architecture!

What's next?

Stay tuned for a release announcement for NeuralAmpModelerCore v0.4.0. You'll want to integrate it as soon as possible to be ready for Stage 3. I'll be updating on this project here on my blog; email me directly if you need to, and I'll be happy to shoot out a little email blast as updates come out.

Thanks!

Footnotes

*13.8k parameters is also about 10 million times smaller than a typical large language model today. This really is a strange application of deep learning! Back

**This isn't to say that other contexts are "wrong", but it is what I think deserves prioritization for a default recipe. NAM remains open-source and completely customizable for other applications. Back