SamediDimanche/NeuralSynth
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d9f672cd1005f3db0567d81d449d8b14b5a04a3b
NeuralSynth/AGENTS.md
Roboboffin 3ac2cc15b1 Fix line endings and some cleanup
2025-10-23 04:00:21 +01:00

2.6 KiB
Raw Blame History

Repository Guidelines

Project Structure & Module Organization

NeuralSynth is a JUCE-based synthesizer plugin. Core runtime code lives in Source/, with PluginProcessor.* orchestrating audio/MIDI flow, PluginEditor.* driving the UI, SynthVoice.* implementing per-voice DSP, and helper headers such as AudioEngine.h and NeuralSharedParams.h exposing shared state. JUCE-generated scaffolding sits in JuceLibraryCode/; regenerate it through NeuralSynth.jucer rather than editing by hand. Platform build assets are under Builds/ (for example Builds/LinuxMakefile/), and finished binaries default to Builds/LinuxMakefile/build/. Install scripting for Windows lives in NeuralSynth.iss.

Build, Test, and Development Commands

  • cd Builds/LinuxMakefile && make CONFIG=Debug compiles the standalone app and VST3 with debug symbols.
  • cd Builds/LinuxMakefile && make CONFIG=Release builds optimized artefacts for distribution.
  • cd Builds/LinuxMakefile && make clean removes intermediate objects when builds misbehave.
  • ./Builds/LinuxMakefile/build/NeuralSynth launches the standalone target; VST3 binaries appear in Builds/LinuxMakefile/NeuralSynth.vst3 and copy into ~/.vst3 when the Makefile post-build step runs.

Coding Style & Naming Conventions

C++ sources use 4-space indentation, brace-on-new-line functions, and JUCE’s juce:: namespace types. Prefer PascalCase for classes (e.g., NeuralSynthAudioProcessor), camelCase for methods and members (prepareToPlay, audioEngine), and suffix queues/collectors clearly (AudioBufferQueue, ScopeDataCollector). Match existing lambda formatting in SynthVoice.cpp, keep includes sorted locally, and avoid editing generated files under JuceLibraryCode/.

Testing Guidelines

Automated tests are not yet configured; rely on manual validation in the standalone app or a DAW host. After each change, rebuild and audition key features: oscillator switching, chorus/delay/reverb chains, parameter automation, and MIDI input. For DSP tweaks, monitor the oscilloscope components linked to the buffer queues to confirm signal stability. Document ad-hoc test coverage in your pull request until formal tests are added.

Commit & Pull Request Guidelines

Follow the existing concise, imperative commit style (Add chorus modulation, Fix voice detune). Scope each commit to a logical change and format messages as a single summary line. Pull requests should describe the motivation, outline testing performed, and link issues when relevant. Include platform notes (Linux, Windows installer) and screenshots or audio clips for UI-affecting or sonic changes so reviewers can assess impact quickly.