Due to Zynthian has direct access to Tone3000 (T3K), I want to share my first amp capture of my lovely Hughes & Kettner Grandmeister 36 also here.
Have fun and play it loud!
You also need to add an IR of your favorite cabinet. This is only an amp capture!
When going through zynthian, this cannot be selected, tone3000 saying it is incompatible with my architecture.
Looks like something A2 versus A1 (legacy). My Zynthian is updated (vangelis beta).
Anybody knows what’s going on there, and what we can expect to be supported?
Yes, I think that’s the problem.
We would need a “NAM-A2 player” on Zynthian and i might try to convert my profiles to A1.
I will take a look at this…
(Ok, training will take ~2h per profile capture… I will go for a faster machine and startup again 
)
Okay, downloaded it manually to Zynthian, the NAM plugin loads it, and the current Ratatouille does not (A2 models are selectable, but when leaving the file dialog the value is reset).
Okay, the t3k integration in Zynthian does not send the architecture field to t3k.
When adding "architecture": 2, to the authorize url (in lib/t3k_handler.py) I am able to select A2 models. And it seems that if they also support a1, these can be used in ratatouille.
Currently, only NAM engine can load A2 models.
Good point! Thanks for reporting. I will try to create a fix for this the next days.
I now added A1 (0.5.x) profiles to my T3K captures. The A1 (0.7.0) profiles are currently created and wil be added soon.
@niels you are right: API docs says:
architecture: Filter by model architecture. Accepts 1 (A1), 2 (A2), or custom. Omitting falls back to A1 + Custom (legacy default; excludes A2). Applies to select_tone and load_tone flows.
Thanks for putting the captures up, and for chasing the A1/A2 filter down to the actual API parameter — that’s a genuinely useful find, because the failure mode (“selectable, then the value silently resets when you leave the file dialog”) is exactly the kind of thing people would otherwise report as a broken capture rather than an architecture mismatch.
Two thoughts on the fix, since it’s being worked on anyway.
Defaulting the architecture parameter based on which engine is actually loaded would be nicer than sending 2 unconditionally. If the target is Ratatouille, offering A2 models it can’t load just reproduces the same dead end from the other direction. If the handler knows the engine, it can request A1 for Ratatouille and A1+A2 for NAM, and nobody has to know the architecture generations exist.
Failing that, the browse list showing the architecture tag inline would at least make the mismatch visible before the download rather than after.
On the re-training: 2h per capture is a lot of GPU time to spend twice. Worth checking whether the standard trainer can export an A1-compatible model from the same captured input pair rather than re-capturing — the reamp recording is the expensive part to get right (levels, latency alignment), and that file is architecture-agnostic. If you’ve kept the raw input/output wavs, re-running training at a different architecture is just compute, and you can queue them overnight instead of doing them one at a time.
One tuning note on the amp itself: on a GrandMeister the sag and power-amp response change quite a lot with the master volume, and a capture bakes in whatever position you had. If you’re regenerating anyway, capturing two masters — one edge-of-breakup, one wide open — usually turns out more useful than two architectures of the same setting.
Also worth stating in the T3K description that these are head-only and need an IR, since you mention it here but people often grab the file from the browse list without reading the notes and then wonder why it sounds like a fizzy DI.