Reply to thread

Message: [QUOTE="Shamiso, post: 92737, member: 160"] Nagi's interface designer supports knobs, sliders, meters, spectrum and envelope displays, keyboards, preset browsers, response curves, and custom image skins. The useful part is not the pile of widgets. It is the fact that the controls can be tied to actual plugin parameters instead of existing mainly for appearance. A good Nagi panel starts after the DSP already behaves properly. If the filter range is wrong or the mix control clips at one end, a nicer knob will only make the bug easier to grab. The [URL='https://goldmidi.com/community/threads/your-first-nagi-plugin-does-not-need-c.78147/']first Nagi plugin build[/URL] is the better place to sort out signal flow and basic host testing before spending an hour on layout. Keep the first interface embarrassingly plain. Give the user the controls needed to shape the sound, make their labels obvious, and leave internal housekeeping parameters off the front panel unless they genuinely help. [HEADING=2]Parameter mapping decides whether the panel feels right[/HEADING] Nagi lets each control bind to a real parameter, which means the first job is deciding what deserves to be exposed. A delay may have plenty happening internally, but the person using it probably cares more about time, feedback, tone, and mix than every coefficient or intermediate value behind the processing. The [B][URL='https://doi.org/10.5281/zenodo.1176424']parameter-mapping study[/URL][/B] made the same point years ago, arguing that the mapping between controls and system parameters can define an electronic instrument as much as its interface or sound engine. It sounds obvious until a plugin panel ends up mirroring its implementation instead of the way somebody actually thinks about the effect. Custom Faust projects make the naming side more important. Nagi can address Faust parameters by paths such as /Synth/Envelope/Decay, so the GUI needs to point at the parameter you intended, not merely something with a familiar label. The [URL='https://goldmidi.com/community/threads/nagis-faust-dsp-editor-starts-where-nodes-stop.78149/']Nagi Faust DSP workflow[/URL] goes deeper into parameter paths and the collisions that can happen when several controls share sloppy names. Map one control, move it, and listen before mapping ten more. Check whether the displayed value tracks the sound in a way a normal user would expect. A knob labelled feedback that suddenly jumps into unstable territory near the end of its travel may be technically connected and still feel badly designed. [HEADING=2]Ranges and response curves do more work than skins[/HEADING] Nagi supports per-widget ranges and response curves, which is where a basic panel can start feeling deliberate. Not every parameter needs equal screen travel across every value the DSP can technically accept. Useful control often lives in a smaller region. Frequency controls are the obvious case. Human pitch perception is not linear, so a straight numerical sweep can waste a huge amount of knob movement where the ear does not experience the change evenly. A response curve can make the physical motion of the control better match how the parameter feels while you use it. The same thinking applies to time, gain, resonance, drive, and modulation depth. You do not need to invent a fancy curve for everything, but you should drag each control slowly from minimum to maximum and notice where the useful action actually happens. If ninety percent of the interesting sound sits inside the last ten percent of the knob, the mapping needs work. The [B][URL='https://goldmidi.com/community/threads/minimal-instruments-has-introduced-nagi-plugin-builder.78128/']Nagi interface and plugin workflow[/URL][/B] gives you knobs, sliders, displays, filmstrips, keyboards, preset browsers, and image skins on the same canvas. Use the extra range because the plugin needs it, not simply to fill unused panel space. [HEADING=2]Displays and skins should earn their space[/HEADING] Meters and spectrum displays are useful when they tell you something the sound alone does not make easy to judge. A compressor can benefit from visible level or gain reduction feedback. A simple one-knob saturator probably does not need a tiny spectrum analyzer burning space just to look serious. Preset browsers follow the same rule. Add one when the plugin has enough meaningful states to browse and recall. A keyboard makes sense for an instrument or MIDI-driven design, while an envelope display earns its keep when the user is actually shaping an envelope. Custom skins and filmstrip controls can come last. Nail the spacing, labels, ranges, parameter assignments, and basic hierarchy first, then make it look like a finished product. A gorgeous panel with a cutoff knob mapped to the wrong range is still broken. Do a final interface pass with your eyes on the controls rather than the graph. Move every knob and slider through its full travel, watch every meter, switch every preset, and confirm each label describes what the DSP really does. The panel is finished when you can use the plugin without mentally translating its internal structure first. [/QUOTE]

Name