[FEATURE/PROPOSAL] Conditional NAM: train one model from multiple amp control settings

[PaulCORDON]

Summary

Currently, a NAM model represents a single fixed operating point of an amplifier:

audio_in → model → audio_out

If an amplifier has physical controls such as Gain, Bass, Middle, Treble, Presence, etc., changing one of these controls changes the behavior of the amplifier itself. A conventional NAM capture therefore represents only one specific configuration.

As a result, users who want to represent several settings of the same amplifier generally need to provide several independent .nam captures.

This proposal is to investigate a conditional NAM model that can represent multiple amplifier configurations in a single model:

audio_in + control_values → audio_out

For example:

DI + [Gain=7, Bass=4, Mid=6, Treble=8] → amplifier output

The goal would be to expose continuous control parameters in the resulting model, allowing a user to move virtual amplifier knobs rather than switching between independent captures.

---

Motivation

Multiple captures of the same amplifier already contain much of the information required for this concept.

For example, a user might currently provide:

JCM800_Gain5_Bass5_Mid5_Treble5.nam
JCM800_Gain6_Bass5_Mid5_Treble5.nam
JCM800_Gain7_Bass5_Mid5_Treble5.nam
JCM800_Gain7_Bass3_Mid7_Treble8.nam
...

Today these are independent models.

Instead, the proposed training process would treat them as samples of a larger function:

output = f(audio, controls)

where controls contains the normalized physical control positions.

This could potentially turn a collection of captures into a single parametric model.

---

Existing A2 infrastructure

This proposal is motivated by the fact that the current A2/WaveNet implementation already contains several mechanisms that appear relevant to this problem:

• condition_size exists in WaveNet layer configurations.
• WaveNet supports conditional inputs.
• condition_dsp is already represented as a nested WaveNet.
• A2 contains multiple FiLM conditioning points.
• The current A2 configuration infrastructure therefore appears capable of representing models whose behavior depends on an additional conditioning vector.

The proposal is not to assume that the existing conditioning implementation already solves this problem.

Instead, the question is whether the existing mechanisms can be reused with a conditioning vector representing amplifier controls.

For example:

condition = [
    gain,
    bass,
    middle,
    treble,
    presence
]

with each value normalized to [0, 1].

---

Proposed training representation

Instead of training independent datasets:

input.wav → output.wav

we would train samples conceptually represented as:

input.wav
output.wav
controls.json

For example:

{
    "gain": 0.70,
    "bass": 0.40,
    "middle": 0.60,
    "treble": 0.80,
    "presence": 0.50
}

The model would then learn:

f(input_audio, control_vector) = output_audio

The existing NAM input signal could initially be kept unchanged.

There is no requirement at this stage to introduce a new excitation signal or multiple types of test signals.

Using the same input signal for every amplifier configuration also has an important advantage: differences between captures are primarily attributable to the amplifier control configuration rather than to differences in the input signal.

---

Capture protocol

A new capture tool could orchestrate the creation of the dataset.

The user would first describe the amplifier:

Amplifier:
    Manufacturer: Marshall
    Model: JCM800 2203

Controls:
    Gain      [0..10]
    Bass      [0..10]
    Middle    [0..10]
    Treble    [0..10]
    Presence  [0..10]

Potentially, controls could also have metadata such as:

type:
    gain
    tone
    volume
    switch

and discrete controls could be represented differently from continuous controls.

The tool would then generate a capture plan.

For each capture:

1. Display the required amplifier settings.
2. User sets the physical controls.
3. User confirms the configuration.
4. Software plays the standard NAM input signal.
5. Software records the amplifier output.
6. Software validates the recording.
7. Software associates the recording with the exact control vector.
8. Continue with the next configuration.

The user should not have to manually rename files or construct metadata.

---

Sampling strategy

The capture tool should not simply generate a regular grid.

For N controls with M positions per control, a full factorial grid quickly becomes impractical.

For example:

5 controls × 11 positions each

11^5 = 161,051 configurations

Therefore the capture plan should select a relatively small subset of the parameter space.

A possible first implementation could use a space-filling design such as:

• Sobol sequences
• Latin Hypercube Sampling

The important point is that the exact sampling algorithm should remain experimental.

The goal is to determine which strategy gives the best reconstruction of the amplifier behavior for a given number of physical captures.

---

Adaptive sampling

A potentially more powerful second stage would be adaptive dataset generation.

The workflow would be:

Initial sampling
      ↓
Initial training
      ↓
Evaluate on unseen configurations
      ↓
Find regions with high error
      ↓
Generate additional capture configurations
      ↓
Capture those configurations
      ↓
Retrain
      ↓
Repeat

This would allow the system to concentrate captures where the model has difficulty.

For example, the model might perform extremely well for:

Gain 0–7

but poorly around:

Gain 8–10 + Bass 0–3

The next physical captures could then concentrate in that region instead of wasting captures in already well-characterized regions.

This could substantially reduce the number of physical amplifier captures required.

---

Validation requirements

A major concern is interpolation.

A conditional model should not only reproduce the exact configurations that were captured.

For example, if the dataset contains:

Gain = 5
Gain = 7

the model should produce a plausible and accurate result at:

Gain = 6

without having seen that exact configuration during training.

Therefore the dataset should be explicitly divided into:

Training configurations
Validation configurations
Test configurations

The test configurations must contain control combinations that were not used during training.

Evaluation should include at least:

1. Exact reconstruction of captured configurations.
2. Interpolation between captured configurations.
3. Multi-dimensional interpolation.
4. Behavior near control extremes.
5. Smoothness when continuously varying a control.
6. Interaction between controls.

---

Smoothness is an important requirement

A model could theoretically achieve a low average reconstruction error while still producing undesirable behavior when a control is moved continuously.

For example:

Gain 5 → 6 → 7

should produce a smooth evolution of the amplifier response.

The evaluation should therefore include sweeps through the parameter space.

A useful test would be:

Hold:
    Bass = 5
    Middle = 5
    Treble = 5
    Presence = 5

Sweep:
    Gain = 0 → 10

and compare:

real amplifier sweep
vs.
conditional model sweep

The same should be performed for each control and for selected combinations of controls.

---

Important question: what should be conditioned?

Not every amplifier control necessarily affects the same part of the signal chain.

For example:

Gain

may strongly affect nonlinear preamp behavior.

Whereas:

Bass / Middle / Treble

may primarily affect filtering.

And:

Master

may affect a different part of the amplifier depending on the circuit.

Therefore the first prototype should probably not attempt to reproduce every possible amplifier control.

A good initial experiment would use a small number of controls, for example:

Gain
Bass
Middle
Treble

and establish whether a single conditional model can successfully reproduce those four dimensions.

---

Potential dataset format

The exact format should be discussed, but conceptually:

capture_set/
├── metadata.json
├── input.wav
├── captures/
│   ├── capture_0001/
│   │   ├── output.wav
│   │   └── controls.json
│   ├── capture_0002/
│   │   ├── output.wav
│   │   └── controls.json
│   └── ...
└── calibration.json

metadata.json could contain:

{
    "manufacturer": "Marshall",
    "model": "JCM800 2203",
    "controls": [
        {
            "name": "gain",
            "type": "continuous",
            "min": 0,
            "max": 10
        },
        {
            "name": "bass",
            "type": "continuous",
            "min": 0,
            "max": 10
        }
    ]
}

This would also extend naturally from the existing concept of capture sets and control metadata.

---

Backwards compatibility

Existing single-capture NAM models should remain unchanged.

A conventional model would simply have no conditioning inputs.

A conditional model would explicitly declare its conditioning inputs.

This would allow existing NAM plugins and players to continue loading conventional models while future software could support conditional models.

---

Runtime API

A conditional model would require an inference API capable of receiving the control vector.

Conceptually:

model.process(
    input,
    output,
    controls
);

where:

controls = {
    gain,
    bass,
    middle,
    treble,
    presence
};

For real-time use, controls would normally remain constant for a block or be updated between processing blocks.

This would allow plugin/UI implementations to expose normal amplifier-style knobs.

---

Compatibility with A2

The first proof-of-concept should preferably reuse the existing A2/WaveNet conditioning mechanisms rather than introducing an entirely new neural architecture.

The experiment should answer:

1. Can the existing condition_size mechanism represent a control vector?
2. Can the existing FiLM mechanisms effectively condition the audio network on that vector?
3. Does condition_dsp provide any advantage over directly conditioning the main WaveNet?
4. How many captures are required for acceptable interpolation?
5. What sampling strategy minimizes the number of physical captures?
6. Is inference performance acceptable for real-time plugin/mobile use?

If the existing architecture cannot provide sufficient quality, a new architecture can then be considered based on the results.

---

Proposed proof of concept

A deliberately small experiment could use a real amplifier with four continuous controls:

Gain
Bass
Middle
Treble

Suggested initial dataset:

~50–100 physical configurations

using a space-filling sampling strategy.

Reserve approximately 15–20% of configurations as unseen validation/test points.

Train:

standard NAM

on one selected configuration as a baseline, and:

conditional A2

on the entire capture set.

Then compare the conditional model against the real amplifier at:

• captured configurations;
• unseen interpolated configurations;
• random unseen combinations;
• control sweeps.

The objective is not initially to achieve production quality.

The objective is to determine whether one conditional A2 model can learn a continuous family of amplifier states from a manageable number of physical captures.

---

Expected outcome

If successful, this would change the capture model from:

One capture = one model = one amplifier state

to:

One capture set = one model = an amplifier operating space

For the end user, this would mean:

                 Gain
                  ↓
             ┌─────────┐
Bass ───────►│         │
Middle ─────►│  NAM    │────► Audio
Treble ─────►│         │
             └─────────┘
                  ↑
             Presence

Instead of distributing:

Amp_Preset_01.nam
Amp_Preset_02.nam
Amp_Preset_03.nam
...

a capture creator could distribute one conditional model representing the amplifier and its controls.

---

Open research questions

Before implementation, the following should be investigated:

• How many control dimensions can be practically supported?
• How many physical captures are required per control?
• Are Sobol/LHS designs better than manually designed grids?
• Does adaptive sampling significantly reduce the number of captures?
• Should the conditioning vector be injected directly into FiLM?
• Should controls be encoded continuously or with learned embeddings?
• Should different controls be injected at different network depths?
• Does Gain require a different conditioning strategy from tone controls?
• Should discrete controls such as channel switches be represented separately?
• Can the model extrapolate safely outside the captured parameter range, or must all controls be clamped?
• How should Master be handled when it changes the power-amp operating point?
• What inference API changes are required in NeuralAmpModelerCore?
• How should conditional models be represented in the .nam format?
• Can existing real-time fast paths support conditional models, or should they explicitly fall back to the generic WaveNet path?

---

Why this is worth investigating

This proposal does not require changing the fundamental NAM capture concept.

The existing capture workflow already produces the required audio input/output relationship.

The key addition is to retain the amplifier configuration as structured data and train one model over multiple configurations.

The current A2 infrastructure already contains general-purpose conditioning mechanisms, making this a potentially incremental research direction rather than a completely new model architecture.

The main unknown is therefore not whether the concept can be expressed mathematically, but whether the combination of:

capture count
+
sampling strategy
+
conditional architecture
+
training procedure

can reproduce an amplifier’s continuous control space accurately enough for practical use.

A small proof-of-concept could answer that question without requiring changes to the existing NAM ecosystem.

[sdatkinson]

Hi, Paul.

This feels very broad and surface-level. Can you research this repo and what I've said on this topic in the past and sharpen the ask here?

I'm open to re-adding parametric modeling ingredients to this repo, but my preference is not for this repo's code to take an opinion on many of the requirements you've stated and instead enable others to use it as their curiosity dictates. So the correct low-level primitives are interesting in terms of developing this repo, but how they're used at a higher level is not--that should be handled separately.

[cordonp]

Hi Steven,

Thanks, that makes sense. I’ve dug further into the existing A2 conditioning infrastructure and the previous parametric-modeling work, and I agree that my original proposal was too broad.

I’d like to narrow the scope to the low-level question: can the existing A2 conditioning primitives be effectively used to represent continuous model parameters?

From what I understand, A2 already provides most of the relevant building blocks:

condition_size
conditional inputs / condition_dsp
multiple FiLM injection points
configurable FiLM scale/shift mechanisms

There is also existing work outside the main repo exploring parametric NAMs using ConcatWaveNet and HyperWaveNet. So rather than proposing another parametric architecture, I’d like to experimentally compare these approaches using the existing A2 infrastructure.

My plan is now deliberately small:

Finish a minimal proof-of-concept showing that FiLM can learn a continuous audio transformation from a control parameter.
Move the same experiment to the actual A2 architecture, initially with a single continuous parameter such as Gain.
Test where conditioning is most effective within the existing A2 FiLM injection points.
Extend this to a small multi-parameter case such as Gain + Tone and evaluate interpolation on configurations that were not present during training.
Compare the resulting A2/FiLM approach against the existing ConcatWaveNet and HyperWaveNet approaches using the same dataset and evaluation procedure.

The goal is not to define a complete parametric-capture workflow, dataset format, UI, sampling strategy, etc. Those would remain outside the core repository.

Instead, I’m trying to answer a much narrower question:

What generic conditioning primitives, if any, are worth exposing or improving in NAM Core so that external projects can build different kinds of conditional/parametric models on top of them?

If the experiments show that the existing A2 primitives are already sufficient, that is also a useful result — in that case there may be little or nothing to change in NAM Core.

I’ll come back with experimental results rather than proposing a specific implementation upfront.

[michalwarda]

We've been working together with my team on a parametrized NAM A2 for the past 3 weeks.
Already did around 500 experiments on different architectures, training approaches, training data distribution and aquiring etc.
A lot of it. We're currently at a stage where we need ~100 different position recordings for a 5 knob amp. Our current global weighted esr is around 0.01 with ability to represent multiple volume, gain, master knobs in the same model, presence etc. and switches.
Architecture goes hand in hand with the training process. IMHO it's impossible to define one film architecture and say this one is the best no matter what data you use to train. Also there are different approaches like MoE, adapters and waaaaay more. It all depends where are you willing to spend more compute or memory or UX during training. It's a balance.

[cordonp]

That's very interesting, especially the ~100 recordings / 5 knobs / ~0.01 weighted ESR result.

I agree with your point that architecture and training data can't really be optimized independently. I'm currently exploring this from a more incremental A2/FiLM perspective, but your results suggest that I should broaden the experiments rather than assuming FiLM is the solution.

If you don't mind sharing a bit more, I'd be particularly interested in:

what architecture you're currently using;
how the ~100 parameter configurations are distributed;
whether the ~0.01 ESR is measured on completely unseen configurations;
and how you define/calculate the global weighted ESR.

I'm mainly trying to understand which part of the problem is actually the limiting factor: architecture capacity, parameter-space sampling, or training strategy.