Writing Audio Plugins with JUCE — UltraGlitch BitFucker

UltraGlitch BitFucker is a public JUCE glitch-plugin project now sitting in a real beta state: multi-effect destruction, cross-platform builds, crash guards, and proper build packaging.

Launch Link GitHub Repo https://github.com/illdynamics/ultraglitch-bitfucker
UltraGlitch BitFucker artwork

UltraGlitch BitFucker started from the simple urge to wreck audio on purpose, but the current repo is past pure idea stage already. The attached codebase shows a real JUCE/CMake plugin project with named DSP modules, platform-aware build docs, packaging scripts, CI, and recent stability work around ugly host buffer behaviour.

Right now the repo identifies itself as v0.4.0-beta. That is the honest state: public beta, real code, real build outputs, and the kind of crash-hardening work you only add after hosts start throwing proper goblin energy at your DSP.

What It Does

The plugin is built as a creative glitch and destruction box rather than a polite studio tool. These are the main sonic troublemakers at the centre of the current build:

BitCrusher — reduce bit depth and sample rate for that classic lo-fi crunch

BufferStutter — capture and repeat audio buffers at variable rates

PitchDrift — slowly detune the signal, creating seasick wobble

ReverseSlice — chop audio into slices and play them backwards

WeirdFlanger — a flanger that doesn’t follow the rules

The repo README and docs also show Slice Rearrange in the current feature set, which means the project has already grown beyond the smaller five-effect snapshot that older summaries were stuck on.

And then there is CHAOS MODE: not a cute preset name, but the deliberate all-gas-no-brakes layer where parameters get pushed into unstable motion and the plugin becomes a musical vandal instead of a polite processor.

The DSP Shape

The project is structured around dedicated DSP modules rather than one giant spaghetti blob. That matters, because glitch effects get messy fast once buffers, playback position tricks, wet/dry handling, and timing weirdness all start colliding.

The current repo also shows recent crash-guard work around unexpected host block sizes. That is proper real-world plugin engineering stuff: hosts do not always behave like your neat little prepare-time assumptions say they should.

void UltraGlitchProcessor::processBlock(
    juce::AudioBuffer<float>& buffer,
    juce::MidiBuffer& midiMessages)
{
    const int numSamples = buffer.getNumSamples();
    if (numSamples == 0 || numSamples > MAX_BUFFER_SIZE)
        return;

    if (bitCrusherEnabled)
        bitCrusher.process(buffer);
    if (stutterEnabled)
        bufferStutter.process(buffer);
    if (pitchDriftEnabled)
        pitchDrift.process(buffer);

    if (chaosMode)
        chaosController.scramble(allEffects, numSamples);
}

JUCE 8 Friction Was Real

The repo history and build notes make it pretty clear this was not just “clone repo, vibe, done.” JUCE 8 changes and cross-platform build quirks forced some actual engineering cleanup.

PtyCommandLine usage changed for process handling

AudioProcessorEditor lifecycle differences had to be handled cleanly

Universal binary builds (arm64 + x86_64) needed careful CMake configuration

That last one especially matters on macOS, because the project now targets a single universal build instead of forcing duplicate plugin installs for Apple Silicon versus Intel / Rosetta hosts.

set(CMAKE_OSX_ARCHITECTURES "arm64;x86_64")
set(CMAKE_OSX_DEPLOYMENT_TARGET "11.0")

Shipping State

The current repo is set up for VST3 and Standalone builds, with AU on macOS. The build docs and scripts also show real packaging work for Windows x86_64 and universal macOS binaries, which is exactly the kind of unglamorous labour that turns a cool DSP experiment into something other people can actually test.

That means the project page should talk about it like what it is now: a public beta plugin project with real build targets and real fixes, not just a flexy concept banner.

Lessons from the Chaos Yard

These still feel like the real takeaways from the project, and yeah, they deserve to pop in proper Rikketik colours:

Buffer sizes vary wildly — always guard against edge cases (0 samples, huge buffers)

DSP is math, but UX is art — the parameter ranges matter more than the algorithm

CHAOS MODE is a feature — sometimes the best sounds come from controlled randomness

Test with real audio — unit tests catch crashes, but your ears catch bad DSP

That is the bit I rate the most: destructive plugin design is only fun if it stays musically nasty without also becoming technically clownshoes.