Architectural Review Board - Please visit my project!

I've been writing and rewriting Nama[1,2,3] for several years now. It's been my introduction to intermediate concepts in computer science.

Nama is an audio recording, mixing and editing application, using Ecasound[4] as the audio engine.

I'm proud of how it has evolved. At first it was all procedural, driven by a command processor loop. Then I added a Tk-based GUI, my first GUI. I added a text interface with a command grammar based on Parse::RecDescent. I introduced OO to separate the code for two different UIs. Then I added classes for tracks, buses and other entities. I added an event system (actually two), serialization, a help system, tests. I created a build system to automatically generate parts of the grammar, the help system, and to merge various files. The code for audio routing has gone through three different design interations: hardcoding, routing by rules, and now, routing by creating and transforming a graph.

I've cleaned up, commented, refactored wherever it could help. I profiled and memoized to speed up my code. I refer to a shelf full of well-respected Perl books, follow PerlMonks and other forums of the Perl community. Most of the really hard stuff I've solved by accreting other programs and libraries, largely from CPAN.

It's been exciting, exhiliariating, and at times laborious, confusing and opaque. I've had users helping to test, suggest features, and occasionally hold my hand.

Despite all my work to keep the code legible, even users familiar with perl have a hard time reading the code. I'm feeling ready for a visit by the architectural review board!

After reading a number of articles advising against the use of global variables. I'm wondering: Should I be encapsulating the 250 or so global variables into objects? (Clearly, yes.)

What about the way classes reach into each other for data?

Maybe I should be re-architecting my tests? Expanding test coverage is hard, but necessary. I'll need a way to build a test environment that includes (or fakes) some WAV files and other project data.

Welcome, ARB, especially those of you who are musicians!

  1. Nama - github
  2. Nama - cpan
  3. Nama - home
  4. Ecasound


Most of the questions you ask are utterly irrelevant to musicians. If I want a mixer, do I care whether or not its tests are "re-architected," or that the code is all object-y? No.

I would work on improving the documentation, perhaps dividing it into a page for people wanting to use Nama, and one or more for people wanting to extend it.

The alternative to globals is passing everything by parameters - i.e. Dependency Injection. I recommend all the writings by Misko Hevery on this subject:

Leave a comment

About Joel Roth

user-pic I blog about Perl.