Creating the gainstaging utility — Part 2

After messing around with complicated spreadsheet to calculate optimal mic gains, I though it really shouldn't be that hard. So I set about writing a python utility to take care of the heavy lifting.

For more background on what lead to here, see the original post about calculating gains for classical recording and the first post about this utility.

Development update

tl;dr: If you're here for calculating your mic gain settings, skip this section.

I chose Python as the programming language to go with, as I find it very quick way to through together a prototype, and I use it as a CLI calculator whenever I need something more powerful than dc. I'm using Python 2.7, but with all the unicode headache I caused myself supporting micro-Pascals as 'µPa', I really should have used Python 3.x!

For version control I've used SVN and Hg (Mercurial) before, but felt I should try out GitHub, and use that as an excuse to use Git. The repository is at https://github.com/heddmorf/gainstaging for anyone who wants to try out the utility, or laugh at me for the development history!

Once a Test Engineer, always a Test Engineer. I'm naturally drawn towards TDD (Test Driven Development), especially for prototyping. Not only can you clearly see the result your code must be written to produce, but having the test suite first means you know exactly which bits are broken if you go to demo your WIP to someone.

As an added bonus, the doctest tests I write can be used as a Travis CI test suite, with the simple config .travis.yml file:

language: python
script:
  - python -m doctest -v gainstaging.py

Now I can have the comforting "Build: Passing" badge to plaster around.

Regression testing is much easier too. But, your test coverage does need to be at a certain level of coverage to benefit. For instance, I handle going in signal-flow direction by multiplying, and going back up the signal path by dividing gains. When I made multiplying gains together unit-aware, my dividing function stopped working for more than two gains. I didn't have a test for that, so didn't notice this until writing a later function which depended on using the divide function thrice. The time I spent trying to fix the problem in the dependant function when the fault was elsewhere can hardly be called rapid prototyping!

I originally aimed to keep track of all gains and levels within a central object, but having written classes to provide unit-aware levels and gains, I had a little play with it -- I mean performed UX testing, cough -- and found swapping out mic capsules in the simulation etc. was easier if I left the values in the users hands. Provide the tools, rather than straight-jackets!