Wishing you could do more than one thing at a time may be as close as you'll ever get to doing it, but your computer is another story altogether. Harvey P Newquist III explains multitasking and some of its uses.
Almost certainly destined to be the next major step in the evolution of personal computers, multitasking is beginning to come of age.
THINK OF ALL the times during the average day when you would like to be able to do more than one thing at a time. I'm not talking about trying to walk and breathe. I'm talking about something like reading this article while programming your synth, or shagging (dancing, what did you think I meant?) while drinking a yard of ale. Such an ability would certainly make your life easier, and probably earn you a place in the Guinness Book of Records (if not turn you into a contortionist).
Unfortunately we humans are pretty well limited to coping with one task at a time, or "singletasking". Those of us who want to do more than one thing at a time usually end up concluding that there just aren't enough hours in the day - corny, but true.
UP UNTIL RECENTLY, personal computers were coming to the same conclusion. When they were asked to run a word processing program, that's all they could run. If you wanted them to check a name in a database, you had to exit from the word processor, load the database, get the information and return to the word processor. Result? A lot of wasted time, especially with a single-drive machine where disk switching slowed the proceedings still further.
Having spent enough time quitting and booting up programs, you'd be fully justified in wondering why the computer can't get into your database from your word processor without all the hassle. Admittedly, this is the functional equivalent of asking it to play the guitar, do your taxes and make you breakfast all at once - but it is a computer and we're forever being told how wonderful they are, so why shouldn't it be able to do more than one thing at a time?
WELL, ITS NOT an unreasonable request. Large mainframe computers and certain types of scientific and engineering workstations have been able to perform multiple operations simultaneously for many years now. While this doesn't include dancing and drinking, it does cover applications such as inventory control, managing mail lists, payroll programs, report generation, and a gamut of other programs we normally think of as being part of complex systems. The ability to perform separate tasks at the same time is known as "multitasking".
This is fine for the DVLC at Swansea, but what about the rest of us with more modest computers who want to compose, sequence and perform our musical masterpieces simultaneously? Well, the humble micro is finally beginning to catch up with those of you adventurous enough to contemplate this sort of multitasking.
With the introduction of PCs in the early 1980s, people were fairly happy to have a machine with one disk drive and 64K of RAM. In those days, PC hackers felt that if their computers had just a little more memory - say 256K - then they could create programs to do just about anything. Yet, as quickly as more memory became available, programs kept growing in size to eat it up. Where once you could run a spreadsheet comfortably in 64K, you now need at least 512K to operate today's equivalents. Applications themselves became more complex and left little time or memory space to consider running more than one program at a time. Multitasking was put on hold.
In 1985, Commodore introduced the Amiga 1000, the first true multitasking microcomputer. The machine was outfitted with custom processors to handle graphics and the like, freeing computing power to allow handling of several programs running simultaneously. Though the business world did not flock to the machine, much of the entertainment and graphics industries found the answer to unlocking stifled creativity through the Amiga's design. It quickly won friends that the less powerful Apples (of the time) had failed to win and that the uninteresting IBM PCs and clones had ignored.
In time, though, the demand for multitasking permeated the hallowed halls of the PC vendors. This was coupled with pleas for faster processors and greater graphics-handling capabilities until, in 1987, both IBM and Apple revealed plans to appease the multiple-tasked masses. IBM introduced its PS/2 (Personal System 2) microcomputers, based on the Intel 80386 processor - which replaced its slower predecessors, the 8086, 8088, and 80286. The 80386 was designed first and foremost to improve graphics handling within IBM PCs, as well as to start addressing some of the requirements of multitasking.
On the Apple side, the company incorporated Motorola's 68020 chip into its Macintosh II. The 68020 was already noted for being the core of the successful Sun Microsystem workstations, which are used for everything from artificial intelligence to 3-D model simulation to stock monitoring. Beyond that, Apple realised the importance of multitasking for the Mac II, and gave it a complete interface environment known as MultiFinder. The Finder is the Mac's basic application management program. It allows you to access and control all your applications and documents, as well as moving information to and from your disks. MultiFinder, however, allows you to nip in and out of separate applications that are open simultaneously so that you can do such things as spreadsheet calculations while you're typing your Christmas mail list.
The basic idea behind MultiFinder is that it allows you to do "background processing" (providing the programs in RAM can support this). In other words, one program will run in the background while another is available to be worked on in the foreground. The switching capabilities of a program like Switcher are different. In that case, you simply jump from one program to the next - they won't work simultaneously.
Another problem with MultiFinder, and one that pervades all areas of micro multitasking, is the fact that it requires a great deal of RAM. No, 512K won't do, and in practicality, neither will 1Meg. You need at least 2Meg of RAM to operate MultiFinder, simply so that the program can control all simultaneous applications with room to spare in random access memory. Anything less than this causes MultiFinder to slow down considerably - and for good reason. It's much easier to service those programs if they're all held in the computer's memory at the same time. If they're not, and if the user (that's you) suddenly switches to one that's not held in memory, the computer has to take time out to boot it up and run it.
Another problem shared by all multitasking systems is having enough power to perform as if all programs are being serviced all the time. In reality, most microprocessors can only deal with one thing at a time too, so they feign omniscience by being extremely fast. Extra memory helps a microprocessor keep its place in all the relevant programs.
Think of this as being similar to a pop star at a press conference. One person has to respond to questions from 50 members of the press, all of whom want his or her attention at the same time. They each scramble to make themselves heard, so that they can get their answers taken care of before any of the other reporters (or even at all). So they verbally assault our pop star simultaneously. But like the rest of us humans, and contrary to popular opinion, our besieged pop star is only capable of singletasking, and therefore can answer only one question at a time. In the meantime, the remaining reporters have to wait, ready to take his or her attention at the first available free moment. For this reason the press conference lasts until everyone is satisfied - much longer than a one-on-one interview. Had our pop star been capable of transparent multitasking, he or she could have answered everyone's question at once. An important point to be aware of is that a lot of time gets wasted in the process of vying over who gets the next question in (a little like you swapping disks, or the computer swapping things in and out of memory).
"One problem shared by all multitasking systems is having enough power to perform as if ail programs are being serviced all the time."
A microcomputer's processor faces the same dilemma. In order to accomplish much of anything, it has to take all applications in their turn. In multitasking, the processor takes pieces of each application at once, spits them out, repeats the process with the next set of incoming data, and does so quickly enough that each application thinks it's the only one getting serviced. Put our pop star in the middle of a circle of reporters and have each of them ask their questions very slowly while he/she spins in a circle, catching all their words almost simultaneously (because he/she's moving faster than they are speaking). Granted, he/she'd have to have a huge memory to be able to handle and partition each of the words from each reporter (and be able to spin really fast), but that's the general idea. The processor takes information in and spits it out so quickly that no single one of the applications appears to be being neglected.
The time between servicing applications may be only a matter of milliseconds, but now we're going to talk music specifics, and in some cases, a few milliseconds is a delay worse than an eternal death.
WHEN USING MIDI in conjunction with micros (which is about the only way we can currently get computers to make music), there are already inherent time dilemmas. Without getting too heavily into the MIDI spec as it exists now, suffice it to say that data transmission between PCs, MIDI software and MIDI instruments is not always in real time, especially when you've got a lot of things going on simultaneously. This is regardless of multitasking; a single MIDI operation can bog down a system based on its complexity, length, and type of information. But we'd still like to take advantage of multitasking by sequencing one piece at the same time that we're printing the score to our latest Top 40 single. How is our processor going to cope without resorting to a life of word processing and antiquated video games?
First of all, this depends to a large extent on the processor. Older processors will simply lie down and beg for mercy. But, as I mentioned earlier, the most recent microprocessors are fast enough to handle almost any sort of multitasking operation thrown at them. But even this is a source of contention in the music software community. Hybrid Arts, for example, claim that there currently isn't a true multitasking microcomputer environment for music software that meets their standards of rhythmic integrity. This is due to the fact that as the processor works on each part of different programs (say the sequencing and scoring), it might be involved with the printing of a measure at the moment a critical MIDI time instruction appears. Even though only a fraction of a millisecond may elapse before the processor gets back to the sequencer, the piece of music may slow down or slip slightly out of sync. Suddenly you have a musical composition which has the slightest glitch (which may seem like a flaw as large as Birmingham to the composer) because the processor was "busy" performing another task at the critical moment. Other companies argue that this is a software programming problem and that the processor can be managed to do anything given the proper coded instructions.
To be fair, in an isolated example like this one, the glitch probably wouldn't occur with only two programs running simultaneously. But the concept of multitasking necessarily involves having half-a-dozen or more programs ready to run at any given time if you so wish, and this is where the processor and the programs run into trouble. Logically, it gets tougher as you add more numbers to the process.
Another more insidious problem is that of sharing resources. Several programs running at once may all want data from the same MIDI In port, send data out the same MIDI Out port, and want timing information from the same clock inside. And they want to do this without competing with the other programs running.
THERE ARE PRESENTLY several "shell" or "switcher" programs on the market. These are programs that manage a number of other programs concurrently resident within computer memory. Hybrid Arts have one called HybriSwitch for the Atari ST (which sells for $29 in the States, and is due in Britain shortly). This allows you to partition RAM so that your programs are floating around in active memory waiting to be utilised without taking up processor and hard memory time. This is done at the outset of the operations so that RAM is handled more efficiently. Most programs when loaded will soak up as much memory as they can - like a vampire in a blood bank. HybriSwitch allows you to limit the applications to the amount of memory you deem necessary to keep them functioning properly (although they obviously have a minimum requirement to run at all). Hybrid Arts are seeking third-party support from other ST software developers so that a number of manufacturers' programs can be used within this type of multitasking environment.
This brings us to another aspect of multitasking: that of different developers' software. Mimetics developed a set of modules for the Amiga that ran simultaneously, and had MIDI data piped from module to module. They eventually published their interface spec - but no one adopted it. Dr Ts have their MPE (Multi-Program Environment) along with KCS 1.6 (Keyboard Controlled Sequencer) which also takes advantage of the full multitasking capabilities of the Amiga. But the program shares tasks among other Dr Ts packages, not with software from other manufacturers.
MPE is also available for the Atari ST computers, where it assumes a slightly different form. Instead of multitasking, it employs a technique known as "nesting" or "multi-nesting". Here applications sharing the same MIDI data can be run together, so, if you're running a sequencing program that uses a specific format for structuring information about tracks, with a scoring program that uses the same track format, then the two applications can share the same structure for their operation, instead of having separate structures. This cuts down on having to store a diverse set of instructions for two fairly similar functions. You can also do things like record system exclusive information, created while editing a synth patch with a patch editor, into a sequencing program. (Read it again, slowly...) The problem with nesting is that it's often developer-specific, rather like a MIDI exclusive command. Unless your sequencer, scoring program, patch editors and whatnot have similar data and file structures, you're going to be out of luck. Then you'll have to resort to true multitasking.
In that realm, developers of Macintosh software are trying to make sure their packages work within the MultiFinder environment. Already, MasterTracks Pro from Passport Designs reckons to take full advantage of the Mac's multitasking abilities by being "MultiFinder compatible", and other programs are certain to follow in the very near future.
Also in the Mac world, Opcode Systems and Digidesign are working on a utility called MIDI Share which is a small program that grabs the Mac's internal clock and serial ports and directs the desired information to and from the programs that want it. Eventually this will mean something like having a sequencer and an automation program run simultaneously. Southworth Systems are independently working on a similar idea.
In the IBM camp, DeskView is supposed to help speed those micros in the process of multitasking, but very few packages anywhere in the MS-DOS world are designed to optimise this capability.
WHILE TRUE MICRO multitasking is creeping in by degrees, once it arrives there'll be no turning back. In the near future, any micro incapable of multitasking will go the way of the stegosaurus, or at least the manual typewriter. It may not be too long before dancing and drinking are reconciled.
Feature by Harvey Newquist
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!