Week 1 establishes the development environment and the foundation the rest of the project depends on. It installs the JUCE framework, sets up a reproducible CMake build, builds a minimal plugin that loads and produces sound, reviews the CLAP specification, and puts the work under version control. The milestone for the week is a sine-tone plugin that loads and produces audio in all target hosts. The plugin and its build are in place. The host-load verification is captured separately as evidence, the one item still outstanding, deferred to a short capture task before submission.
Design study
The week begins before any code, with a study of what the instrument is and why. Eidolon is a hybrid software synthesizer. It combines three synthesis architectures, subtractive, additive, and wavetable, in a single instrument. The motivation comes from working with hardware modular systems, the Eurorack and Buchla 200-series instruments, where signal flow is physical and audible. The aim of the contract is to translate that physical intuition into real-time C++. The design target is documented in the sound-design reference at ../../docs/ILC_Eidolon_Sound_Design.md and the concept renders under ../../images/concept/, which fix the sonic goal and the reference instruments before implementation begins. Establishing the target first is deliberate. The architecture of the build follows from the sound the instrument has to make, and a three-mode instrument with two filters, modulation, and effects is large enough that the toolchain has to be reproducible and scriptable from the first day rather than assembled by hand.
Build environment and toolchain
The project builds with CMake and a vendored copy of JUCE pinned as a git submodule, rather than the Projucer GUI generator. The reason is reproducibility. The entire toolchain rebuilds from a recursive clone and two CMake commands, with no GUI step and no machine-specific project file to keep in sync. Exporting compile_commands.json from the CMake configuration gives CLion and any clangd-based editor accurate navigation and inline diagnostics. Plugin formats are declared once in the build description. The minimal Week 1 build emits AU, VST3, and Standalone from a single juce_add_plugin target. The full instrument adds a CLAP build through the clap-juce-extensions bridge, a separate concern taken up in Week 8.
The minimal plugin and the AudioProcessor lifecycle
The core study target for the week is the JUCE AudioProcessor lifecycle, the contract every plugin format obeys regardless of host. The constructor declares the bus layout. A synthesizer has no input bus and one stereo output, so the constructor sets that up and does no audio work. prepareToPlay receives the sample rate and maximum block size from the host. It is the only place allocation and setup are permitted. processBlock runs on the real-time audio thread, where allocation, locks, and file access are all forbidden because any of them can block and cause a dropout. releaseResources frees what prepareToPlay set up once the host is finished.
The minimal plugin in code/ implements all four stages. It uses JUCE's Synthesiser and SynthesiserVoice model for polyphony. The synthesiser owns a pool of voices, walks the incoming MIDI buffer, dispatches note-on and note-off events to free voices, and sums their output. This is the same structure the full instrument uses, so Week 2 can replace the sine voice's render with a real oscillator base class without disturbing the surrounding lifecycle. One deliberate detail in the sine voice is worth noting. Switching a full-amplitude sine on or off instantly produces an audible click, so the voice ramps its level over a few milliseconds at note boundaries. That is the first concrete encounter with the reason envelopes exist, and it anticipates the ADSR work in Week 5.
The code in code/ is a minimal teaching artifact written to demonstrate these competencies, not an excerpt of the full engine. It is a standalone reading reference, so an editor opened on it reports a missing juce_audio_processors.h. That is expected, because the folder is not wired to a build.
CLAP specification
The week also includes a first reading of the CLAP specification headers, the open C-language plugin standard developed by Bitwig and u-he, with notes kept for the comparative study in Week 8. CLAP is a plain C ABI organized around an extension system. Rather than inheriting from a large base class, a plugin exposes named extension structs that the host queries for parameters, audio ports, and note ports. Its threading contract is stated explicitly in the specification. Each extension documents whether the host may call it on the main thread or the audio thread, which maps directly onto the lifecycle discipline above. One practical point carries forward. Bridging JUCE to CLAP requires the host and plugin to agree on parameter ranges, and the full project sets the bridge to report actual ranges rather than normalized values, since a mismatch there causes parameters to stick during the host round-trip. That is noted now and analyzed properly in Week 8.
Version control and status
The project is under git with JUCE and clap-juce-extensions pinned as submodules at fixed commits, so any checkout reproduces the same build. Commit discipline is in place. Commits use conventional messages that explain the reason for a change, and a pre-commit gate runs formatting and the project's verification pipeline before accepting a commit.
The milestone has two halves. The first is a plugin that produces audio, which is the code path, and it is written and in place. The second is that the plugin loads and produces audio in Ableton Live, Bitwig Studio, and Logic Pro. That half is observable only in a running host, so it is captured as screenshot evidence, the single deferred item, described in evidence/README.md. The report counts as complete only the work performed this week. That is the toolchain, the lifecycle implementation, the sine render path, the CLAP reading, and the repository. It treats compiling, running, and host-loading the minimal plugin as deferred until the evidence task is done, rather than claim a result not yet observed.
Hours
The roughly thirty hours divide across the design study at six, the JUCE lifecycle and hosting model at seven, CMake and toolchain setup at six, the minimal plugin implementation at six, the CLAP specification reading and notes at three, and repository setup with this report at two.
References
- JUCE
AudioProcessor,Synthesiser, andSynthesiserVoiceclass documentation - JUCE CMake API (
juce_add_plugin) documentation - CLAP specification headers (
clap/clap.hand the extension headers) - The project sound-design reference,
../../docs/ILC_Eidolon_Sound_Design.md - Hardware reference: the Buchla 200 series and Eurorack modular signal flow
Next week
Week 2 implements the oscillator base class shared across all three synthesis modes, then the subtractive oscillator with saw, square, triangle, sine, and noise waveforms, all anti-aliased. The sine voice's render path from this week is the seam where the base class plugs in. The polyBLEP algorithm is the studied anti-aliasing baseline, documented against the C1-continuous approach the project uses for its analog character.