So DMC60 doesn't try to be clean. Everything runs through a 26.04 kHz internal rate, samples are quantized to 12 bits, and there's an SSM2044-style filter on the voice. The aliasing you get from that low rate is deliberate. In the README I put it this way: those are features, not bugs.

Why 12 bits and 26.04 kHz

Modern plugins give you 32-bit float at whatever rate your session runs at, which is great for transparency. But play a kick through a 12-bit converter at 26 kHz and you get something clean audio doesn't give you: a crunchy top end, folded-back harmonics, and a low end that feels denser than it measures.

The core of the effect is simple. Here's a sketch of the quantization step. The clamp matters: a signed 12-bit converter tops out at +2047, so a full-scale peak clips slightly instead of landing on a level the hardware never had.

// Simplified: snap a float sample in [-1, 1] to a signed 12-bit grid
inline float quantize12 (float x)
{
    constexpr float scale = 2048.0f; // 2^12 levels, split across both polarities
    const float code = std::clamp (std::round (x * scale), -2048.0f, 2047.0f);
    return code / scale;
}

The harder part is everything around it. The sample-rate conversion has to alias the way the old hardware did instead of filtering it away, and the filter has to respond the way the analog chip did. That's where most of my time went.

One codebase, four platforms

DMC60 builds from a single CMake project into:

JUCE does most of the cross-platform work, but the iPad version took real design effort. A drum machine is something you want to touch, so the iPad app got its own layout, not a shrunk-down desktop window:

• Native point sizes, with 44-point minimum button targets and 48×44-point fader handles
• Pad controls and the session inspector start closed, so the 4×4 pad grid gets the screen
• Background audio, and live sampling from the microphone
• Projects and programs live in the app's Documents folder, so they show up in the Files app

I leaned on Apple's button guidance along with Fitts's Law and Hick's Law to size and simplify the controls. Bigger targets that are closer to your thumb, and fewer choices on screen at once.

I also added a desktop preview mode. Launching the standalone with DMC60_IPAD_LAYOUT=1 renders the iPad layout on the Mac, and a touch_layout_smoke test renders the real editor at iPad size to check pad and toolbar dimensions without touching audio hardware.

A pre-commit hook that builds everything

One habit that paid off: the repo's pre-commit hook runs a full Release build before every commit. It's slower than a lint check, but a C++ plugin that doesn't build is worthless, and this way the main branch always does.

npm run prepare        # point git at .githooks
./scripts/build-app.sh # the same build the hook runs

What's next

DMC60 has its own program format (.dmcpgm), and building kits for it by hand got old fast. That's what led to my next tool, DorDSP Kit Pro, which turns folders of samples into ready-to-play kits for DMC60, the MPC, and Ableton.

Why JUCE?

If you're getting into audio plugin development, JUCE is basically the industry standard. It handles the cross-platform plumbing (VST3, AU, and AAX with Avid's SDK) so you can focus on the actual DSP. The learning curve is real, but the documentation is solid and there's a great community.

void WarmTubeProcessor::processBlock(juce::AudioBuffer<float>& buffer, juce::MidiBuffer&)
{
    juce::ScopedNoDenormals noDenormals;

    for (int channel = 0; channel < buffer.getNumChannels(); ++channel)
    {
        auto* channelData = buffer.getWritePointer(channel);

        for (int sample = 0; sample < buffer.getNumSamples(); ++sample)
        {
            // Soft clipping with tube-style saturation
            float x = channelData[sample] * driveAmount;
            channelData[sample] = std::tanh(x) * outputGain;
        }
    }
}

The basic idea behind tube saturation is soft clipping. When you push a tube amp, it doesn't cut the signal off harshly. It rounds it off smoothly, adding harmonics that our ears hear as "warmth."

There's a catch, though. tanh() is symmetric, so it only adds odd harmonics, which lean toward grit more than warmth. Real tubes are asymmetric, and that asymmetry is where the even harmonics come from. Adding a small DC bias before the curve (and removing it afterward) gets you a lot closer.

The DSP rabbit hole

What started as a simple tanh() waveshaper quickly became an obsession with modeling how vacuum tubes actually behave. There's a reason good saturation plugins cost what they do: the math gets complicated fast.

Key things I learned:

1. Oversampling is essential. Any nonlinearity creates new harmonics, and the ones above Nyquist fold back down as aliasing. JUCE's dsp::Oversampling class makes this easy.
2. Smooth your parameters. Jumping straight to a new drive value mid-buffer causes zipper noise. SmoothedValue fixes it.
3. Filters matter. Pre- and post-filtering shape the character dramatically.
4. UI is half the battle. A good-looking plugin makes you want to use it.

What's next

I'm currently working on a proper EQ section and a bias control, so you can dial in how asymmetric (and how "warm") the curve gets. The goal is to release it as a free plugin once it's polished enough.

If you're thinking about building your own plugins, I'd say go for it. The combination of music and code is incredibly satisfying, and there's nothing quite like hearing your own DSP in a mix.

Start with the room

Before you spend money on gear, think about your space. I started out in a spare bedroom in my Bay Area apartment, which came with all the acoustic problems you'd expect: parallel walls, hardwood floors, and neighbors who don't love 808s at midnight.

The fixes don't have to be expensive:

• Bass traps in the corners. This made the biggest difference. Small rooms pile up low end in the corners, and that's what makes mixes sound boomy in one room and thin everywhere else.
• Absorption panels at the first reflection points. Have a friend slide a mirror along the side walls while you sit in the mix position. Anywhere you can see a speaker in the mirror gets a panel. DIY rockwool panels work great.
• A thick rug. Seriously, it helps more than you'd think.
• Speaker placement. Put your monitors and your head in an equilateral triangle, and keep the monitors off the wall behind them. It's free and it matters.

The gear that matters

Here's my current signal chain for tracking and mixing:

Guitar/Keys → Apollo Twin X → Yamaha HS8s
                    ↓
            MacBook Pro M1 Max
                    ↓
              Ableton Live

The Apollo Twin was my biggest investment, but the built-in UAD processing and near-zero latency monitoring made it worth it. I can track through an LA-2A emulation without any delay I can hear.

Plugins over hardware

Hot take: for most home producers, plugins are a better investment than hardware. My FabFilter bundle and Soundtoys collection get used on every session. A clean, flexible hardware compressor in the same league as Pro-C 2 costs many times more, and you only get one instance of it.

The workflow advantage

The real benefit of a home setup is iteration speed. I can wake up with an idea, be tracking within 5 minutes, and have a rough mix by lunch. No booking studio time, no commute, no pressure.

My French bulldogs make excellent A&R. If they fall asleep during playback, I know the track needs more energy.

Keep it simple

The best studio is the one that gets out of your way. I've seen people with $50k setups who never finish anything because they're too busy tweaking gear. Start small, learn your tools deeply, and upgrade only when something is genuinely holding you back. My setup has grown a lot since I wrote this (the current list is on my uses page), but every upgrade came from hitting a real limit, not from wanting new gear.

DorDSP Kit Pro fixes that. Point it at a folder of drums and it:

1. Scans the library and classifies every hit by name: kick, snare, hats, percussion, and so on
2. Lays them out on a 16-pad bank
3. Writes a self-contained kit folder with the program and its samples, ready to copy onto the hardware

It writes kits for DMC60 (.dmcpgm), any Akai MPC (.xpm), MPC 3 tracks (.xtd), Ableton Live Drum Racks (.adg), and Ableton Move and Note presets.

One Rust core, two front ends

The most important decision was keeping all the logic in Rust crates that know nothing about the UI:

crates/mpc-core/        scanning, classification, layouts, generation
crates/mpc-xpm/         .xpm parser + template-preserving writer
crates/mpc-xtd/         MPC 3 track writer with MPCe pad expression
crates/ableton-adg/     Ableton Drum Rack writer
crates/ableton-bundle/  Move/Note preset writer
crates/mpc-cli/         the dordsp-kit-pro binary
apps/desktop/           Tauri 2 + React

The desktop app is the main way in: drag a folder in, review the classification, preview the 4×4 pad grid, then generate. The CLI calls the exact same APIs, so it's great for batch jobs:

# Twenty kits from one library, with minimal sample reuse across kits
dordsp-kit-pro ./samples --kits 20 --output ./kits --name "BoomBap"

# One kit per subfolder, named after the folder
dordsp-kit-pro ./Pack --per-folder --output ./kits

# Same variation every time, or a true shuffle
dordsp-kit-pro ./samples --seed boomspot
dordsp-kit-pro ./samples --shuffle

Tauri gives me a small native app without shipping a whole browser, and Rust gives me fast, safe file and audio handling. None of the core crates depend on Tauri, so the engine stays testable on its own.

MPC 3 and pad expression

MPC 3 changed things: its factory kits are tracks (.xtd), not programs, and only tracks carry MPCe pad expression, meaning what a pad does depending on where you hit it. Kit Pro can write those with an expression preset applied to every pad:

For zones, blend, and spread, the allocator stacks samples from the same category onto each pad: four kicks on pad 1, four hats on pad 3, and so on. The generated files follow the same structure as Akai's own factory tracks, but they still need testing on real MPC 3 hardware before I'd call them compatible.

Cleaning up samples as they go in

Two optional passes fix the most common problems with downloaded packs. Neither one touches your library, because processed samples are written as fresh WAV files inside the kit.

• Trim leading silence (--trim-start) cuts everything before the first sample above -60 dBFS, keeping a 2 ms pre-roll so the transient never clicks. Pads trigger on the hit instead of a few milliseconds of air, which is what makes sloppy chops feel late or flam against each other.
• Normalize (--normalize peak or --normalize loudness). peak puts each sample's loudest point at -0.3 dBFS. loudness matches the RMS of the loudest 50 ms of each sample to -12 dBFS, so a kick and a snare come out at the same perceived level instead of the same peak.

When you audition a pad in the app, you hear the processed audio, so what you hear is exactly what goes into the kit.

Why this matters to me

This tool came out of building DMC60. I needed kits to test the drum machine, and making them by hand was killing my momentum. Now building a kit takes seconds, and I get back to the part I actually care about: making beats.

The tipping point

The final straw was building a website for a local vegan restaurant here in the Bay Area. They needed good SEO (obviously), fast load times on mobile, and the ability to update their menu themselves. My usual SPA approach wasn't cutting it.

// The old way - client-side data fetching
useEffect(() => {
  fetch('/api/menu')
    .then(res => res.json())
    .then(setMenu)
}, [])

// The Next.js way - server components
async function MenuPage() {
  const menu = await getMenu()
  return <MenuList items={menu} />
}

That second approach is just... better. The data is already in the HTML when the page loads. No loading spinner, no content popping in after the fact, and search engines see the full menu on the first request.

What I love about the App Router

Next.js 14's App Router finally clicked for me after a few projects:

1. Server Components by default - Less JavaScript shipped to the client
2. Nested layouts - No more prop drilling for navigation state
3. Route Handlers - API endpoints live next to the pages, in one codebase
4. Image optimization - The next/image component is magic

The learning curve is real

I won't pretend the transition was seamless. Server vs. client components took some getting used to, and I definitely broke things by trying to use hooks in the wrong places.

// ServerComponent.tsx - this will break, hooks don't work in server components
async function ServerComponent() {
  const [count, setCount] = useState(0) // Error!
  return <div>{count}</div>
}

The fix is to move interactive pieces into their own file and mark it as a client component. The 'use client' directive has to be the very first line of that file:

// Counter.tsx
'use client'

import { useState } from 'react'

export function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>
}

Worth the switch?

For me, yes. My sites are faster, my code is cleaner, and I spend less time configuring build tools. For any project that needs good SEO or has dynamic content, Next.js is now my default choice.

The vegan restaurant site? Their search rankings improved noticeably within a month of launch. I can't credit that to server rendering alone, since the old site had other problems too, but serving real HTML on the first request certainly didn't hurt.