Building an audio plugin normally starts far away from the way musicians build sounds. Before an oscillator can reach a filter inside a finished VST3, a developer may need DSP knowledge, a programming language such as C++ or Rust, plugin SDKs, graphical-interface code, build systems, and platform-specific packaging.
Minimal Instruments’ nagi tries to move the starting point back toward sound.
Released in beta on September 23, 2026, nagi is a desktop application for Windows, macOS, and Linux that lets users construct audio plugins by placing DSP nodes on a canvas and wiring them together. Oscillators, filters, effects, MIDI, parameters, and audio connections can share the same graph. More advanced users can move into Faust code, design a custom interface, preview the result, and then build native VST3 or CLAP plugins from the same project.
That workflow makes plugin development resemble modular synthesis: begin with a signal path, connect functional blocks, listen immediately, then make the system more sophisticated only when the sound requires it.
The Node Editor Makes DSP Look Like A Patch
The most important part of nagi is its node editor.
According to the September 23 nagi release report, users can drag oscillators, filters, dynamics processors, and effects onto a canvas and connect their ports to create a working audio path.
Ready-made modules include processors such as reverb, compression, chorus, flanging, de-essing, formant filtering, and stereo imaging.
That is conceptually close to a modular synthesizer.
A modular user does not begin by writing the mathematical equation for an oscillator. The oscillator already exists as a module. The creative task is deciding what should feed it, what it should control, and where its output should go next.
nagi applies that same logic to plugin construction.
Audio, MIDI, and parameter connections can exist on the visual graph together. Instead of thinking first about classes, callbacks, or SDK structures, a producer can think in terms of signal flow.
That does not remove DSP from the plugin. It changes where the user encounters it.
The first question becomes “what should connect to what?” rather than “how do I implement this architecture in code?”
Instant Preview Keeps The Workflow Close To Sound Design
Traditional plugin development can introduce a long gap between an idea and hearing it.
A developer edits code, compiles the project, loads the resulting plugin, finds a problem, returns to the source, and repeats the cycle. Modern development environments can shorten that process, but the basic loop remains different from patching a synthesizer.
nagi includes an instant preview system.
Users can hear a graph before compiling it into its final plugin form. That is a significant design choice because it keeps experimentation inside the listening process.
Connect a filter differently and hear the result.
Add a chorus node and audition it.
Change an envelope or modulation path and listen again.
This is much closer to the feedback loop producers already know from modular software, node-based synthesis environments, and visual programming systems.
The practical advantage is not simply speed.
Immediate listening changes what people are willing to try.
A producer may test a strange routing idea when the cost is one cable and a few seconds. The same experiment feels more demanding when it requires editing source code and rebuilding an application.
nagi turns iteration into part of sound design rather than a separate software-development stage.
Faust Provides A Route Beyond The Ready-Made Nodes
Visual systems become restrictive when users can only choose from what the developer already included.
Minimal Instruments addresses that limit with Faust.
nagi projects include access to main.dsp, where users can write signal-processing code using the Faust language and its standard library. Syntax highlighting and inline diagnostics are built into the editor.
Faust was developed specifically for audio DSP, which makes it a natural bridge between visual patching and lower-level signal design.
The graph can therefore act as the entry point rather than the ceiling.
A beginner might build an effect entirely from supplied nodes. Someone with more DSP experience can replace or extend parts of the system with custom Faust processing.
That progression resembles modular hardware again.
A musician can begin by buying existing modules. Later, the same musician may start designing unusual utilities, modifying circuits, or building modules that do something unavailable in the standard catalog.
nagi attempts to create a similar gradient in software.
The user does not need to begin as a programmer, yet the project can become increasingly technical when the idea demands it.
The Interface Designer Makes The Plugin More Than A DSP Graph
A working signal chain is not a finished plugin.
Someone eventually has to decide what another user will see.
nagi includes a separate interface-design layer with knobs, sliders, meters, envelope displays, spectrum views, keyboards, filmstrip animations, and preset browsers.
Controls can be connected to actual plugin parameters, with ranges and response curves configured for the intended interaction.
This matters because interface design is part of audio-tool design.
A delay with 30 exposed parameters feels different from the same DSP represented by four carefully chosen controls. A compressor whose most important behavior sits behind an obscure menu communicates a different creative intention from one built around a single prominent control.
Plugin creation therefore involves deciding which parts of the underlying system become playable.
nagi gives that decision a visual canvas too.
The user can build the sound-processing graph first, then decide how much of that graph should appear on the front panel.
This is another point where the application moves toward instrument design rather than simple code generation.
The internal system can be complicated.
The visible plugin does not have to be.
Building VST3 And CLAP Is Where The Experiment Becomes A Product
Visual patching environments have existed for decades.
What distinguishes nagi’s proposition is that the graph is intended to leave the builder.
Minimal Instruments says nagi can compile native VST3 and CLAP binaries directly from a project. Builds can target Windows, Linux, and macOS.
That turns a patch into something a normal DAW can load.
The distinction is important.
A Max patch, modular environment, or experimental DSP graph can be useful without ever becoming an independent plugin. nagi is designed around an additional step: packaging the idea as a conventional audio tool.
A producer might create a personal utility for one session.
Another user could build a custom distortion architecture and use it across several DAWs.
A sound designer could develop a specialized effect, add an interface, compile it, and distribute the resulting plugin.
Projects are stored as ordinary files, and the graph is saved in JSON. That makes versioning practical with tools such as Git rather than trapping the project inside an opaque proprietary document.
The software-design layer becomes more accessible without discarding established development workflows entirely.
Local AI Is An Assistant Rather Than The Whole Builder
Nagi includes an AI assistant, but its role is narrower than “describe anything and receive a finished plugin.”
Minimal Instruments says the assistant can draft Faust DSP or graphical-interface layouts from a written request.
The model runs locally on the user’s computer rather than sending the project to a remote service.
That makes the AI feature compatible with the rest of nagi’s structure.
A user can begin visually, ask the assistant to produce a more specialized piece of Faust, inspect the result, edit it, connect it into the graph, and continue listening.
The AI is another entry point into the same project.
That is more useful for audio development than treating the whole plugin as an inaccessible generated artifact.
A producer who understands what a compressor should do but cannot write the DSP from memory can request a starting point. Someone who already knows Faust can ignore the assistant and work manually.
The important part is that the generated result remains connected to an editable development environment.
Plain Project Files Make The Workflow Less Dependent On A Cloud Service
Minimal Instruments also emphasizes local ownership.
nagi projects live as files on disk, and the developer says users do not need an account simply to build plugins. Local builds can use the user’s own development setup, while an isolated container can provide another reproducible build path.
That distinction matters for creative tools built around AI-assisted workflows.
A cloud-only builder can create a dependency between the project and the continued operation of a remote service. If the project format, compiler, or generated source remains inaccessible, long-term maintenance becomes difficult.
nagi takes a more conventional software-project approach.
The graph is stored as JSON.
Faust DSP remains visible.
Build settings are stored in project files.
Users can place those files under version control.
This gives the project a life beyond one design session.
For developers, reproducibility is valuable. For musicians who are new to software development, the same structure introduces habits that make increasingly complex projects manageable.
The tool may feel like modular patching on the surface, but the files underneath still behave more like software.
The Beta Is Free, But nagi Pro Has A Planned Price
nagi is currently in beta.
KVR Audio lists version 0.15.0, with Windows 10/11, macOS Ventura or later, and Ubuntu 24.04 among the documented environments.
Downloading, patching, previewing, and building are currently free. During the beta phase, nagi Pro features are available without charge.
Minimal Instruments says the Pro tier is planned as a $99 one-time purchase after beta, with no subscription or expiration and support for up to three computers per license.
The developer also states that beta-phase Pro licenses will terminate once the beta ends, meaning current free Pro access should not be interpreted as a permanent commercial license.
That distinction matters for anyone evaluating nagi as part of a long-term workflow.
The current beta makes experimentation inexpensive.
The final division between free and Pro capabilities will determine how much of today’s workflow remains available without the paid upgrade.
Visual Plugin Building Could Change Who Experiments With DSP
The most interesting audience for nagi may not be experienced plugin developers.
Someone already comfortable with JUCE, Rust audio frameworks, CMake, Faust, plugin SDKs, and cross-platform release engineering can already make sophisticated tools.
nagi potentially changes the entry point for producers who think clearly about signal flow but have never considered themselves software developers.
That group is large.
A producer may know exactly how an unusual delay should behave.
A modular musician may have spent years building feedback networks.
A mixing engineer may repeatedly construct the same effect chain in every project.
A sound designer may understand modulation relationships intuitively but have no interest in learning C++ before testing an idea.
Node-based building lets those people begin with knowledge they already possess.
RobSonic has explored a similar shift from abstract parameters toward direct visual interaction in its Iota II sampling workflow. Iota II turns spectral sample exploration into something users can draw. nagi applies the broader principle to tool creation itself: the architecture becomes something that can be seen and connected.
No-Code Does Not Mean No Technical Decisions
A visual interface can simplify plugin construction, but it cannot eliminate the underlying engineering questions.
Feedback paths can become unstable.
Filters can behave poorly near extreme parameter values.
Gain staging still matters.
MIDI behavior must make musical sense.
Automation needs predictable parameter ranges.
CPU use can become significant when graphs grow.
Plugin state must restore reliably when a DAW project reopens.
Cross-platform deployment introduces another layer of testing.
nagi can lower the amount of code required to reach these problems, but the problems themselves remain.
That may be beneficial.
Instead of forcing beginners to learn software infrastructure before encountering audio engineering, nagi lets them meet DSP problems directly through a working patch.
A user can hear why a feedback network needs control.
The effect of poor gain staging becomes audible rather than theoretical.
Parameter smoothing becomes relevant when a knob creates clicks.
In that sense, visual construction may become a teaching environment as much as a productivity tool.
Why nagi Feels More Like Modular Patching Than Software Engineering
The strongest idea behind nagi is not that programming disappears.
It does not.
The application still produces software. Faust remains available. Builds still target formal plugin formats. More complex projects will still reward knowledge of DSP and software architecture.
What changes is the first creative gesture.
A traditional plugin project may begin by creating source files and configuring a development environment.
nagi begins with a canvas.
Place an oscillator.
Connect a filter.
Route a parameter.
Add an effect.
Press play.
That sequence is much closer to patching a modular synthesizer than conventional application development.
Once the idea works, the project can grow outward. Faust adds custom DSP. The interface designer determines how the plugin should be played. Local AI can help draft specialized pieces. VST3 and CLAP builds turn the patch into something another DAW can load.
The path therefore runs from musical system to software product rather than forcing every idea to begin as software engineering.
For producers who have repeatedly thought, “I wish there were a plugin that did exactly this,” that inversion could matter.
The custom plugin may stop feeling like something that requires becoming a programmer first.
It can begin the same way many electronic musicians already build sounds: put useful modules on a surface, connect them, and listen to what happens.