Firmware 3.2.0 shipped on October 8 with four features, two fixes, and two bounty payouts. The release took four months. The feature that took longest was one nobody outside the community asked for, and it nearly did not ship, because for eleven months the argument was not about code. It was about what a sequencer is allowed to decide on your behalf.
Our release notes read like receipts on purpose: every change, every fix, every contribution with a name attached, and every miss we made that cycle published in the same document. This note is the story behind one line of that receipt, and a defense of why receipts beat announcements.
The skip engine argument
ARRAY-16 has a skip engine: when a stage is programmed to skip, the sequencer jumps over it. The first version skipped cleanly, which was the problem. A skip that lands wherever it lands in time sounds like a machine losing its place. Musicians do not want a machine that loses its place; they want a machine that knows where the beat went.
K. Iwasaki's community patch proposed the answer that shipped: the skip engine follows the musical beat instead of the sample clock, so a skipped stage collapses into the nearest musical subdivision rather than the nearest millisecond. The patch worked immediately and the argument took eleven months anyway, because the version that follows the beat has to know what the beat is, and there were five honest definitions of "the beat" in the community thread and no way to pick one by being right.
The resolution was structural: the shipped engine follows the master clock's downbeat definition by default, and all four other definitions are selectable, documented, and named after the people who argued for them. The changelog entry credits K. Iwasaki for the winning patch and three other community members for the definitions that lost. Nobody lost in a way you cannot see, which we count as the actual feature.
Why receipts beat announcements
A marketing announcement optimizes for the story. A receipt optimizes for the audit. We ship receipts because our users are the kind of people who read them, and because a release note that names every miss trains the whole company to notice misses early. The FLUX CORE routing default in 3.1.2 is the example I point new hires at: four units shipped with an undocumented default, we found it ourselves, and the changelog entry says so with the batch number and the correction path. A rival company would have called that a security incident. We call it a Tuesday, because the alternative is a culture where quietly patching feels safer than writing it down, and that culture is how small mistakes become large ones.
What "boring" buys
The 3.x family has shipped eleven releases in nineteen months with zero regressions that reached the field. That is not because the firmware team is careful, although they are. It is because the release format makes every change visible to the whole company before it ships, and visible changes collect corrections while they are cheap. The boring format is the review process.
The 3.2.0 receipt also carries the two bounty payouts from this cycle, P. Almeida and S. Novak, both confirmed timing bugs, both paid in modules. The bounty program exists because the best firmware reviewer for any module is the person who uses it in a way we did not imagine, and the fastest way to find that person is to make the receipt worth reading.
Corrections. An earlier draft said 3.2.0 shipped "three features." It was four; the calibration table documentation in the housekeeping section was promoted to a feature by the community's count, which we accept. The release notes are unchanged.
Filed under: firmware, process. The full receipt is on the changelog page, and the repository history is intact back to the first commit, including the embarrassing ones.