Auditor's Guide

This document is the entry point for a code, security, or technical due-diligence review of Buffle Audio Visualize. It states the scope, provenance, dependencies, security posture, real-time characteristics, and validation methodology, and points to where each claim can be verified in the source.

Everything here is meant to be checkable. Where a claim can be reproduced with a command, the command is given.

1. What this software is (and is not)

2. Provenance & reproducibility

3. Dependencies & licensing

Component Version Role License
This project 4.0.1 Plugin source, installer, docs MIT (see LICENSE)
JUCE 8.0.7 Application/audio framework Dual: JUCE personal/commercial or AGPLv3

Licensing note for the auditor: the project's own code is MIT, but it links JUCE, which is dual-licensed. Any party building or redistributing binaries must satisfy the JUCE license terms that apply to them (JUCE's own personal/ commercial terms, or AGPLv3). This is a compliance item for the distributor, not a defect in the source. See THIRD_PARTY_NOTICES.md. No other third-party code is vendored in WaveformVisualizer/Source/.

4. Security posture

Concern Status How to verify
Network access None grep -rniE "URL|Socket|http|WebBrowser|curl" WaveformVisualizer/Source/ → no matches
Telemetry / analytics None Same as above; no analytics SDKs are linked
Data collection None No user data is read, stored, or transmitted
Filesystem writes User-initiated only Only the HTML mix report, to a path the user picks via a save dialog (TimelineComponent::exportReport)
Filesystem reads User-initiated only Only a reference audio file the user picks (SpectrumComponent::chooseReferenceFile)
Process launch The exported report only File::startAsProcess() opens the report the user just saved
Credential / secret handling None No secrets in the repo; nothing is entered or stored
Plugin state persistence Settings only, in-project getStateInformation / setStateInformation (de)serialize a juce::ValueTree — UI/analysis settings (waveform window, vectorscope view, spectrum averaging/hold, Translation Lens, Masking Radar toggle) and the tone-match reference library. No audio, no filesystem paths beyond what the DAW itself already persists, no network — the data lives entirely inside the host's own project file.
Cross-instance data sharing (v4.0.0+) In-process only, metrics only InstanceRegistry.h uses juce::SharedResourcePointer so instances loaded in the same OS process can read each other's name and metrics (LUFS/true peak/correlation) for the session panel. No shared memory, sockets, or files — it is a plain C++ object shared within one process's address space, and it holds no audio and no user data beyond those three numbers and a display name.
Code signing Ad-hoc / unsigned The installer is not Developer-ID signed or notarized

Net: the plugin's only I/O beyond audio is two explicit, user-driven file operations. It does not phone home.

5. Real-time safety

Audio plugins must avoid unbounded work, blocking, and allocation on the audio thread. This project's characteristics are described honestly in ARCHITECTURE.md § Threading & synchronization model. Summary for the reviewer:

None of these are defects; they are the points a real-time reviewer should weigh, and they are surfaced deliberately.

6. Validation methodology

Every release is validated with:

  1. pluginval at strictness level 10 — the strictest setting. It open/closes the editor repeatedly, processes audio across sample rates (44.1–96 kHz) and block sizes (64–1024), enumerates and toggles bus layouts, round-trips plugin state, and fuzzes parameters. Every release since v3.0.0, including the current v4.0.1, returns SUCCESS.

    pluginval --strictness-level 10 --validate \
      ~/Library/Audio/Plug-Ins/VST3/buffleaudio_visualize.vst3
  2. Standalone launch smoke test — the app is launched, confirmed alive for several seconds, checked for crash reports, and quit cleanly.

  3. Clean Release build — zero compiler warnings in first-party source (JUCE's own SDK warnings are out of scope).

There is not yet an automated unit-test suite; validation relies on pluginval's behavioral coverage plus the smoke test. Adding first-party unit tests for the DSP (e.g. LUFS against reference tones, K-weighting coefficients, true-peak on known signals) is a recommended next step and is noted in the roadmap.

7. Suggested review path

  1. PluginProcessor.cpp — confirm the audio pass-through and engine wiring.
  2. The four engines (*Analyzer.{h,cpp}, WaveformBuffer.{h,cpp}) — DSP and the atomic/lock publication pattern.
  3. PluginEditor.{h,cpp} — the 10 Hz health/recorder tick and the metric snapshot.
  4. HealthMonitor.h, SessionRecorder.h, TimelineComponent.cpp — message-thread logic; note SessionRecorder::exportReport builds HTML by string concatenation (report content is derived from numeric metrics, not user free-text).
  5. SpectrumComponent.cpp — the largest file; references, Translation Lens, and Masking Radar. The file/threading touch-points are chooseReferenceFile (open dialog + background analysis) and nothing else external.

8. Known limitations & areas of attention

9. Points of contact

Issues and questions: the project's GitHub issue tracker. Security reports: see SECURITY.md.

Mirrored from the project source for the public site — see the in-repo Markdown for the canonical, linkable version.