Nagi opens its custom DSP layer through main.dsp, where the app gives you real Faust plus the full Faust standard library. The node editor is still the easier place to begin, but it stops being the best tool once the sound depends on behavior the ready-made blocks do not expose.
A graph can handle a lot before you need code. Anyone still debugging basic signal flow should keep the first Nagi plugin build simple before adding custom DSP, because the stock blocks already cover plenty of ordinary jobs.
Move over to Faust when the processing itself needs to be custom. If the sound needs a custom transfer curve, an unusual feedback structure, tighter control over parameter behavior, or reusable DSP logic, the Nagi visual plugin-building system gets you started while Faust gives you finer control over the processing.
Faust uses a different programming model from C++. It is a functional language built specifically for sound synthesis and audio processing, so the code describes signal relationships without requiring you to manage the usual plugin framework plumbing. The Faust compilation model for audio DSP is designed to turn one DSP description into efficient code for different deployment targets.
Nagi keeps this part inside main.dsp and adds syntax highlighting plus inline diagnostics. Build settings live separately in build-config.json, which is useful because DSP code and build configuration are different problems and do not need to be mashed into one file.
The standard library also saves you from writing basic audio maths from scratch. Importing stdfaust.lib gives Faust access to a large collection of filters, oscillators, envelopes, delays, reverbs, compressors, routing tools, physical models, and other building blocks that can sit inside your own processing design.
It matters once a custom DSP has several sections with similar controls. Faust does not allow two input controls to share the same path, so repeated labels inside a sloppy hierarchy can create a real error rather than a harmless naming quirk. Giving voices, bands, or processing stages distinct groups keeps those addresses separate.
Ranges deserve the same attention. Faust sliders define an initial value, minimum, maximum, and step, while Nagi can bind its interface controls to real parameters with their own ranges and response curves. A cutoff that technically runs from zero to some huge number can still feel awful to use if most of the useful movement is crammed into a tiny part of the knob.
Fast parameter movement has another wrinkle. Faust's own documentation notes that interface controls run at control rate and can produce clicks when moved quickly, with smoothing functions such as si.smoo available to tame abrupt changes. A custom Nagi DSP that sounds clean while sitting still can therefore need extra work before automation feels polished.
Using those pieces inside your own structure is where Faust gets interesting. You can keep proven building blocks for the routine parts and spend your effort on the signal relationship that actually makes the plugin different, whether it is an unusual modulation path, a custom dynamics curve, or a processing stage Nagi does not already expose as a node.
Inline diagnostics help while you are editing, but clean syntax is only one kind of success. Parameter addresses still need to match the controls you intend to expose, useful ranges need to survive real automation, and any fast-changing control may need smoothing before the result behaves like a finished plugin.
Keep the first Faust experiment small enough to hear what changed. Replacing one awkward section of a patch with a focused main.dsp implementation gives you a clearer read on whether custom code improved the design or simply made the same idea harder to inspect.
A graph can handle a lot before you need code. Anyone still debugging basic signal flow should keep the first Nagi plugin build simple before adding custom DSP, because the stock blocks already cover plenty of ordinary jobs.
Move over to Faust when the processing itself needs to be custom. If the sound needs a custom transfer curve, an unusual feedback structure, tighter control over parameter behavior, or reusable DSP logic, the Nagi visual plugin-building system gets you started while Faust gives you finer control over the processing.
Custom DSP earns its place when nodes get awkward
Using Faust in Nagi makes most sense when expressing the algorithm as nodes becomes awkward. Ten stock nodes wired together to fake one specific behavior may work, but a short DSP definition can be easier to inspect, easier to revise, and less annoying six weeks later.Faust uses a different programming model from C++. It is a functional language built specifically for sound synthesis and audio processing, so the code describes signal relationships without requiring you to manage the usual plugin framework plumbing. The Faust compilation model for audio DSP is designed to turn one DSP description into efficient code for different deployment targets.
Nagi keeps this part inside main.dsp and adds syntax highlighting plus inline diagnostics. Build settings live separately in build-config.json, which is useful because DSP code and build configuration are different problems and do not need to be mashed into one file.
The standard library also saves you from writing basic audio maths from scratch. Importing stdfaust.lib gives Faust access to a large collection of filters, oscillators, envelopes, delays, reverbs, compressors, routing tools, physical models, and other building blocks that can sit inside your own processing design.
Parameter paths are easy to ignore until they break
Nagi addresses Faust parameters by path, with names such as /Synth/Envelope/Decay. Faust builds those paths from interface labels and groups, so a neat parameter hierarchy is not just cosmetic naming. It becomes part of how controls are identified.It matters once a custom DSP has several sections with similar controls. Faust does not allow two input controls to share the same path, so repeated labels inside a sloppy hierarchy can create a real error rather than a harmless naming quirk. Giving voices, bands, or processing stages distinct groups keeps those addresses separate.
Ranges deserve the same attention. Faust sliders define an initial value, minimum, maximum, and step, while Nagi can bind its interface controls to real parameters with their own ranges and response curves. A cutoff that technically runs from zero to some huge number can still feel awful to use if most of the useful movement is crammed into a tiny part of the knob.
Fast parameter movement has another wrinkle. Faust's own documentation notes that interface controls run at control rate and can produce clicks when moved quickly, with smoothing functions such as si.smoo available to tame abrupt changes. A custom Nagi DSP that sounds clean while sitting still can therefore need extra work before automation feels polished.
The Faust library keeps experiments from becoming chores
A custom Nagi DSP does not have to mean inventing every oscillator or filter yourself. Faust's libraries already include common Butterworth filters, resonant filters, filter banks, envelope generators, anti-aliased oscillators, delays, reverbs, analysis tools, and a long list of more specialized processors.Using those pieces inside your own structure is where Faust gets interesting. You can keep proven building blocks for the routine parts and spend your effort on the signal relationship that actually makes the plugin different, whether it is an unusual modulation path, a custom dynamics curve, or a processing stage Nagi does not already expose as a node.
Inline diagnostics help while you are editing, but clean syntax is only one kind of success. Parameter addresses still need to match the controls you intend to expose, useful ranges need to survive real automation, and any fast-changing control may need smoothing before the result behaves like a finished plugin.
Keep the first Faust experiment small enough to hear what changed. Replacing one awkward section of a patch with a focused main.dsp implementation gives you a clearer read on whether custom code improved the design or simply made the same idea harder to inspect.
