< email > home

Me

[myself] [and i]

My name's Tim Baverstock. I'm 33 at the time of writing, I'm a programmer and a Christian, I like sci-fi and singing, and I have no sense of dress. I go to the gymn once a week, I commute by cycling, and at some stage I'll find someone to shack up with forever.

I escaped from servitude in Bolton to beautiful Cambridge, working for EDS/Unigraphics IMAN/iMAN/iMan/i-man (except we're not supposed to call it that any more - we're Unigraphics Solutions Ltd, a Wholly Owned Subsiduary of EDS :). Whoops, 'EDS PLM Solutions' following the merger with SDRC (Metaphase/Ideas). Or perhaps we're TeamCentre Engineering. Or rather, TeamCenter, 'cos it's an American company and they spell things incorrectly. At least MMM didn't rename itself every six months.

I still hope to emigrate to Canada, but even 2005's looking unlikely now, with my mortgage and that.

At UG, I started re-engineering the ClearCase environment, with the objective of all but obsoleting my role in that field and resuming as a normal software developer. Sadly, it looks like our clients want NT support, although why they feel the need to run flakey software is beyond me. Some day, managers will know enough about software not to buy from disreputable and untrustworthy houses.

I did that for the first three years. I eventually made some progress, once the NTs decided not to misbehave as rampantly as they were (although we did discover an obscure Microsoft bug: we have some C-code header files which we've been calling .pif files for a long time. Microsoft's File Explorer thinks it knows what .pif files are, reads inside, gets confused, and instead of just saying that it's a corrupt file and ignoring it, it sucks in up to 100% of the CPU resource to try and decode the file properly, making the machine unusable. So much for quality software.)

Anyway, I all but completed renovating the build system from an enormous, unmaintainable monolithic makefile into a hierarchical system which runs twice as quickly (despite `Recursive Make Considered Harmful' - monolithic incomprehensible Make which takes minutes to start building considered even more harmful). Next comes getting that working on NT (which should be relatively easy), then doing various things to make some internal APIs more rigorously enforced.

Now I'm a real C++ developer again (yay), and we've just (2002) started using STL (gasp), but there's no point in using exceptions in the core because the code's so old that retrofitting would just make things more confusing. New (2001) bits of code are using exceptions, but I'm not in them yet. Hopefully, I can avoid contamination from the more baroque bits of Java certain now-absent so-called developers hacked together.

So I've completed a couple of unexpectedly pivotal projects in C++ - a system comparing structured parts lists and one to export selected sections of the parts lists in various different file formats. Plenty of OO used, and rather enjoyable, but the company still needs Perl scripting, and without careful coding, Perl can become completely unreadable. I'd far rather write the code myself than be asked to maintain something someone completely inexperienced had written (without being given the time to tidy the code up). So I seem to be drifting back towards tools work.

My previous job with Multi Media Machine involved C++ multimedia programming and Perl-based CGI scripting.

The code I remain most pleased with constitutes MMM's Kwizoke Plus karaoke system. (But please don't ask me for files, CDs, or how to hack the security: I'm not even in touch with MMM any more.)

I took the project over from MMM's former developer when it was essentially a desktop MIDI player, and developed it to saleable quality.

I had the fun of specifying, designing, and implementing a proprietory CD-ROM filing system (theoretically capable of storing up to 20,000 titles, over 5000 when I last checked) because Amiga's own CD-ROM filing system was unreliable. This offered a measure of protection against pirating, futher improved by a separate hardware dongle.

I managed to explain to the computer how to automatically format the plain lyrics in real-time, both in timing and position on the screen: how to place the lines a useful and natural moment before they were due, and particularly how to jiggle the positioning and timing of display/removal if the preceeding set of lyrics were still onscreen. I was particularly pleased with it because I managed to codify the requirements into algebraic form, encode them in C, and have the thing working beautifully with minimal tinkering.

My main regrets are that I didn't manage to encode a `bouncing ball', and that I never tracked down the bug which made the top line of seven unusable, and caused it to hang if a line of lyrics which resolved into four screen lines was followed by a line which resolved into three screen lines (or perhaps the other way around). It would almost be worth offering to fix that for them, except that programming the Amiga brings me out in a rash.

I found it quite funny that MMM's main competitors' (SunFly's) later karaoke CDs (based on CD-G technology) appeared to have adopted the style of my algorithm's lyric timing, even though their original method had the advantage over mine of showing how quickly a word or syllable was supposed to be sung. (I never found out whether it was imitation or just new software of their own, but it looked suspiciously similar.)

Most of the CGI systems were based on a single pre-sorted ASCII records system with various configuration files for the presentation and data. Amongst the systems I wrote were Bolton Library's Database and the company's old CD ROM catalogue and shopping basket. I'd use a database now, obviously. I also wrote an email-based update system for the CPSA's rankings table.

< email > home