I think people are underestimating how hard this is to add to Quad Cortex.
Quad Cortex is not like a normal computer where Neural DSP can just install NAM A2 as a plugin. The audio processing runs inside a very specific real-time DSP system (SHARC). Everything has to be extremely optimized, low-latency and stable.
So even if NAM A2 sounds amazing, adding it to Quad Cortex is not just a matter of building the existing code and running it. NAM’s DSP/inference code would likely need to be adapted, optimized, or partly rewritten for the SHARC architecture used in the QC audio path.
SHARC DSPs are powerful for real-time audio, but they are not desktop CPUs. They have their own constraints and bottlenecks: memory layout, limited fast local memory, DMA/cache behavior, SIMD/vectorization differences, fixed audio block sizes, and very strict real-time deadlines. A neural model that runs fine on a PC, or even on a simple dedicated embedded pedal, does not automatically fit cleanly into an existing multi-block QC preset with amps, cabs, effects, routing, scenes, and low latency.
That is a very different job from PCOM, where Neural DSP are mainly porting their own plugins into their own ecosystem. Supporting NAM A2 would mean integrating an external model format and inference engine into the core DSP platform. That is a much bigger engineering and maintenance problem.
Also, Neural DSP may not need to support NAM A2 directly to get better results. They can use the same kind of data, research, and newer modeling ideas to improve their own capture system. That would probably be easier to integrate and more realistic than turning Quad Cortex into a general NAM host.
I fully support better captures. I just think “add NAM A2” is a much bigger engineering request than it sounds.
If someone specifically wants to use NAM A2 today, they can use a separate pedal or embedded Linux device that supports it and put it in the Quad Cortex effects loop. That is probably the more realistic short-term solution.
But latency still matters. A Linux-based pedal is not automatically bad, but its real-world latency depends heavily on the audio implementation: buffer size, drivers, scheduling, converters, and how optimized the inference engine is. In an effects loop you also add another round of AD/DA conversion, so the total round-trip latency should be checked rather than assumed.