Nobody is standing at your desk

Start here

The most valuable thing you can send costs you ten minutes

Not code. A report from a rig the maintainer does not own.

Getting started

Clone, run, change something

You need JDK 25+ and Maven 3.9+. You do not need a measurement mic, an interface, or a venue — every source runs from a simulated preset.

1. Get it running

   Two commands. The window that opens is the one in the screenshots, driven by simulated sources.

   $ git clone https://github.com/d135-1r43/fohanalyzer
   $ cd fohanalyzer
   $ mvn javafx:run

   mvn test and mvn package work even if JAVA_HOME points at an older JDK — the POM picks an installed 25+ toolchain. Running and packaging are not covered by that, so put JAVA_HOME on 25 yourself:

   $ export JAVA_HOME=$(/usr/libexec/java_home -v 25)   # macOS

2. Find your way around

   Five packages, no framework, no dependency injection container, no code generation. engine and dsp are pure functions with full test coverage — start there if you want a change that is easy to prove correct.

   The README is unusually detailed on purpose: it explains not just what the code does but why it is shaped that way, down to why the Blackman window is the symmetric definition and why the broadband RMS is hand-rolled. Read the section covering the area you are touching before you change it — it will usually already answer your first question.

3. Use the dev aids

   CSS hot reload re-applies theme.css to the running window on save, so padding and colour work does not need a restart. The render probe boots the app, snapshots the window and exits — handy for a visual check without a display.

   $ FOH_DEV=true mvn javafx:run   # CSS hot reload
   $ PROBE=true mvn javafx:run     # snapshot to target/probe-full.png, then exit

4. Match the house style

   The style is the Eclipse formatter profile in formatter/java.xml: tabs at width 4, braces on their own line, comments wrapped at 80 columns. It is enforced, not suggested — the formatter's validate goal runs in the validate phase, so any build fails on an unformatted file, including mvn test.

   $ mvn formatter:format   # apply it, then commit

   One quirk that will bite you

   The profile sets join_line_comments=false, so the formatter splits an over-long // line but never rejoins the remainder. Keep // lines inside 80 columns yourself — counting the tab indent — and put a long comment on its own line above the statement rather than trailing it.

5. Test what you can test

   EngineTest, SignalStateTest, AudioDspTest and SettingsTest cover the band maths, note naming, formatting, simulation, averaging, smoothing, peak hold, the spectral logic and the settings store. If your change touches any of that, it needs a test.

   The JavaFX controls have no unit tests and that is deliberate — they are trivial and the harness would cost more than it caught. Nobody will ask you to add one.

   $ mvn test

6. Open the pull request

   One change per PR, and say what a reviewer should look at. If it is visible, attach a screenshot — PROBE=true mvn javafx:run will take one for you. CI runs the tests, the format check and a full package on every push, so you will know within a few minutes whether it holds.

   Draft PRs are welcome, and so is asking first. An issue that says "I am thinking of doing X, is that wanted?" saves everyone an afternoon.

What needs doing

Pick something that suits you

Roughly ordered by how self-contained they are. None of these are assigned to anyone, and the issue tracker is short enough to read in a minute — open an issue saying which one you are taking, so two people do not build the same thing.