NAM: Neural Amp Modeler

I reached out to the NAM FB group and found out that most people are training with 1000 Epochs. Are you guys also capturing with those settings?
 
Sascha Franck said:
Thanks.
Would/could that be different in case I'd be using Melda's MGuitarArchitect?
Click to expand...

Actually have no idea and no way to try - so it's worth a shot! Would be interesting to know. I want to say it's due to the plugin (iplug) and not nam-core so it would depend on how he implemented it
 
I've got it running on orange pi5B by building your LV2 and loading it in ardour! I don't think it's 100% glitch free but after I unset the memlock and increased realtime priority for my user account the DSP running a standard NAM is about 60% reported latency is around 2.7ms (so ~6 RTL) but I haven't actually measured it. That's at 48k/128 buffer with my evo 4 via ALSA
 

Attachments

  • sPXL_20230820_090927337.MP.jpg
    sPXL_20230820_090927337.MP.jpg
    252.2 KB · Views: 111
  • sPXL_20230820_090951000.jpg
    sPXL_20230820_090951000.jpg
    356 KB · Views: 105
Last edited:
northern_fox said:
@Mike Oliphant - what were you using to run NAM on pi right now? Is it via your lv2 with patchbox/modep?
Click to expand...

I'm actually using my own software on top of jackd. Performance of the lv2 should be essentially the same, though, since the important stuff is in the NAM core code.

On Windows, the lv2 plugin seems to use a lot more CPU in Ardour than it does in Reaper. I don't use Ardour much, though, so I don't know why. Maybe it is running two instances on a stereo track?

For me, standard NAM models run at about 70% CPU on a Pi 4 at 48K with a 64-sample buffer. Orange Pi 5 should be significantly faster than that.

Maybe try the Linux version of Reaper? You'll need a pre-release version to be able to select NAM models - they added the required support a while back, but it hasn't made it to an official release yet (it looks like it will come in v7.0).
 
Mike Oliphant said:
I'm actually using my own software on top of jackd. Performance of the lv2 should be essentially the same, though, since the important stuff is in the NAM core code.

On Windows, the lv2 plugin seems to use a lot more CPU in Ardour than it does in Reaper. I don't use Ardour much, though, so I don't know why. Maybe it is running two instances on a stereo track?

For me, standard NAM models run at about 70% CPU on a Pi 4 at 48K with a 64-sample buffer. Orange Pi 5 should be significantly faster than that.

Maybe try the Linux version of Reaper? You'll need a pre-release version to be able to select NAM models - they added the required support a while back, but it hasn't made it to an official release yet (it looks like it will come in v7.0).
Click to expand...
Ahh - I had not grabbed the pre-release, just the normal. I'll take a peek at that too. I think there's also something about cpu frequency scaling that could be improved somewhere on the system
 
So I tried training at 96kHz - after some code rewrite to support it on the trainer.

Now, this is far from scientific for several reasons - but read the description in here:
tonehunt.org

Mesa Dual Rec Dirty Trees Modern Red 48kHz/96kHz Test | ToneHunt

Here are 3 captures of the same amp/settings. The differences are as follows: Dual Rec 3CH DT 48kHz - Normal capture at 48Khz Dual Rec 3CH DT 48kHz as 96kHz - the same reamp as the 48kHz capture, but exported from DAW at 96khz resampling, and trained at 96 kHz. You *must* run NAM at 96...
tonehunt.org tonehunt.org

I don't trust myself to speculate on aliasing, so I'll leave that to someone who knows what they're measuring if they want to give that a try. In a nutshell: I used the same settings/training file/trainer settings for everything, varying recording sample rate and export sample rate. I can't hear any audible difference to be perfectly honest, between all 3 files even though the ESR is slightly different.

Make sure to actually run NAM at 96kHz if you want to test the 96kHz captures.
 
Senor Blues said:
New version up today resamples, not limited to 48k now.
Click to expand...

The new version will resample the I/O to 48 kHz internally, so there's nothing new to be gained in terms of aliasing or anything - but you *can* use it with any project sample rate now. Ironically, this will also prevent you from using a 96kHz capture now I think because it'll be forced to 48, but that wasn't really a thing people did in the first place so it's fine for now.
 
northern_fox said:
The new version will resample the I/O to 48 kHz internally, so there's nothing new to be gained in terms of aliasing or anything - but you *can* use it with any project sample rate now. Ironically, this will also prevent you from using a 96kHz capture now I think because it'll be forced to 48, but that wasn't really a thing people did in the first place so it's fine for now.
Click to expand...
did the 96k capture alias less? if the plugin can resample internally now it would be cool if it can play higher sample rate models at any sample rate
 
MirrorProfiles said:
did the 96k capture alias less? if the plugin can resample internally now it would be cool if it can play higher sample rate models at any sample rate
Click to expand...

If you see my post just up above, it was generally inconclusive for me. I'm not really sure how to judge/measure that properly to be honest. But I can tell you it used 2x the CPU with zero audible difference to me


It could support multiple rates in theory, but I wouldn't expect that Steve is going to implement that anytime soon (if at all). It's also more of a pain to train
 
I think the resampling is very useful in an specific use case: if you have a multieffects that only has 44.1kHz USB audio, you can now use it as audio interface with NAM. And if the unit routing can handle it, with reamp an I/O options, you can even use its internal effects pre and post NAM. Cool.
 
Last edited:
Sedaxel said:
I think the resampling is very useful in an specific use case: if you have a multieffects that only has 44.1kHz USB audio, you can now use it as audio interface with NAM. And if the unit routing can handle it, with reamp an I/O options, you can even use its internal effects pre and post NAM. Cool.
Click to expand...
I love that resampling is now a thing in NAM; hopefully training models at different rates is going to make its way into the trainer soon.
 
northern_fox said:
If you see my post just up above, it was generally inconclusive for me. I'm not really sure how to judge/measure that properly to be honest. But I can tell you it used 2x the CPU with zero audible difference to me


It could support multiple rates in theory, but I wouldn't expect that Steve is going to implement that anytime soon (if at all). It's also more of a pain to train
Click to expand...
Ah fair, I didn’t know if there had been any updates with it since.

I was briefly looking at NAM in plugin doctor to see if I could determine much about the resampling but it crashed. The aliasing at 48kHz was high, so that’s why it was on my mind.
 
MirrorProfiles said:
Ah fair, I didn’t know if there had been any updates with it since.

I was briefly looking at NAM in plugin doctor to see if I could determine much about the resampling but it crashed. The aliasing at 48kHz was high, so that’s why it was on my mind.
Click to expand...

I stopped paying attention to it (aliasing concerns) once I realized I couldn't tell the difference between the real amp and the capture in a blind listening A/B. It may be measurable, but at least with profiles I've made and have the reference audio for, it doesn't seem to make an audible difference to me and the null test tends to confirm that (as long as the ESR is good).

The crash though has a fix - which I suspect he'll release ASAP
 
You must log in or register to reply here.

Similar threads

B
Tried to match some more Vox tones with NAM
Replies
0
Views
141
bikescene
B
Back
Top