ToneForge AI

I wanted a tone-building tool for my own use that runs locally and privately, with no cloud service or subscription behind it, and that could be released as open source later. Describing a sound in words is how most guitarists talk about tone, so the interface starts there and ends in ordinary, editable pedal settings.

• DSP core. A C++20 library with no JUCE dependency, so it builds and unit-tests anywhere. It holds the effect modules (noise gate, compressor, overdrive, distortion, amp, cabinet, EQ, modulation, delay, reverb) and the preset model. The core has its own unit-test suite.
• Plugin. A JUCE wrapper that builds as VST3 and as a standalone app. It has an eight-slot pedalboard and an AI panel with four actions: Generate, Modify, Explain, and Reference Song.
• AI backend. A FastAPI service with endpoints for generate, modify, explain, song reference, and health. The plugin calls it over local HTTP.
• Model providers. One interface with two implementations: a deterministic keyword-based provider used for tests and as a fallback, and an Ollama provider that uses a local model (gemma3:4b).
• Song references. A small hand-curated table of songs matched by fuzzy search. For songs not in the table, the local model infers a tone, and the result is labelled as an approximation.

Text goes to the backend, which turns it into a small tone descriptor (gain, brightness, compression, delay, reverb, modulation, noise gate, plus reverb type, modulation type, and overdrive-versus-distortion). One mapping function expands that descriptor into a full preset of pedal parameters, and the plugin loads the preset into its slots. Both providers feed the same descriptor, so the pedal-parameter logic lives in one place.

• Descriptor between language and parameters. The model never writes raw pedal values. It describes the tone, and shared code decides parameters, which keeps model output constrained to values the DSP accepts.
• Local model, with a deterministic fallback. If Ollama is unavailable or returns unusable JSON after retries, the backend falls back to the keyword provider instead of failing.
• Categorical choices as words. The model is asked for "spring" or "chorus" rather than an index number, and the backend maps them back, since small models handle names more reliably than numeric codes.
• Honest labelling. Every song-based result carries a match type and confidence, and is presented as an approximation rather than a recreation.
• Few-shot prompting. Prompts include a few examples generated from the deterministic mapper so they are consistent with it.

• Generated presets had ten modules while the pedalboard has eight slots, so reverb was silently dropped from every AI preset. I found it by testing varied prompts, not just the default, and fixed it by making the chain builder respect the slot budget.
• A 4B-parameter local model does not reliably know obscure songs. Curated entries fix specific songs, and prompting for honest genre-based guesses helps, but neither adds knowledge the model lacks.
• I looked at fine-tuning a small model on generated data and wrote the dataset generator and training script, but did not run it, because the setup cost outweighed the uncertain benefit.
• Verifying on a real toolchain matters: building on Windows exposed a missing JUCE module include and a CMake test-discovery problem that the Linux-based checks did not.

Results are rough approximations. The cabinet is an EQ-shaped approximation rather than impulse-response convolution, and the amp is a simple waveshaper and tone stack rather than a modelled amp. Tone quality has been judged by ear on my own machine; there is no formal evaluation.