I built AutoSampler because I kept running into the same annoying workflow problem: I had a great sound living inside a DAW track, but turning that sound into a playable sampled instrument was still too manual.
The sound might start as a synth patch, then run through a few effects, then maybe get some gain staging, tone shaping, or movement. By the time it was finished, it was no longer “just a synth preset.” It was a whole sound design chain. And if I wanted to reuse it somewhere else, especially inside Decent Sampler, I had to bounce notes one by one, trim files, organize folders, and write mapping data by hand.
That was the motivation for AutoSampler.
What AutoSampler does
AutoSampler is a VST3 effect plugin designed to sit at the end of a DAW track chain.
The workflow is simple:
MIDI clip in the DAW -> Instrument -> Effects -> AutoSampler
Inside the plugin, I define:
- lowest note
- highest note
- note interval
- velocity layers
- note length
- release tail
- MIDI channel
- sample cleanup defaults like trim threshold, fades, and normalization
Then AutoSampler exports a MIDI guide file. I import that MIDI clip onto the same instrument track, arm AutoSampler, and let the DAW play through the notes. As the track runs, AutoSampler listens to the actual post-effects audio, records each note, cleans the files up, and exports a Decent Sampler-ready instrument.
The output includes:
- WAV samples
- a .dspreset file
- a ready-to-load folder structure
- optional multiple Decent Sampler presets in one project
So the end result is not just raw notes from a synth. It is a proper sampled instrument built from the final sound of the track.
The original idea, and why I changed it
My first instinct was to make the plugin completely automatic inside one DAW insert slot. In other words, I wanted this chain:
Instrument -> Effect -> Effect -> AutoSampler
And I wanted AutoSampler, sitting at the end, to somehow trigger the instrument upstream, record the audio, and export everything.
Conceptually, that sounds perfect.
Technically, it is a trap.
The big issue is DAW routing. A normal effect plugin at the end of the chain can reliably receive the final track audio, but it usually cannot send MIDI backward to an instrument earlier in the same chain in a host-agnostic way. I explored a couple of variations, including MIDI output and even a trigger companion plugin, but that started getting messy fast. Some hosts treat those plugins differently, some will not place them where you need them, and some simply will not route things the way the product idea assumes.
That was the turning point.
Instead of trying to fight every DAW, I leaned into the DAW itself.
That is why the current AutoSampler workflow uses exported MIDI. The DAW is already very good at holding MIDI clips, routing MIDI into the instrument, and playing the full audio chain. So I stopped trying to force the plugin to be a universal MIDI brain and let the host do that part.
It ended up being a much better design.
How I built it
AutoSampler lives inside my Go-based plugin framework, not JUCE. The plugin itself is a VST3 effect with stereo input and output, and the UI is a web-based editor rendered inside the plugin.
That split gave me a nice architecture:
- Go handles audio processing, capture state, file export, and preset generation
- React handles the editor UI
- a lightweight message bridge connects the UI and processor
Over time, the project settled into a few main pieces.
1. Capture planning
The first thing AutoSampler needs to do is turn a user’s settings into a capture plan.
If the user says:
- lowest note C2
- highest note C5
- every 3 semitones
- 1 velocity layer
then the plugin builds a series of steps with:
- root note
- low/high key range
- velocity range
- output filename
- sample path for the Decent Sampler preset
That key-range spreading matters because if I sample every minor third, I still need those notes mapped across the full keyboard correctly. So AutoSampler computes midpoints between sampled notes and builds the ranges automatically.
2. MIDI guide export
Once the plan exists, AutoSampler writes a standard MIDI file to disk.
That MIDI file follows the capture plan exactly: note-on, note duration, note-off, release tail spacing, channel, and so on. The MIDI clip becomes the timing reference for the whole capture process.
This turned out to be one of the most practical decisions in the project. Instead of inventing a host-specific triggering system, I made the DAW play exactly what AutoSampler expects.
3. Real-time capture with onset detection
The capture engine listens to the stereo input and waits for actual signal before it starts recording each note.
That part became important after early testing, especially with hardware and slower patches. Starting a blind timer when the capture begins is not enough. If the patch has latency, a slow attack, or some routing delay, you end up recording silence or clipping the transient.
So I changed the session logic to require a short sustained audio onset before the plugin considers a note “started.” Once it hears real signal, it begins recording that step and keeps the configured note length plus the release tail.
That small change made the tool much more reliable.
4. Sample cleanup
Once a note is captured, AutoSampler runs a cleanup pass.
Right now that includes:
- trimming leading silence
- optional trimming of trailing silence
- optional normalization
- fade-in
- fade-out
I wanted these to be practical controls, not fancy DSP theater. The goal is simple: make exported files usable immediately.
5. Decent Sampler preset generation
The export stage builds a .dspreset file in plain XML and points it at the generated samples.
This part was fun because Decent Sampler is very approachable as a target format. I focused on writing valid sample mappings first:
- sample path
- root note
- low/high note range
- velocity range
Then I added polish by generating a small built-in Decent Sampler UI. Instead of putting every possible playback control inside AutoSampler, I let the exported instrument open in Decent Sampler with its own controls for things like:
- attack
- decay
- sustain
- release
- volume
- tuning
- tone
- resonance
That felt like the right separation of concerns. AutoSampler captures and packages the sound. Decent Sampler becomes the place where the instrument is performed and tweaked.
One of the best changes: libraries and presets
A big step forward was realizing this should not just be “export one instrument and leave.”
I added a library system so AutoSampler can manage:
- a library folder
- defaults shared across presets
- multiple presets in one project
- recording status per preset
That means I can build a small sample library project instead of just spitting files into a folder. I can also generate multiple .dspreset files that share the same sample set, which is useful for alternate versions of the same instrument.
For example, one sampled sound can ship with multiple Decent Sampler presets that differ in envelope or filter behavior without duplicating WAVs.
The UI process
The UI also changed a lot during development.
At first it was more of a functional control panel. As the workflow became clearer, I restructured it around what the user is actually doing:
- open or create a library
- configure a preset
- export MIDI
- arm capture
- let the DAW play
- export the instrument
Later, I split the UI into smaller components and cleaned up the stylesheet structure so it would stay maintainable as the plugin grew. That refactor mattered because once tools like this start working, they tend to accumulate a lot of small quality-of-life features.
What I learned
The biggest lesson from AutoSampler was that the “most automatic” idea is not always the best product design.
Trying to make one end-of-chain plugin both trigger MIDI and record audio sounded elegant, but it depended on DAW behavior that is not universal. Exporting MIDI and letting the DAW do the playback ended up being simpler, more compatible, and easier to reason about.
The second lesson was to treat export quality as part of the core product, not a later polish pass. Trimming, fades, normalization, good naming, and preset generation are not extras. They are the difference between “it technically works” and “I can actually use this.”
Where AutoSampler is now
At this point, AutoSampler can:
- live at the end of a DAW chain
- export a MIDI guide
- record one WAV per sampled note
- clean up the captured audio
- write Decent Sampler preset files
- organize captures into library/preset projects
- generate multiple Decent Sampler presets from one sample set
And most importantly, it solves the actual workflow I built it for: turning a finished DAW sound into a reusable sampled instrument without doing everything by hand.
That was the goal from the start.
If I keep pushing it further, the next obvious steps are things like richer velocity workflows, round robins, more preset controls, and maybe smarter loop handling. But even in its current form, AutoSampler already feels like a real tool instead of just a plugin experiment.
If you want, I can also turn this into:
- a more personal founder-style blog post
- a more technical devlog version
- or a polished launch post for a website or X/LinkedIn thread