Type a Sound. Get a Free Synth Preset.

Open-sourcing the early DeepSynth: an LLM-powered preset generator for Surge XT, Vital, and Dexed

Type a sound. Get a preset file that actually opens in a synth.

That was the promise behind the earliest version of DeepSynth: turning a phrase like “a dark, hypnotic warehouse techno bass” into named parameters and a file a real instrument can load.

I did not start out wanting to build an AI music tool.

In 2013, while backpacking through twelve European countries, I kept ending up in clubs in the cities I visited. That was where I properly encountered EDM. I also went to Ibiza alone, visited Pacha and Amnesia, and saw artists I loved at the time, including Dash Berlin, Fedde Le Grand, and Hardwell. I left with a simple conviction: one day, I would make EDM myself.

For a long time, that ambition stayed on hold. Work and parenting came first. When small stretches of personal time finally began to appear, I decided to stop postponing it.

My original goal was not to make an AI product. I wanted to become a EDM producer. I wanted to combine the energy of trance and techno, the texture of ambient and synthwave, and the feeling of French dance music into something personal. Eventually, I wanted to make live sets at home and let other people hear the music.

So I built a place to start: Ableton Live and Arturia V Collection X. To turn the sounds in my head into actual audio, I had to learn waveforms, filters, envelopes, modulation, time, and space.

The problem was not a lack of material. It was an excess of it. EDMProd, an endless number of YouTube production channels, Udemy courses, genre-specific tutorials, presets, plug-ins, and sample packs all offered a different path. Logic and Ableton came with their own instruments; then there were Arturia, Serum, Vital, Dexed, and many more VSTs.

I’m building instruments for new kinds of electronic music. Subscribe for notes from the process: AI, modular synths, open-source tools, and occasional live sessions.

At some point, I realized that I was becoming better at learning tools than at making music. I watched lessons, opened another synth, swapped presets, and looked up what each knob meant. Yet I had not finished a proper track.

I tried to narrow the scope. EDMProd and Udemy helped with the broad structure of electronic music: bass and leads, buildups and drops, arrangement and movement. Instead of forcing myself to finish a song, I broke the work down: a pad one day, a kick-and-bass groove the next, then an eight-bar arpeggio. I chose sounds I liked and reverse-engineered what the oscillator, filter, envelope, LFO, and effects were doing.

Modular synthesis became a concrete interest through Chris Meyer’s Learning Modular Synthesis. It did more than explain familiar concepts such as oscillators, filters, and envelopes. It showed how control voltage and gates move between modules and change a sound. A synthesizer stopped looking like a black box full of mysterious knobs and started looking like a system of signals and control.

That perspective led me to buy a Moog Mother-32 and patch by hand. I experimented with analog basses, drones, sequences, and filter movement. For more complex generative sequences and evolving textures, I used VCV Rack as a virtual patching environment. The goal was not to make entire songs in modular. My DAW would hold the structure; synths and modular patches would add texture and motion.

VCV Rack was where modular signal flow became visible: oscillators, filters, modulation, and cables could be inspected as a patch rather than inferred from a preset name.

Even after narrowing the scope, making one sound still meant choosing a waveform, setting a filter cutoff, shaping an ADSR envelope, connecting an LFO, and configuring a modulation matrix. The amount of knowledge seemed bottomless.

That was when I began asking a different question:

What if I could describe the sound I wanted, and an AI could operate the synthesizer for me?

DeepSynth began with that question. The name is deliberately literal: Deep Learning plus Synthesizer.

The early DeepSynth prototype also took the form of a ChatGPT-like Synth Studio. Rather than presenting a long bank of controls first, it let a user choose a target synthesizer, describe a sound in natural language, and continue the conversation. A request could return an explanation, named parameter JSON, or a downloadable preset file; the interface kept the conversation history alongside the selected synth. That design was important even before the file writer was dependable: it made sound design feel like an iterative conversation rather than a form with dozens of unfamiliar knobs.

The original DeepSynth web prototype: select Surge XT or Dexed, describe the intended sound, and let the system plan the patch before generation. This is a real debug capture preserved with the early web project.

I’m building instruments for new kinds of electronic music. Subscribe for notes from the process: AI, modular synths, open-source tools, and occasional live sessions.

Could an AI’s sound-design recipe become actions?

The immediate inspiration came from asking ChatGPT how to make reference sounds. If I described a wide, moving progressive-house lead, it could suggest a practical recipe: saw-like oscillators, multiple unison voices and detuning, filter and envelope settings, a slow LFO, delay, and reverb.

It did not create the sound. But it raised a more useful question: could the recipe be converted into the actual movements of a synth’s controls?

For the first experiment, I chose Surge XT. It was free and open source, which meant I could inspect its preset structure and parameters. It also offered a way to load presets and render audio from code, so an AI-generated result could be tested repeatedly against a real synthesizer. It was not merely a free substitute for a commercial plug-in; it was a practical test bench.

An early Surge XT experiment: the same prompt-to-parameter idea was tested alongside the synthesizer rather than as a detached text demo.

I first built a tiny Max-for-Live and JavaScript experiment: a slider value was sent through the Live API to one Ableton Analog parameter.

In a separate path, I wrote a small adapter that emitted OSC addresses and values for Surge XT through a Max outlet. The intent was to turn an AI suggestion such as “increase the detune, lower the filter, and add movement” into a list of addresses and values that an OSC path could send to the synth.

function osc1_detune(value) {
  var address = "/SurgeXT/oscillator/1/detune";
  var oscMessage = address + " " + value;
  post("Sending OSC message:", oscMessage, "\n");
  outlet(0, oscMessage);
}

function sendParam(address, value) {
  outlet(0, address + " " + value);
}

This file does not transmit OSC packets by itself. It emits the address-and-value string; the Max patch connected after the outlet would perform the actual transmission. It was not yet a complete AI-to-synth product. It did establish the central premise: an AI’s sound-design language could become programmatic control of a synthesizer.

The first AI: LSM and an anonymous latent space

In July 2025, I built the first LSM: the Large Synthesis Model.

The initial implementation was a VAE (Variational Autoencoder) experiment. It tried to bring text descriptions, audio characteristics, and synth parameters together in a latent space, then decode that vector back into synth parameters.

I tried several latent-space sizes: 64 dimensions in the base VAE, 128 in an enhanced version, and 256 or 512 in larger experiments. Changing that size did not solve the central problem. A larger vector could hold more information, but it did not make that information easier to inspect, edit, or validate.

The real problem was not the number of dimensions. It was that the numbers were anonymous.

The approach looked promising from the outside. It appeared to learn a path from natural language to sound. In practice, I could not explain what the first value in the vector controlled. Did changing it affect a filter, an envelope, or nothing useful at all? Small changes could also create a preset that a VST would not open, or would load without making any sound.

The model could produce an output, but I could not explain why it failed.

In music software, plausible numbers matter less than a structure people can understand and repair.

Replacing anonymous vectors with named parameters

So I changed the architecture. Instead of asking a model for a bundle of unnamed numbers, I defined a JSON Schema for each synthesizer and asked the model to fill named parameters directly.

{
  "oscillator_1_type": "saw",
  "filter_cutoff": 45.2,
  "envelope_attack": 0.8,
  "chorus_enable": true
}

Now a person could read the result. If filter_cutoff was too high, lower it. If envelope_attack was too fast, lengthen it.

With structured output from Claude and Gemini, a phrase such as “resonant and squelchy” could be translated into named filter-resonance and envelope values. The important improvement was not simply that the model became smarter. The system constrained where the model could make mistakes.

The fake FXP file

Getting valid JSON was only half the job. A preset is the file that saves a synthesizer’s settings. Surge XT uses an .fxp format.

At first, I wrote binary data in Python and gave it an .fxp extension. A file existed, so I thought it worked.

Surge XT would not open it.

That failure was obvious in retrospect. I had not implemented Surge XT’s file format. I had put JSON inside a binary chunk and changed the extension.

So I (Claude Code) read the Surge XT source code: the FXP header, plug-in ID, sub3 chunk, XML structure, and raw parameter encoding. A cutoff was not just a number between zero and one. Envelope time was not necessarily represented internally as seconds.

I eventually built a Rust preset writer. It preserved the full parameter layout of a known-good base patch and safely overrode only the values chosen by the AI.

At that point, I was also using Claude Code as an implementation partner: tracing the Surge XT source, comparing the FXP container against known-good patches, writing focused Rust tests, and iterating on the writer after each load failure. It did not replace the need to understand the format. It made the feedback loop faster: inspect the format, change one assumption, generate a file, and ask the real synth whether the assumption was wrong.

Only then did the generated results begin to open in the real synth.

The validator mattered more than the AI

Opening a file was not the finish line. A mismatched patch version could fail to load. Incorrectly encoded values could sound wrong. Extreme values could clip.

I built an automated validation loop with surge-xt-cli and headless tools that could load a preset and render audio without opening a graphical interface.

AI generation
-> parameter-schema validation
-> preset-file generation
-> load in the real synth
-> render audio
-> test for silence, clipping, and file-format errors
-> keep only passing results

This led to the most important design principle in the project:

An AI can make musical suggestions, but it should not decide whether its own output is valid.

Code should validate parameter ranges and file formats. Human ears should decide whether the sound is good.

One small, concrete tool

This is the small tool I want to document:

A program that takes one line of natural language and creates a VST preset file that opens in a real synthesizer.

The early goal of DeepSynth was not a grand AI composer. It was to describe a sound, turn that description into synth parameters, and export a real preset file.

More time went into formats, value ranges, compatibility, load tests, and tracing failures than into the model itself. The important outcome was not simply that “AI made a preset.” It was the full pipeline that turns AI output into something music software can safely read.

Why I am open-sourcing it now

The project has since moved in a broader direction. But generating and validating a single VST preset remains a useful problem in its own right.

There is no reason to hide or discard this early preset generator. It solves one problem clearly, has a relatively small architecture, and is easy for others to build and experiment with. Its failures are part of the value: the limits of anonymous latent spaces, the shift to structured output, fake FXP files, Surge XT format analysis, raw parameter encoding, and headless validation are all preserved in the code and tests.

That is why I am releasing it as open source. It can be a starting point for someone who wants to control a synth with natural language, or a reference for someone studying VST preset formats.

What I am releasing

The public release is the focused, hardened descendant of those early DeepSynth experiments: DeepSynth Presets, a small Rust tool that turns a text description into a real file for Surge XT, Dexed / DX7, or Vital. It is deliberately narrower than the early web vision. Its job is to generate named parameters, write a valid preset, and make the result inspectable and loadable.

The released desktop app shows the prompt, target synth, provider, generated file metadata, and named parameters in one place. This is the tool being open-sourced, not a screenshot of the early 2025 web prototype.

How to try the open-source preset generator

The project is available as an open-source Rust application. You can use it in three ways:

• In the browser: open the live WASM demo, describe a sound, choose Surge XT, Dexed / DX7, or Vital, select a small local matching model, then generate and download a preset. The browser build runs client-side; bring your own Claude or Gemini API key (coming soon: ChatGPT, OpenRouter, LMStudio, Ollama).

• From the CLI: run deepsynth-preset with a prompt and a target synth, then write a .fxp, .syx, or .vital file directly to disk.

• In the native desktop app: launch deepsynth-preset-app, the egui application, to enter a prompt, choose a provider and synth, review the mapped parameters, and save the generated preset through a file dialog.

The browser app can also run a model on the device (browser). MiniLM-L6-v2 is the fast keyword-matching default; bge-small-en-v1.5 improves English matching; and multilingual-e5-small accepts multilingual prompts. SmolLM2 is a smaller instruction model with a WebGPU fallback, while Gemma-3-1B-it is the larger on-device option for direct generation.

The browser demo distinguishes fast local matching from direct on-device generation. Model choice is visible and deliberate rather than hidden behind a single “AI” button.

For the fastest way to see the idea in action, test it in your browser. The landing page also links to the source and explains the available formats: DeepSynth Presets project page.

The CLI turns one prompt into a real preset file. In this example, Gemini generates a 64-parameter Surge XT patch and writes warehouse_bass.fxp, ready to load in the synthesizer.

# CLI examples
deepsynth-preset "warm analog pad" --synth surge -o warm_pad.fxp
deepsynth-preset "bright FM bell" --synth dexed -o bell.syx
deepsynth-preset "gritty reese bass" --synth vital -o reese.vital

An interactive CLI run writes its visual banner and result panel to stderr, leaving stdout clean for scripts. The result records the generated file, its byte size, the mapped parameter count, and the provider/model that created it. The same command line supports both providers, a per-run model override, and deterministic offline paths:

# Gemini generation and a per-run model override
deepsynth-preset "warm pad" --synth surge --provider gemini -o pad.fxp
deepsynth-preset "ethereal pad" --synth vital --provider gemini \
  --model gemini-2.5-flash -o pad.vital

# No API: map normalized JSON parameters, write defaults, or inspect the schema
deepsynth-preset --params-json params.json --synth surge -o out.fxp
deepsynth-preset --defaults --synth vital -o default.vital
deepsynth-preset --schema --synth surge

The CLI can produce a provider-backed prompt result, but it can also write presets without an API call from normalized parameters or safe defaults. The implementation keeps generation, parameter mapping, and file writing separately inspectable.

What is included

• Claude and Gemini providers

• Synth-specific named-parameter schemas

• Surge XT FXP writer

• Dexed/DX7 SysEx writer

• Vital preset writer

• Parameter mapping and value scaling

• CLI and native egui desktop application

• File-format parity tests

• Surge XT headless load test

You use your own API key, and generated files stay on your own computer. This is not a service that uploads presets or collects music data on a central server. It is a small open-source tool that you can download, run, inspect, and change.

I’m building instruments for new kinds of electronic music. Subscribe for notes from the process: AI, modular synths, open-source tools, and occasional live sessions.

The early version of DeepSynth was not a complete answer. It was a record of learning what mattered.

• Named parameters beat anonymous latent spaces.

• Deterministic validation matters more than unconstrained model freedom.

• A file that opens in a real synth matters more than plausible JSON.

• A system that explains its failures matters more than one that merely generates an output.

I did not want to build an enormous music AI. I wanted to build a small bridge between a phrase such as “a warm pad” or “a rough techno bass” and an actual sound.

This is the story of building that bridge. The code is now open for anyone to continue the experiment.

Try it now: DeepSynth Presets browser demo

Open-source repository: DeepSynth Presets

What I am building now

I am now building DeepSynth LSM, a model for creating modular-synth patches, and I occasionally stream live experiments on YouTube. This preset generator is the earlier, smaller piece of that longer exploration: a way to make the path from musical language to a working instrument concrete and testable.

For updates, subscribe to this Substack. You can also follow the ongoing experiments at legott.ai, on YouTube, and on X.