A Modern Voicing Platform for Allen Organ

The challenge

The instruments outgrew the software that voiced them

Allen Organ Company has been building organs in Pennsylvania since 1937. They introduced the first digital organ in 1971. Today, it is the world’s largest maker of digital church organs.

One of the most important parts of that work is voicing, and it happens in a room, not at a desk. After an Allen organ is installed, a specialist sits at the instrument with a laptop. They listen to how it sounds in that particular space and adjust the organ until it sounds right there. Voicing is central to Allen's craft. The company likes to say the most important stop on any organ is the room it's placed in.

Allen has built digital organs since 1971, and for decades DOVE was the software at the center of that work. It served Allen well, and it carried much of what the company had learned about adjusting its instruments. But Allen's latest instrument technology needed the organ and the software to communicate in ways DOVE was never built for. No update to screens or features would fix that, because the problem sat in how the application talked to the instrument.

So Allen stopped patching and decided to build a replacement from scratch. That meant changing everything underneath the tool without losing the working knowledge that made it useful.

The solution

A Windows platform built around the work of voicing

LARK is a Flutter application for Windows, built to support the session that happens beside the instrument. A specialist connects to the organ, listens, makes an adjustment, and listens again.

Its user experience design follows how Allen's specialists move through a session: which adjustments belong together, and what someone needs to see before sending a change to the instrument.

LARK isn't a general audio editor. It's software built specifically for adjusting the sound of an Allen organ.

The process

Learning a craft while the hardware kept moving

None of this could come from a spec sheet. Voicing knowledge lives with Allen's specialists. Building LARK meant learning from them what voices, tremulants, and key regions mean to the people who adjust them, along with how a session actually unfolds.

There was also no finished target to build against. Allen was developing its newest instrument hardware at the same time, so the way the organ and the application communicate kept evolving while both took shape. When the hardware changed, the software followed.

Testing happened at several levels. Automated tests covered the application logic on its own. An organ simulator made hardware-dependent behavior repeatable, so development could keep moving without an instrument in the room. The simulator was never a substitute for real hardware, though, so LARK was also validated on physical organs over live networks. The Windows installers for both the Factory and Dealer versions were tested as well, since the installer is part of what Allen and its dealers actually receive.

Both teams came away with a clear takeaway. On specialized work like this, it pays to define workflows, hardware boundaries, failure cases, and acceptance criteria in more depth before full implementation begins. That's where we'd invest first on the next project like it.