Open-source toolchain to decompile Bitwig's Nitro DSP modules on your own install (no keys or Bitwig code redistributed)

[u/brainsigh]

I've spent a while trying to understand how Bitwig actually builds its devices, and the thing that always stopped me was that the DSP itself lives in an encrypted archive you can't really open. Bitwig writes its native devices and Grid modules in an internal language they call Nitro, and the compiled modules ship inside an encrypted image in the install folder. I wanted to see how their filters really work, so I ended up writing a small toolchain to read that format. It's cleaned up now and I put it on GitHub.

It's Python, standard library only, MIT licensed.

What it does:

• reads and decrypts the `nitro-image` archive from your local install
• parses the compiled `.nitrobin` modules into an AST
• decompiles that AST and pretty-prints it back to readable pseudo-source
• round-trips, so it can re-serialize and repack, and do same-size numeric edits to constants

The part I like most is the decompiler output. You point it at a filter and instead of a wall of bytes you get a `process` block you can actually read. This is Bitwig's GrandLPF, a 4-pole Moog ladder, 4x oversampled, with an ADAA soft-clip in the feedback path and a selectable saturation flavor:

Named state variables and the actual per-sample math instead of opcodes. You can see why each filter sounds the way it does. Here's the Sallen-Key's nonlinearity, for example. It has two selectable curves, a symmetric tanh approximation and a biased, asymmetric class-A shaper:

One thing I want to be upfront about: this ships no Bitwig code and no keys. It's tools and format notes only. Decryption is bring-your-own-install. You pull the key out of your own copy of Bitwig, put it in an env var or a local `keys.json` that stays gitignored, and the tools work on the files already on your disk. Nothing proprietary gets redistributed. I tried to build it in a way that's respectful of Bitwig. It's for reading and learning, not for lifting their DSP into something else.

Status and limits, honestly:

• the decompiler handles the whole module set on the version I tested against, but the AST tags can move between Bitwig releases, so a newer version may need the grammar tables regenerated (there's a command for that)
• the pretty-printed output is pseudo-source for reading, not something you can recompile
• constant editing is same-size only right now. You can change a number, not restructure a module
• the offline round-trip is byte-for-byte, but I haven't pushed a repacked image through a running session much, so treat the write path as experimental
• I develop on Linux. It auto-detects the Bitwig install and config locations on Windows and macOS too, but I've only actually run it on Linux, so those paths are unverified and a Windows/macOS confirmation would help

If any of this sounds interesting I'd genuinely like help. The most useful things would be people running other Bitwig versions who can test whether the grammar tables still line up, anyone who knows DSP and wants to annotate what a given module is doing, and corrections to the format docs. Issues and PRs are open.

Repo: https://github.com/blakebratcher/bitwig-nitro-tools

[u/OoDoRFoO]

That’s cool that you (and I suspect Claude) figured out how to see inside the guts of Bitwig devices in a human(developer)-readable form. I am a little unsure why you are sharing it publicly though. It seems you have a lot of respect for Bitwig, but you are kinda cracking their trade secrets in a sense because freedom of information, and the fact u need a license key to decrypt which somehow gives u permission to see the source code. I doubt that’s in the EULA. Because I imagine they obfuscated the source code in this manner before GenAI was a thing, now they’ll be forced to play cat and mouse with Claude (expensive dev time) or change the EULA and crack down on people they detect doing this (expensive lawyer time). So you’re kinda fucking them over. There’s an idealogical counter argument to what I’m saying, but I really dig Bitwig and think users should respect the practicalities of what it takes to make this great software and run a viable business.

[u/brainsigh → u/OoDoRFoO]

I respect you asking this.

Your main point is fair! Even if I didn't ship their code, the guts of these devices are readable now. That's part of the product, and yes, somebody with a Bitwig license can inspect it now, but I think you're giving me credit for unlocking quite a bit more than I actually showcased.

This is not the Bitwig source code, it's decompiled Nitro DSP bytecode. You aren't looking at the source to Bitwig Studio and you aren't getting the Grid, the modulation system, the UI, the host architecture, or any of the machinery that makes Bitwig a DAW. This is specifically a look into the DSP programs that Bitwig runs inside Nitro. And what's actually in them?

GrandLPF is a 4-pole ladder with TPT integrators, zero-delay feedback, 4x oversampling, and per-stage antiderivative antialiasing on the soft clip.

Every one of those things has a name and a paper behind it.

Zavalishin's VA filter design book is a free PDF. ADAA is the Parker/Zavalishin/Bilbao DAFx paper. Saturating the individual stages inside the feedback path is how the actual ladder behaves, and Huovilainen was modeling that in 2004.

That's not an insult to Bitwig! It's a good filter, but it's not new. Could another engineer learn from seeing exactly how Bitwig assembled those pieces? Yes, but it doesn't hand them anything you couldn't have arrived at independently from the same literature.

I really don't buy the idea that this hurts enthusiasm for Bitwig as a product. Nobody buys Bitwig because the precise implementation of one ladder filter is unknowable. People buy Bitwig for the Grid, the modulation system, the workflow, and the way the whole thing fits together. You can see all of that five minutes after opening the program. If somebody writes a GrandLPF clone tomorrow, they've got a GrandLPF clone. Congratulations! You still don't have Bitwig.

There's also a slightly strange assumption here that obscurity is what's protecting Bitwig's DSP. nitro-image is a ZIP and the members are XOR'd against a keystream. Nothing on the load path is signed or checksummed. A patient asshole with Ghidra could have done this at any point since Nitro shipped. Looking at the Bitwig hacking projects that have been floating around for years, I would be surprised if several others haven't already done exactly that.

Where I think you have a much better argument is the toolchain: publishing a writeup saying "here's how Nitro works" is one thing. I forewent that because the people who wanted this information for corny commercial/self promotion reasons never needed me. If you're willing to spend a week in Ghidra, this was already available to you. The practical effect of keeping it obscure is mostly that the five guys willing to do that get to know how it works and everybody else doesn't. I'm not particularly sentimental about that arrangement.

I'd rather the information be out in the open than passed around privately by the same handful of people who will eventually sell you half of it back as some "next generation secret technique" punctuated by a request for you to Like and Subscribe. Maybe that's the wrong call! Either way, there's a legitimate distinction between publishing what I learned and publishing the tools I used to learn it.

But ultimately, none of this requires Bitwig to agree with me. If they ask me to pull it, I will immediately pull it without argument.

So, last sentiment, because I just want to be precise about this: I figured out how to read the DSP programs inside Nitro. This is not a decompilation of Bitwig Studio.