Those of you who have been keeping abreast of developments in computer‑based music are likely to be only too aware of the problems posed by the Windows and MacOS operating systems. You may also know that an alternative exists — but is it worth making the change? Dave Shapton introduces BeOS.
It seems like years since I first read about a new operating system called BeOS, which ran on Macs and described itself as "The Media Operating System". I had to admit that as recently as a year ago, I still assumed that it was just one of those slightly idiosyncratic startup ideas that would vanish with not so much as a puff of smoke the moment it was given a dose of commercial reality — especially when it was announced that newer G3 and G4 Macs would not run BeOS.
Well, I was wrong. Because not only does it still exist, but it now runs on PCs and — in a quiet way — is generating a lot of excitement in the music business. Only last month, SOS carried a news item about thestudiolab.com, a web site dedicated to BeOS and the musician. If you're a PC user, your first reaction when confronted with BeOS is probably going to be that it makes your PC look like a Mac. With friendly, chunky, almost cuddly icons, 'tracker' in the top right‑hand corner, and disk icons on the desktop, this is clearly a Mac way of doing things.
If you're a Mac user, though, things are as different as they could be (assuming you have a suitable Mac) — not least in the time it takes to boot up. With BeOS, if you turn the computer on before the monitor, chances are that it will have booted to the desktop before the monitor has warmed up!
What follows is not a review of BeOS, but rather an introduction to the philosophy of it. I also want to explain where it fits in with other developments in media‑related computing, and where it might be in a year or so (an eternity in the computer calendar!).
Heavy Loading
BeOS is specifically designed for media applications, so the handling of windows running video, for example, is much less prone to glitching than in Windows.
It's strange how something as clinical as a computer program (because that's what an operating system is) can stir up the emotions. You've only got to look at what can happen if a PC user dares to criticise a Mac, or vice versa. Take the emotion out of it and what you have is a computer and some housekeeping software. In this sense, there's no difference between a PC and a Mac (or any other desktop computing platform you can think of).
If ever there was a task a desktop computer was never designed to do, music is it.
Now I realise you could be forgiven for thinking you've picked up What Impenetrable Software magazine instead of SOS, and I apologise in advance for the fairly technical slant of this article. In mitigation, I'm more of a musician than a programmer, and what I want from a computer is the ability to help me compose and record music in the best possible way. We're talking about operating systems because the OS, as I shall call it from now on, is what gives a computing platform its 'personality', and, ultimately, dictates how well a computer works in a given role.
And, of course, the role we're interested in is music, which just happens to be one of the most demanding applications you could ask of a computer. You could argue that some tasks require more processing power (such as image manipulation) and some call for faster data transfer (video, for example), but I don't think anything demands as much all round from a desktop computer as multitrack audio; expecially when you take into account the complexities of real‑time effects and sample‑accurate synchronisation. If ever there was a task a desktop computer was never designed to do, music is it.
And it's not as if the systems we are currently using help, exactly. I don't want to frighten anyone off at this stage by delving into the scary innards of microprocessors, but to understand the difference between BeOS and other systems we need to look at what's going on inside the box.
In an ideal world, digital media wouldn't be digital. Until digital audio came along, the aim of professional recording engineers was to recreate an analogue signal that was as close as possible to the original. Now, the first thing we do is to sample it. We slice it up into equal chunks and give each one a numerical value. It's about the most destructive thing you could to to a silky‑smooth analogue signal, but we do it in a way that lets us reconstruct the original by reassembling the samples and joining up the dots. The detail we lose is detail that we wouldn't have heard anyway.
This principle works very well with CDs and digital tape recorders, and you'd think it would work with computers as well. But there are several reasons why this isn't necesarily true. For a start, you can't synchronise a computer's master clock to your incoming sample rate. In a digital studio there can only be one master clock, to which every other device in the signal path must lock. Mistakes in this department lead to clicks, or even no signal at all. Given that your average Pentium III processor doesn't have a pin labled 'Audio clock in', we have to go to extraordinary lengths to make a computer work in a digital studio.
If the down side is that the computer can't be synchronised to the audio clock, the up side is that it does at least go very fast. For every audio sample, there are hundreds or even thousands of processor clock cycles. Given a 500MHz processor, there would still be hundreds of clock cycles per sample per channel, even with 48 tracks of audio. But, still, speed doesn't equal synchronisation. However, as long as an audio sample is processed and in the right place before it is needed, it can then be read out of memory at the precise moment that it is needed back in the final digital audio stream. So, provided there is sufficient memory to 'buffer' the audio samples as they are waiting for their place in the audio output stream, then it doesn't matter what clock speed the computer is running at.
So that's OK, then? No, not really, because working around the synchronisation problem — and orchestrating multiple audio streams within a computer — uses up masses of processing resources. Native software processing is cheap, but wasteful. This makes the role of the operating system even more important, and makes it all the more surprising that for conventional operating systems (Windows, MacOS and so on), media processing seems little more than an afterthought.
Perhaps this is not so surprising, though, given the history of personal computers: it's only in the last year or three that real‑time native signal processing has been possible on PCs and Macs. Good audio processing is obviously a number one priority for readers of SOS, but not necessarly for users of spreadsheets, word processors or databases. So while office application suites have more and more obscure features packed in, the programs and operating systems get bigger and easily soak up the extra power available from modern PCs. It's a familiar story, and it's frustrating, because even the slowest computer you can buy today is a processing powerhouse. So why don't our computers do more for media? And why is 'The Computer As Recording Studio In A Box' either an unattainable dream or a simply a nightmare?
BeOS To The Rescue?
Mac users will be instantly comfortable with BeOS's friendly icons and graphical interface.
It's time, then, to have a closer look at BeOS. (If you want to know more about the Interface, Installation or History of BeOS, have a look at the boxes). The overall aim of BeOS is to be a better operating system for dealing with digital media — images, audio and video. Designing an operating system from scratch is never going to be easy. It's a bit like building an aeroplane: you can't test it until it has both wings! But starting from scratch is actually a wonderful opportunity to get things right. First of all, there's no need to support old software, because there isn't any. Contrast this with Windows and its support for DOS, and MacOS with its emulation of 68000‑dependent programs. Support for 'legacy' programs, while obviously valuable, adds complexity and can compromise the design and funcionality of an operating system. In fact, every time you add a new technology to an OS, you have to add another layer to translate between this and emulations of older technologies (Be describe these layers as 'Silt'). The more layers you have, the greater the distance between application programs (such as sequencers and audio editors) and the hardware.
To get round this, and to give you decent audio performance from your computer, your software can do either of two things: it can take liberties with your operating system and 'bypass' it, by talking directly to your hardware, or it can use a technology such as Microsoft's 'DirectX' — which Be disparagingly refers to as 'Chewing Gum'. Bypassing the OS is effective but dangerous: the OS has no way to protect the memory space of programs under its control from programs that aren't, with the inevitable result that the computer crashes. What DirectX does, by contrast, is 'tunnel' through the layers to give application sofware more direct access to the hardware. This is largely successful, but I don't think anyone would claim that it's anything more than a clever workaround, and still less that it never crashes!
BeOS overcomes this using the twin virtues of simplicity and modularity. It's simple in the sense that the kernel (the bit of software at the very core of the operating system) is small and uncomplicated. Its job is to communicate with applications and to allocate processing time between them (we'll deal with this in more detail later). It then has to communicate with the computer hardware. It's because of this that the kernel is the part of the OS that is the most platform specific: it would have to be rewritten to work on another type of processor (this has already happened three times in the history of BeOS).
Most importantly, the kernel ensures that the OS is responsive. What responsiveness means in practice is that, for example, you can run several programs at once, and each of them will respond smoothly, with little dependence on what is happening in other windows. If you try running a 3D animation in a window on a Windows system, you wouldn't expect much else to happen. Try loading another program and everything judders; move the window and the animation stops. This doesn't happen with BeOS. Because of the efficiency (and simplicity) of the scheduler in the kernel, processor time is shared fairly and appropriately between applications that require it. The effect is stunning, because it gives your computer a completely different feel. You can actually play a high‑resolution video in a BeOS window while you are dragging it and resizing it on the desktop! You can even play multiple videos simultaneously (with sound, of course!).
You can actually play a high‑resolution video in a BeOS window while you are dragging it and resizing it on the desktop!
Because the BeOS kernel is so small and responsive, BeOS applications load very quickly, and the system itself boots in what seems like an instant (but is actually about 15‑30 seconds). In keeping with the speed theme, BeOS doesn't have an hourglass!
In a manner consistent with the idea of simplicity, BeOS keeps most functions of the operating system separate from the kernel, and separate from each other. Drivers are loaded dynamically if and only if they are needed. To make maximum use of the modularity, there are communication channels between applications which are effective at programming level or at script level — there is a script language accessible to anyone, which can customise applications and even the behaviour of the user interface. So, for example, errors from a device driver can be passed directly to an appliction for assessment and reporting to a user.
Caring, Sharing BeOS?
BeOS includes a simple web browser.
BeOS is designed with to work with multiple processors — in other words, several processors on the same motherboard. It makes sense. If you take the fastest processor in a product line (let's say a 750MHz Pentium III) and a slightly lesser processor from the same company (say a Celeron 466), the faster chip will cost several hundreds of pounds while the slower one will typically cost less than a hundred — in any case, less than half the cost of the faster one. So it would make sense to use two of the slower ones together, giving you a combined clock‑speed of nearly a Gigahertz. So why don't we do this already? First of all, because Windows and MacOS don't support multiple processors. Load Windows 98 on to a system with a dual‑processor motherboard, and it just ignores one of the processors. Windows NT does support multiple‑processor configurations, but few application programs take advantage of this.
Writing application programs to make full use of multiple processors is an uphill task, and not all programs need it. But think of the benefits if you could assign each of eight audio streams to its own processor. BeOS makes this a lot easier, because is has a feature called Pervasive Multi Threading. Which I won't abbreviate at all.
What's a thread? It's like a small independent part of a program which has a specific task, and — to some extent — can run independently of the rest of the program. For example, the print function of a program could be a thread which could be excecuted on its own, allowing the rest of the program to continue. The more threaded an application program is, the more responsive it will be. There are other advantages as well: since threads have an independent existance, they can be allocated by the kernel to use separate processors, and they can intermingle with threads from other programs, giving smoother multitasking.
Threading is eminently suited to digital media: although there are additional complications with audio because it is sequential by nature and not parallel (in other words, there's no point in using multiple processors if the samples come out in the wrong order), there are no reasons why separate audio channels or streams shouldn't each have their own processor (or share of one). It's because everything in BeOS is threaded that the threading is called 'Pervasive'.
Hand‑in‑hand with Pervasive Multi Threading is Pre‑Emptive Multitasking. Multitasking is what describes the kernel's job of allocating processor time between applications. Try not to confuse it with multi‑processing, because it works on single processors as well. We all multitask. We start doing one thing, get interrupted and do something else, then come back to our original job. If we are good at it we can pick up tasks just where we left them. It's the same with processors. A CPU will execute one program (or thread) until it is told to do something else. With BeOS (and 32‑bit programs running under 32‑bit versions of Windows) it is the kernel that decides this. That's good, because with the type of multitasking found in earlier versions of Windows — called (inappropriately) cooperative multitasking — an application wanting processor time would have to wait until the program currently executing reliquished control of the processor. This would obviously be no good for real‑time media work, because the process would be totally unpredictable. BeOS's multitasking is better than that of Windows' or Mac OS's because of the effectiveness of the sheduler and the fine‑threadedness of the applications and OS.
Saving Graces
Now for the file system. Without going into too much detail, the BeOS file system (that's the equivalent of FAT 32 in Windows, for example) is designed for media work, and for a generally more reliable OS. It has a 64‑bit file structure, which is important, because anyone who has done video editing on a computer will know about the 2Gb file‑size problem. It seems that when technologies like Microsoft's Video For Windows were designed, it was thought inconceivable that anyone would want files bigger than 2Gb. A broadcast‑quality video signal, however, takes up around 23Mb of storage per second, or around 1Gb per minute. Most TV programmes and even music videos are longer than the two minutes the 2Gb file limit would allow. I have recently been asked to figure out a way of storing over 1000 hours of uncompressed video on hard disks! That's 60,000Gb or 60Tb (Terabytes). BeOS's file‑size limit is 18,000 Petabytes — or, in other words, big enough.
Another important feature of the file system is that it uses Journaling. BeOS keeps a record, in real time, of every transaction and operation it carries out. Which means that if, say, you turn the power off without properly shutting the system down, it can reboot almost as fast as if the system was starting up normally. Other operating systems tend to store important data in RAM until it is convenient to write it to disk. This obviously makes such data — and, indeed, the integrity of the whole system — vulnerable in the event of a crash or power loss.
A Choice, Not A Compromise?
You don't necessarily have to treat BeOS as an operating system. Think of it as another program that requires a reboot. Be have engineered BeOS to co‑exist with Windows and don't expect you to give up your investment in conventional Windows applications; many people will partition their hard disk, giving them the option of running either OS at startup.
Plenty of information is available — most of it on the web — about BeOS. I find www.beeurope.com the best starting point as it lists most of the useful links, and has some good white papers. Check out www.beosbible.com as well. This is also the name of a really comprehensive book about the BeOS, by the wonderfully named Scot Hacker, with over 900 pages, which has been helpful to me in preparing this article.
Reviewing an operating system is almost an impossible task because it works at so many levels, from the most intimate crevasses of a computing platform to the culture surrounding it. This is only the briefest of overviews of what is a surprisingly mature and fully featured operating system. I'm left with what I can only describe as a feeling of bewilderment that BeOS exists at all, that it is so good at what it tries to do, and that it is a genuine alternative to the other operating systems we have grown to love and hate. As for the future, it would be foolish to even hazard a guess, but that's never stopped me before, so I think BeOS may just find its way onto a lot of musicians' desktops because of the ease, simplicity and elegance with which it handles audio and video. It will also be the basis of non‑Intel based web‑based appliances (didn't I mention that it comes with an effective, if simple, web browser?) and maybe, just maybe, might become the operating system of your next sampler.
Oh, and I don't know why it's called BeOS either.
Applications
So, you've installed BeOS, figured out what those yellow tabs on top of the windows are for, and have tried running eight video files simultaneously. Now for some real stuff. Where are those amazing audio sequencer packages? Er, there aren't any.
You do get a nice set of demo applications that do fabulous simulations of atomic particles, draw three‑dimensional teapots, play MIDI files and let you grab audio from CDs (from the BeOS media player: it's actually got a 'save as' facility for audio CDs!). There's a demo office suite which is actually very good — but there's no Cubase and no Logic. Yet.
I've heard that these products are being ported — or should I say rewritten — for BeOS, and I don't disbelieve any of it. The prospect is exciting, because I would expect performance to be phenomenal, but don't hold your breath. Meanwhile, there are some genuinely good Be‑native products around, such as IK Multimedia's T‑Racks (see review on page 168), which is a mastering package that emulates valve processing. There are a few video editing packages around that look good for home movies (the next release of BeOS will have a DV codec built‑in, so all you will need to edit DV video is a FireWire card and some editing software) but, basically, there isn't much.
It's really a kind of chicken‑and‑egg situation. If enough people were using BeOS, there would be no question that there would be applications for it. I suggest that the way out of this impasse is to set up a BeOS system anyway. It's fun to play with, you'll boost the sales statistics fed back to the application developers, and you'll be ready for the programs when they come out.
User Interface
Be don't claim that their graphical interface is anything other than another interpretation of the Xerox/Apple/Windows model. That's actually good news, because there isn't much to learn. The most distinctive feature is perhaps the yellow tab at the top of a BeOS window. It's where you click to move the window, and also has the 'close window' and 'maximize/minimize' controls.
The icons have a friendly, welcoming look to them, and the whole thing looks extremely polished — surprisingly so for a product from such a small company. However, since the majority of the design team came from Apple, they ought to know a thing or two about user interface design. What's missing is the equivalent of Windows' Explorer, or any really easy way to look at file organisation system‑wide.
Also part of the interface is a command‑line window, called terminal, which is fun if only because it shows that BeOS is at least distantly related to Unix (programmers may want to note that although it is not officially Posix compliant yet, it is aiming for full conformity within a release or two). The reason I think this is because every Unix command I know is recognised, even the prosaic 'awk' and 'grep'. Be are very specific, though, that BeOS is not a flavour of Unix, but uses a Unix 'shell' for its command‑line interface.
There are some neat touches, like multiple workspaces. The idea is not new but it is well implemented, and is a fundamental part of the user interface. It lets you set out windows on multiple 'virtual' workspaces and switch between them using the function keys. I can see this being useful if you are using a complex application like Cubase and want to have, say, the mixer page on one workspace and an arrange window on another. Workspaces can even have different screen resolutions.
Finally, BeOS's user interface is superbly responsive, in keeping with the philosopy of the operating system. Whatever else is going on, you will always get a response from a mouse click. If an application crashes, you get a nice message telling you that the application has gone wrong and that it will now reset itself. While you watch this happening — annotated by little messages — you can carry on using the user interface as normal. I like that very much indeed.
Platforms & Hardware Compatibility
BeOS is processor‑agnostic, in that, apart from the kernel — which must be rewritten — it can be re‑compiled to run on most platforms. Those currently supported are Intel and Apple Macintosh machines. Sadly, though, this does not include any of Apple's G‑series processors. The problem is simply that Apple won't release the technical specs of their systems that are based on these chips. Maybe it's political (following Apple's decision not to buy BeOS as their future operating system) but for whatever reason, it's a shame.
Still, the good news is that if you want to set up a BeOS system you can do so on a very cheap Intel PC. I'm running BeOS on a 466MHz Celeron that cost my under £500, excluding the monitor, and it's as fast as you could want. For full hardware compatibility you should check out the official BeOS web site, www:beeurope.com.
For a minority operating system, BeOS supports a surprising range of devices. Stick to mainstream soundcards and graphics cards and you shouldn't have too many problems. Of course, it would be great if all our favourite audio interfaces worked, but that isn't yet the case. It may well be worth lobbying the manufacturers to write BeOS drivers, and I'm sure some already are because of the exciting range of BeOS‑native applications just round the corner (see the 'Applications' box on page 146).
History
Jean‑Louis Gasse, founder of Be Inc., left Apple in September 1990 to start work on BeOS. A year later, a prototype computing platform, based on the unpromisingly named AT&T 'Hobbit' microprocessor, was ready. It actually had five chips — two Hobbits and three AT&T DSPs — an early clue to the media orientation of the operating system. BeOS was always intended to be a multi‑processor OS, able to take advantage of multiple low‑power, low‑cost chips. In fact, despite the high chip‑count of the prototypes, the combined cost of their processing power was less than that of the Intel 386s that were around at the time.
To no‑one's great surprise, AT&T ceased production of the Hobbit in 1994. Incredibly, by October 1995, Be were ready to show their first public offering: the PowerPC‑based BeBox. Be were now in a position to move forward by generating public interest in their product.
In 1996 Be was ported to run on the Apple Macintosh platform. Shortly after this, Apple found itself in the position of having to look externally for new technology to base its future operating systems on. Be found that it was not only a contender, but was actually the favourite — right up until the point when Apple chose Steve Jobs' Next Step instead. With hindsight, this was hardly surprising, given Steve Jobs' position at Apple.
The decision not to use BeOS was made by Apple in December 1996. Inititially despondent, the Be team made the decision to create an Intel version of the OS. They had to: if they hadn't made the leap to the Intel universe, BeOS wouldn't have had a platform. Shortly after their decision not to go with BeOS, Apple ended their close technical collaboration wth Be, effectively putting an end to all development on the Apple platform.
Installation
Installation of BeOS is really pretty easy. I can say this with confidence, because I have done it several times. BeOS installation is remarkably straightforward; I would always recommend that you start on a fresh machine, either a new one or one that has just been formatted. It's quite possible to install BeOS alongside an existing Windows installation, but back up your data first.
BeOS auto‑detected all the hardware on my machine: the soundcard, graphics card, network card, and so on. It even found an Epson digital camera I had attached to a serial port and politely asked me if I wanted to download any pictures. An earlier installation attempt had found a graphics card that wasn't supported, and gave me a message to the effect that although it couldn't use the card to its full potential, it would still attempt to use it at a lower resolution, although this would be wasteful of processor cycles.
There is a boot manager that lets you look at the partitions on your hard disk and decide which you want to be active. It's slightly scary stuff, but if you work on a blank hard disk, you've got nothing to lose if you make mistakes. It seems to me that the developers at Be know that the first contact most people will have with their OS is the installation routine, and they have obviously worked very hard to make sure that it works well, and with as little pain as possible.