2005-01-23 OBB's Postmortem

If you went to the OBB's website recently, you probably haven't noticed anything new. OBB went from nothing to 0.7 (the last release with major features added) in a relatively short time span: ~6 months. The fact that we couldn't come up with any new stuff in over a year should be seen at the confirmation that the project is dead. After a few beers with Vince, we came to the conclusion that we probably wont come up with new features and that it was time move from OBB to something else. Let's take a moment to see what was good and what was wrong with OBB.

A long time ago, Vince suggested that we code a beat box for GNU/Linux. I had never used a drum machine before but I knew how to make custom graphics dance on the screen so I was convinced that I could make something that looked nice. It took us some time to get started, we wanted to see what technology was available. I didn't want to do raw input management with SDL but I didn't want ugly rectangular widgets like in all the hi-level toolkits either. The goals were:

  • portability
  • impressive GUI
  • plug-in type sound-effects

Looking at successful drum machines, that seemed like the key to success. We needed to be portable because our target platform was GUN/Linux but there was almost no audio-tools for GNU/Linux back then so we needed to attract audio artists on what ever platform they were using. We needed impressive GUI: there was no drum machine out there with a plain GUI. I don't know why, technically a plain GUI would eat up less CPU cycles and free resources to make more sound effects. Who cares if your tools are ugly, we wont see them on the CD. Ok, thats not entirely true, trackers are popular and extremely ugly. Finally, we needed plug-ins for sound effects. I'm not too why sure why either but that was a common feature of popular drum machines.

For maximal portability, we went for Python, Qt and CSound. If you've ever spent 20 minutes looking at a compiler output just to test some basic feature you added, you know why we went for Python. It is also really painful have a build system to work on both Windows and GNU/Linux though Qt helps a lot. Qt provides all the input support and let you do all the drawing by hand if you don't want to use the QWidgets. CSound is a really powerful batch file synthesizer. That setup is optimal for rapid application development, the plan was to show an array of pretty buttons, read their on/off state, write batch file to disk, call CSound and write the result to /dev/audio.

I think that we spent more time on the website that it took to come up with 0.1. One thing that is sure is that I spend a lot more time in the Gimp than on the code. Impressive GUIs are not developer friendly. OBB 0.1 would heat 40% of the CPU so we had to optimize some stuff before we could go any further. I rewrote the whole redrawing code many times. Python is fast enough most of the time but it's integer performance is bad and psycho was not enough. When you have only rectangular widgets, you can computed the bounding box of the region to redraw with only two point. OBB has arbitrarily shaped widgets, you can't easily compute what is hidden by other widgets, you have to redraw all the widget stack in a region when it's invalidated. With lots of shortcuts and caching, the bottle neck of the redrawing was not OBB anymore, it was X. It seems that X doesn't like to have arbitrarily shaped windows. So keeping the drawing fast meant to have as less animation as possible, which is no good for an impressive GUI if you ask me.

CSound too is slow. If you try to sequence a few samples, it's fast but if you add effects, it's really slow. That, we could not know until we add the effects support. Our solution was to pre-compute some samples with the effects in and only ask CSound to sequence those. That lead to some really unintuitive user interface. When playing with the panning bar, we didn't wanted to compute a panned sample until we knew the final panning so it had no effects until the user release the mouse button. Then you would see the label stop scrolling for a split second and the beat continued with the new panning. To support effect properly we would have to drop CSound or to do some massive hack. Ok I don't know too much about the sound part so I'll let Vince elaborate further in his postmortem.

Then Trolltech, the maker of Qt, decided to stop producing a non-commercial version of Qt on Windows. That would mean no more portability. Yes, we could live without portability, sound effect and animations but that would put us quite fare from our initial goal. When we realized that we needed from massive re-write, well it never came. The fact that neither of us used a beat box before is a bit telling too. We were looking for a nice project but that one wasn't particularly scratching an itch of ours.

So to summarize, you should code something that you plan to use, it will help usability a lot. You should use whatever technology that will let you put together a working prototype as fast as possible. Once you have your working prototype, you have to be really critical. Is the technology up to the task ? Really ? Do you need to review the features priorities ? Custom GUIs are really nice to look at but not so nice to use an really painful to maintain. Think about it before you commit to a particular design. And finally, if you are not happy with your prototype and plan to move to something else, make it clear so people won't be refreshing your website waiting for the next release. Hence this postmortem. You have plenty of choice now if you want a drum machine on GNU/Linux. Wired looks great and is coded by people who cares about music and Hydrogen is quite usable and has a really good documentation. Now let me play with my fractals!


Copyright © 2001-2005 Yannick Gingras <ygingras@ygingras.net>

You can use my public key to send me secure transmissions.

Valid XHTML 1.0! Valid CSS!