v0.4.3 — macOS ships a real signed .app; no more Gatekeeper warning

If you're on a Mac, this is the release you want. Every macOS build before this one — including v0.4.2 — throws Apple's "Apple could not verify this app is free of malware" warning on launch, with no obvious way past it. That's fixed, and it was my fault, not Apple's.

What was wrong

The app was genuinely signed with a Developer ID and genuinely notarized by Apple — that part was true, and the notarization came back Accepted on every build. But it was shipped as a loose Unix executable in the disk image instead of a proper .app bundle, and Gatekeeper refuses to approve a bare executable no matter how well it's signed. Its own verdict on the v0.4.2 download:

spctl → rejected (the code is valid but does not seem to be an app)

There was a second half to it. A notarization ticket can only be attached to a bundle, a disk image, or an installer — never to a loose binary. The ticket was stapled to the .dmg, so the moment you dragged the contents out, the thing you actually ran had no ticket attached to it at all.

Net effect: a correctly signed, correctly notarized build that still couldn't open. The README promised "signed + notarized, opens clean" and delivered two out of three.

What changed

• macOS now ships a real nam-a2a1-converter.app. Open the dmg, drag it to Applications, launch it. No warning, no right-click-Open trick, no trip to System Settings.
• The notarization ticket is stapled to the app itself, not just to the disk image — so it stays verified after you copy it out, and it verifies offline.
• The build now checks Gatekeeper's actual verdict before publishing and fails the release if it isn't accepted … source=Notarized Developer ID. This class of bug shipped because nothing ever asked macOS what it thought; now the release can't be cut unless it passes.

Nothing about the conversion changed. Windows and Linux builds are unaffected — same as v0.4.2 in every respect.

Already downloaded v0.4.2 on a Mac? Delete it and take this one. If you'd worked around the warning and it's running fine, there's no urgency — the app was never actually unsafe, it just couldn't prove it.

Downloads

Platform	File
macOS (signed + notarized .app)	nam-a2a1-converter-macos.dmg
Windows	nam-a2a1-converter-windows.zip
Windows + NVIDIA	nam-a2a1-converter-windows-cuda.zip.001 and .002
Linux x86_64	nam-a2a1-converter-linux-x86_64.tar.gz
Linux x86_64 + NVIDIA	nam-a2a1-converter-linux-x86_64-cuda.tar.gz.001, .002 and .003

The CUDA bundles ship as numbered parts because GitHub caps one release file at 2 GiB:

cat nam-a2a1-converter-linux-x86_64-cuda.tar.gz.0* > nam-a2a1-converter-linux-x86_64-cuda.tar.gz
sha256sum -c --ignore-missing nam-a2a1-converter-linux-x86_64-cuda.tar.gz.sha256
tar -xzf nam-a2a1-converter-linux-x86_64-cuda.tar.gz

Windows: download get-cuda-build.ps1 and run powershell -ExecutionPolicy Bypass -File get-cuda-build.ps1, or copy /b the two parts together by hand. Full detail is in the v0.4.0 notes.

Requires an NVIDIA card of compute capability 5.0+ with a current driver. Apple silicon uses its GPU automatically — nothing to download. Windows is still unsigned, so SmartScreen warns — More info → Run anyway.

v0.4.2 — hot captures no longer fail with "Output clipped."

One bug fix, and it's the one that made some captures refuse to convert at all.

"ValueError: Output clipped."

If a conversion died with ValueError: Output clipped. while other files went through fine, this release fixes it. Nothing was wrong with your .nam — it was just a loud one.

Here's what was happening. The converter works by rendering a DI through your A2 capture, then training an A1 to match that render. Neural Amp Modeler refuses to train on a target that reaches digital full scale, and it's strict about it: one single sample at the rail rejects the whole file. A hot capture — high-gain amp, a boost or drive in front — renders louder than full scale, and the converter was writing that render out unchanged. The 24-bit file pins anything at or below -1.0 to exactly -1.0, NAM sees the rail, and the run stops before training ever starts.

That's why it looked random. Quieter captures never hit the rail; anything with real gain in it did. It also only ever triggered on the negative half of the waveform, which is why two similar-looking captures could behave differently.

The converter now turns the render down before writing it, and puts the level back on the finished model afterwards. That last part matters: the output level is a single number in a .nam file, so restoring it is an exact edit, not a re-training and not an approximation. Your A1 comes out at the same volume as the A2 it came from, same as always.

Captures that already converted are unaffected — they were never near the rail, so nothing is turned down and nothing is put back. There's no reason to re-convert anything that already worked.

Thanks to the person on reddit who reported it. "Some files work, some don't" was the detail that made it findable.

Downloads

Platform	File
macOS (signed + notarized)	nam-a2a1-converter-macos.dmg
Windows	nam-a2a1-converter-windows.zip
Windows + NVIDIA	nam-a2a1-converter-windows-cuda.zip.001 and .002
Linux x86_64	nam-a2a1-converter-linux-x86_64.tar.gz
Linux x86_64 + NVIDIA	nam-a2a1-converter-linux-x86_64-cuda.tar.gz.001, .002 and .003

The CUDA bundles ship as numbered parts because GitHub caps one release file at 2 GiB. Rejoin them the same way as last release:

cat nam-a2a1-converter-linux-x86_64-cuda.tar.gz.0* > nam-a2a1-converter-linux-x86_64-cuda.tar.gz
sha256sum -c --ignore-missing nam-a2a1-converter-linux-x86_64-cuda.tar.gz.sha256
tar -xzf nam-a2a1-converter-linux-x86_64-cuda.tar.gz

Windows: download get-cuda-build.ps1 and run powershell -ExecutionPolicy Bypass -File get-cuda-build.ps1, or copy /b the two parts together by hand. Full detail is in the v0.4.0 notes.

Requires an NVIDIA card of compute capability 5.0+ with a current driver. Apple silicon uses its GPU automatically — nothing to download. Signing is unchanged: macOS is signed + notarized, Windows is unsigned so SmartScreen warns — More info → Run anyway.

v0.4.1 — empty GPU banner fixed, 0.7.0 toggle warns about Valeton Suite

A cosmetic bug on the GPU builds, and a clearer warning on the output-format toggle.

The empty green box on GPU builds

If you ran a CUDA build (or Apple silicon), you got a green banner at the top of the page with nothing inside it. Harmless, but it looked broken — because it was.

The banner is the "your NVIDIA card is idle, get the CUDA build" tip, so on a build that already uses your GPU it's supposed to stay hidden. It was marked hidden correctly; the stylesheet just overruled it. The browser's own rule for hidden elements is a plain display: none, and the banner's own styling set display: flex, which outranks it — so the element stayed laid out, just empty. Fixed globally rather than on that one banner, so nothing else can hit it.

Thanks to the person on reddit who reported it with the devtools output — that turned it from a guess into a one-line fix.

The A1 0.7.0 option now says what it costs you

Valeton Suite cannot import a 0.7.0 file, and it doesn't say so — it sits on "importing..." for around two minutes and then times out. That's expected: A1-only gear wants the 0.5.x format, which is why 0.5.x is the default and the one you should leave selected. But the toggle only said "newer NAM plugins", which wasn't blunt enough to stop someone spending a full training run to find out. It now names Valeton Suite directly.

Nothing changed about the conversion itself. If you already have working 0.5.x files, they're unaffected — there's no reason to re-convert anything for this release.

Also

• The 0.5.x option now names the GP-150 alongside the GP-5 and GP-50. It always worked; it just wasn't listed. Confirmed by a GP-150 owner across Draft, Standard and Best.

Downloads

Platform	File
macOS (signed + notarized)	nam-a2a1-converter-macos.dmg
Windows	nam-a2a1-converter-windows.zip
Windows + NVIDIA	nam-a2a1-converter-windows-cuda.zip.001 and .002
Linux x86_64	nam-a2a1-converter-linux-x86_64.tar.gz
Linux x86_64 + NVIDIA	nam-a2a1-converter-linux-x86_64-cuda.tar.gz.001, .002 and .003

The CUDA bundles ship as numbered parts because GitHub caps one release file at 2 GiB. Rejoin them the same way as last release:

cat nam-a2a1-converter-linux-x86_64-cuda.tar.gz.0* > nam-a2a1-converter-linux-x86_64-cuda.tar.gz
sha256sum -c --ignore-missing nam-a2a1-converter-linux-x86_64-cuda.tar.gz.sha256
tar -xzf nam-a2a1-converter-linux-x86_64-cuda.tar.gz

Windows: download get-cuda-build.ps1 and run powershell -ExecutionPolicy Bypass -File get-cuda-build.ps1, or copy /b the two parts together by hand. Full detail is in the v0.4.0 notes.

Requires an NVIDIA card of compute capability 5.0+ with a current driver. Apple silicon uses its GPU automatically — nothing to download. Signing is unchanged: macOS is signed + notarized, Windows is unsigned so SmartScreen warns — More info → Run anyway.

v0.4.0 — Linux CUDA build + GPU banner fix

Linux gets a CUDA build, and a GPU banner bug that sent Linux users to a Windows-only download is fixed.

Linux + NVIDIA — CUDA build

Linux gets the same GPU path Windows got in v0.3.0. Same app, compiled against CUDA instead of CPU-only PyTorch. A convert that takes ~40 minutes on a CPU takes a small fraction of that.

It runs on exactly the same distros as the standard Linux build. The bundled CUDA runtime needs nothing newer than glibc 2.35, so if the regular build starts on your machine, this one will too — Ubuntu 22.04+, Debian 12+, Mint 21+, Pop!_OS 22.04+, Fedora 36+, Arch, openSUSE 15.5+.

All it needs from your system is the NVIDIA proprietary driver — if nvidia-smi prints your card, you're set. The CUDA toolkit is inside the bundle; there is nothing to apt install.

The GPU banner was broken on Linux

The launch check asked "is there an NVIDIA card here?" and "can this build use it?" — but never asked what OS it was running on. So a Linux user with an NVIDIA card got a Get the CUDA build link pointing at something that only existed for Windows, which dropped them on a release page whose only Linux file was the CPU build they already had.

Fixed. The banner is platform-aware, and it now links to the repo's GPU acceleration section — which actually explains the multi-part download — instead of the bare releases page. macOS is excluded permanently: there are no CUDA PyTorch wheels for macOS at any version, so an NVIDIA card in an Intel Mac has no upgrade path and shouldn't be advertised one.

Thanks to the person who reported it on reddit.

Also in this release

• The app shows its version in the header. It didn't before, which made "which build are you on?" unanswerable.
• Corrected the CPU runtime claim. The README said a Standard convert takes "a few minutes" on CPU. That's true on a modern desktop chip and wrong on an older one — a 2012 i7-3770 took ~40 minutes at Draft. The ETA also reads optimistic at the start: it extrapolates from finished epochs, and early epochs run faster than later ones, so the first number drifts up.
• Apple silicon is unchanged — still trains on the GPU via Metal (MPS) automatically, nothing to download.

Downloads

Platform	File
macOS (signed + notarized)	nam-a2a1-converter-macos.dmg
Windows	nam-a2a1-converter-windows.zip
Windows + NVIDIA	nam-a2a1-converter-windows-cuda.zip.001 and .002 — see below
Linux x86_64	nam-a2a1-converter-linux-x86_64.tar.gz
Linux x86_64 + NVIDIA	nam-a2a1-converter-linux-x86_64-cuda.tar.gz.001, .002 and .003 — see below

Getting the CUDA build

GitHub caps a single release file at 2 GiB, so both CUDA bundles ship as numbered parts you rejoin. They're a plain byte split, so the tools to rejoin them are already on your machine.

Linux (~3.5 GiB, three parts):

cat nam-a2a1-converter-linux-x86_64-cuda.tar.gz.0* > nam-a2a1-converter-linux-x86_64-cuda.tar.gz
sha256sum -c --ignore-missing nam-a2a1-converter-linux-x86_64-cuda.tar.gz.sha256
tar -xzf nam-a2a1-converter-linux-x86_64-cuda.tar.gz
./nam-a2a1-converter/nam-a2a1-converter

The glob orders the parts correctly — they're numbered .001, .002, .003, so plain lexical sort is the right order.

Windows (~2.6 GiB, two parts) — easiest, download get-cuda-build.ps1 and run:

powershell -ExecutionPolicy Bypass -File get-cuda-build.ps1

It fetches both parts, verifies them against the published SHA256, rejoins them and unpacks the app. (-ExecutionPolicy Bypass is needed because the script is unsigned; it only ever downloads from this repo's releases.) Or by hand:

copy /b nam-a2a1-converter-windows-cuda.zip.001 + nam-a2a1-converter-windows-cuda.zip.002 nam-a2a1-converter-windows-cuda.zip

Each .sha256 lists the expected hash for the assembled archive and for every part — check against it if a convert later fails oddly, since a truncated part is the usual cause.

Requires an NVIDIA card of compute capability 5.0+ (GTX 900-series / 2014 or newer) with a current driver.

Prefer not to download several GiB? CUDA also works from source on Linux and Windows:

python3 -m venv .venv
./.venv/bin/pip install torch --index-url https://download.pytorch.org/whl/cu126
./.venv/bin/pip install -r requirements.txt
./.venv/bin/python -m nam_a2a1

Notes

• Signing is unchanged: macOS is signed + notarized and opens clean, Windows is unsigned so SmartScreen warns — More info → Run anyway.
• macOS, Windows and Linux have all now had real conversions run on them by users — including Linux Mint 22 on an i7-3770, with the output imported and running on a Valeton GP-150. The GPU builds are newer and less travelled, so if you're on CUDA and something looks wrong, please open an issue.

v0.3.0 — GPU acceleration + Windows launch fix

GPU acceleration, and a fix for a Windows crash that stopped the app launching at all.

Windows launch crash — fixed

If you double-clicked nam-a2a1-converter.exe and it flashed and disappeared, that was a real bug, not your machine.

The windowed build starts with no stdout, and the web server died while configuring its logger — before it could open a port. Launching through PowerShell with | Out-Host worked around it by handing the process a real output pipe.

This release fixes the cause. No wrapper script or .bat needed. Thanks to the person who reported it on reddit.

GPU acceleration

Training is much faster on a GPU. What you need depends on your machine:

Machine	What to do
Apple silicon (M1/M2/M3/M4)	Nothing. The macOS build already trains on the GPU via Metal (MPS), and always has. No extra download, no setting, no opt-in.
Windows + NVIDIA	Grab the CUDA build below.
Intel Mac, AMD / Intel GPUs	CPU only — no GPU path today.

You don't have to work out which row you're in. The standard build now checks on launch: if it finds an NVIDIA card it can't use, it shows a banner linking to the CUDA build. No banner means you're already as fast as this tool gets.

Downloads

Platform	File
macOS (signed + notarized)	nam-a2a1-converter-macos.dmg
Windows	nam-a2a1-converter-windows.zip
Windows + NVIDIA	nam-a2a1-converter-windows-cuda.zip.001 and .002 — see below
Linux x86_64	nam-a2a1-converter-linux-x86_64.tar.gz

Getting the CUDA build

It's ~2.6 GiB, and GitHub caps a single release file at 2 GiB, so it ships as two parts you rejoin.

Easiest — download get-cuda-build.ps1 and run:

powershell -ExecutionPolicy Bypass -File get-cuda-build.ps1

It fetches both parts, verifies them against the published SHA256, rejoins them and unpacks the app. (-ExecutionPolicy Bypass is needed because the script is unsigned; it only ever downloads from this repo's releases.)

By hand — the parts are a plain byte split, so copy /b rebuilds the zip with no extra software:

copy /b nam-a2a1-converter-windows-cuda.zip.001 + nam-a2a1-converter-windows-cuda.zip.002 nam-a2a1-converter-windows-cuda.zip

Then unzip as usual. nam-a2a1-converter-windows-cuda.zip.sha256 lists the expected hash for the assembled zip and for each part — check against it if a convert later fails oddly, since a truncated part is the usual cause.

Requires an NVIDIA card of compute capability 5.0+ (GTX 900-series / 2014 or newer) with a current driver. CUDA itself is inside the bundle; there's nothing else to install.

Notes

• Windows and macOS are both unsigned/notarized as before: macOS opens clean, Windows SmartScreen still warns — More info → Run anyway.
• macOS is tested end-to-end, and Windows has now had a real conversion run on it by a user. Linux compiles and passes automated checks in CI but is still untested on real hardware — please open an issue if something breaks.

v0.2.0

v0.2.0 — Linux x86_64

New: Linux build. Requires glibc 2.35+ (Ubuntu 22.04+, Debian 12+, Mint 21+,
Pop!_OS 22.04+, Fedora 36+, Arch, openSUSE 15.5+). Nothing to install — Tcl/Tk and
the X11 client libs are bundled, so glibc is the only external dependency.

Fixed (Linux): the browser now opens reliably. PyInstaller's bootloader was leaking
the bundle's libraries into xdg-open via LD_LIBRARY_PATH, so the browser could fail
to start against our bundled libstdc++/libfreetype while the server ran fine.

Fixed (all platforms): captures whose names begin with "." no longer write invisible
dotfiles into ~/NAM-A2A1-out/.

Linux and Windows are verified in CI (the frozen binary's full import graph) but have
not been run on real hardware — no conversion has been completed on either. macOS is
tested end to end.

v0.1.0

ci: add frozen selftest that forces the import graph

CI built green but never ran the binary, so the tkinter ModuleNotFoundError only
showed up on the user's machine. New 'selftest' subcommand imports the whole
pipeline + web stack; a CI step runs the FROZEN exe's selftest on both platforms,
failing the build on any missing bundled module before it ships.

Claude-Session: https://claude.ai/code/session_01C3JrHGeQyEJ5qNLw8cdCe8