When started writing what became io 0.0.1 beta in ’99, having thrown out a whole bunch of old material, I made an effort to write elegant code. This was partly because of the complexity of this project (which would end up in the region of 25,000 lines of code), but also a reaction to the tools that, as apprentice computer music artist-engineers, we’d inherited in the late ’90s which sacrificed conceptual and theoretical elegance for expediency or to the dogma of ‘ease-of-use’.

io was written in HMSL (Hierarchical Music Specification Language) which was, despite everything, a significantly more elegant (and conceptually more robust) system than many of the other interactive real-time computer music system at the time. Still, much of HMSL dates back to the second-half of the 1980s, and in order to get the system to run on extremely modest environments (say, the Mac Plus) the designers had to make many compromises. As Phil Burk later told me, one of the side effects of this was, for example, the uneasy mix of traditional Forth code and object-oriented programming.

However, when it came to writing io, if there was a conflict between elegance and speed, I would generally err on the side of elegance; attempting to write code that would be easy to maintain and extend (and I would, on occasion, rewrite some of HMSL’s core modules).

However, when I shifted io from scaled fixed point to floating point code in 2004, I ran into major obstacles. The processor (a sans-FPU 33MHz 68LC040 which I guesstimate does around 30MIPS) began to creak, and to prevent the system from falling-behind, I hand optimized code and sacrificed a degree of elegance to speed.

io 0.0.1 beta++, which may be significantly more expensive computationally than io 0.0.1 beta, will still run on this antiquated 68k machine. Thus, I’ll have to deal with many of the issues, and make some of the compromises, that Phil and the others dealt with in the late 80’s….