MusicRadar

Bugs are an endless source of frustration. (© Creasource/Corbis)

View in gallery

When you buy a washing machine, it's unlikely that it'll turn itself off half way through the first spin cycle – you'd be straight onto the retailer for a refund or replacement if it did. And when you plug in a new TV, you can be pretty confident that it won't change channel unless you instruct it to do so.

Sadly, though, music software isn't quite so predictable. In fact, most of us are pleasantly surprised when we install a new application or plug-in and it does work exactly as it should.

It's not entirely clear who coined the term 'bug' in relation to problems with software – it's often attributed to engineers who found a fried moth playing havoc with the circuitry of an old valve computer, but the usage of this word to denote malfunctions in electronic and mechanical devices predates this. What's more important, though, is that we establish precisely what bugs are.

Does not compute

Angus Baigent sums things up pretty succinctly: "A bug is when a part of the program is not working as intended. That can result in some kind of anomaly, which might take the form of a crash or some other problem."

This draws attention to the fact that some bugs are more serious than others, and that they can manifest themselves in all manner of ways

"Regarding categories of bugs, there are many classes," says Cakewalk CTO Noel Borthwick. "Some can be subtle, such as a glitch that doesn't properly redraw the screen. Others can be an undesirable interaction of one or more features, or can even be data- or project-related. System crashes can be more obvious, since they cause program execution to halt and, potentially, lead to loss of work (less serious these days, since our applications support crash recovery)."

"A customer can easily blame the software for any old problem – to be fair, we've all done it, haven't we?" Angus Baigent, Steinberg

This gives us an idea of how developers define bugs, but is it true to say that some of the niggles that seem to be caused by certain programs are actually due to conflicts elsewhere within the system?

"One of the things about software engineering that can be very difficult is reproducing a certain type of behaviour and isolating the cause," says Angus Baigent. "A customer can easily blame the software for any old problem – to be fair, we've all done it, haven't we? However, in an audio system with a DAW, audio card, plug-ins, customised hardware configuration, etc, there are myriad issues that can occur. One of the huge challenges in engineering a host application with the sheer scope and complexity of Cubase is that it forms the basis for an environment, and needs to work with many other technologies and products."

Friedemann Schautz, who takes responsibility for quality assurance and testing at Ableton, has a similar story to tell.

"Bugs that involve components from different vendors are typically harder to fix than bugs in a single component. But still they are bugs that can be addressed. The most crucial point is usually to get enough information about the issues so that they can be reproduced in a development environment."

It's certainly unreasonable to expect that developers test their software on every possible system configuration – it would be unfeasible, if not impossible – and this goes some way to explaining why bugs are, unfortunately, part and parcel of the computer music experience. What's more, as u-he's Urs Heckmann points out, programmers can only make educated guesses as to how their products will be used.

"It's often hard for a developer to foresee all the things that users do with the software," says Urs. "Sometimes one is baffled when, for instance, an artist wants to play a single note on a synthesiser for three days and complains that the LFO goes out of sync by a millisecond."

Around the web: