What problem does it solve? Building and validating audio instruments requires iterating on DSP parameters, rendering test audio, and comparing results, which is tedious to do manually across preview renderers and native JUCE builds. ## Core Features & Use Cases - Instrument creation and validation: Modify audible properties like waveform, pitch, attack, or brightness, render a four-note phrase before and after, and compare peak/RMS levels between WAV files. - Native JUCE rendering: Edit the workspace CMake project's Source/main.cpp, run the juce action to compile a native offline renderer, and inspect the measured recording. - Run tracking and reproducibility: Successful artifacts and measurements are stored in out/runs/<id>/ with out/latest.json naming the current result, while failed runs preserve the last success and record the error. - Use Case: An instrument maker adjusts the brightness control in studio.json, renders the same phrase before and after the change, and tells the user which run contains the result and what was actually measured. ## Quick Start Ask the agent to change one audible property such as waveform or brightness in the JUCE workspace, render the four-note phrase before and after, and compare the resulting WAV files.
