MULTITASKING ON THE ST

PART II

The MIDI Imperative

BY JIM PIERSON-PERRY

Last issue, Jim Pierson-Perry discussed multitasking TOS and the existing multi-application systems for the ST. Part II of this special two-part series presents a sneak preview of Atari Corp.'s controversial MIDI-Tasking, and the problems of getting it out the door.

Atari Corp.'s recently announced plan to support a multitasking environment called MIDI-Tasking has generally been met with enthusiasm, particularly from MIDI users. MIDI applications thrive on immediate, real-time interaction with other applications and a multitasking environment with across-the-board compatibility presents a clear solution.

Atari decided such an environment had to follow three criteria: it must be GEM compatible, it must adapt to existing software and it must run without being tied to a specific parent application.

After several months of considerable evaluation and negotiation, Atari gave the nod to Intelligent Music's ST RAM, one of several independently produced systems existing in the music field. Atari announced their choice at the National Association of Musical Merchants trade show in Anaheim, Calif., last January. Beta versions were offered to all interested MIDI developers at that time.

But Don't Call It Multi tasking

Controversy has raged over MIDI-Tasking's practical value to the Atari community at large. Comments, quotes, retractions and position statements from Atari officials and developers have enlivened the major online services and caused general confusion. Is MIDI-Tasking a general multitasking solution for the ST? Or is it an application for MIDI users only?

The answer to both questions is yes and no. According to Frank Foster, Atari director of specialty markets and point man for the MIDI-Tasking project, Atari does not have an official multitasking system for ST/ Mega computers. "We have a system that has been put together for MIDI power users that happens to have as part of it a limited multitasking shell, but that's not the emphasis of it. MIDI-Tasking came from MIDI developers who had been actively pursuing multi-application manager/operating-system enhancements. The thrust was MIDI, rather than a general user need."

As to whether Atari will ever support a general multitasking environment for the ST, Foster answered, "Atari doesn't feel that multitasking can be properly done on a 68000-based system. All such systems are kludges. Those looking for official multitasking will have to wait for the TT. [Atari] does not want to do multitasking without hardware support." (Editor's Note: According to John Townsend, Atari's online representative, the TT does not multitask in TOS mode and it would take a major research-and-development effort on Atari's part to make it happen. No MIDI applications exist yet that can run under the TT's Unix mode.)

Questioned about Atari's policy in view of an existing multitasking system such as Beckmeyer's Micro RTX/MT C-shell, Foster dismissed it as one that "[works] but not very well".

Eric Ameres, a programmer for Intelligent Music and codeveloper of MIDI-Tasking, disagrees with Atari. "MIDI-Tasking is a definite multitasking solution. It does the same multitasking that [Apple's] Multifinder or Microsoft Windows does. Plus, it offers the ability to put time-critical multitasking in, as opposed to just interface-level multitasking which Multifinder does. Well-written GEM applications that aren't doing a lot of weird hardware stuff should work fairly easily and require the least amount of fiddling."

The last point is crucial. Not many applications (MIDI or otherwise) work "out of the box" with MIDI-Tasking. The system is still in beta stage and open to suggestions from interested developers. But what constitutes a "well-written GEM program" is still a question. Atari's less-than-stellar developer's-kit documentation contributes to the problem, along with a profusion of new hardware and multiple generations of current products, components and system software.

Figure 1. A graphic display called from MIDI Tasking's shell program shows where and how memory is used among the system and active programs.

A House Divided

The schism between MIDI-exclusive and general multitasking has deep roots in internal Atari politics. An unfortunate side effect has been broken promises and limited access to the equipment and information necessary for a bulletproof multiapplication environment. Intelligent Music's own involvement with MIDI-Tasking played a part in their recent decision to get out of the software business. According to Ameres the project was never intended to be costly, but later became so. "We hadn't received any support. We had been codeveloping a product with Atari, footing all the bills and doing everything for a product that was not bringing any money in the door for us."

Despite limited past support from Atari, Intelligent Music continues to staff the MIDI-Tasking project and is working aggressively to keep the project alive. An updated beta version is ready and awaiting a move from Atari before its release. Support from other MIDI developers, slow at first, has grown, particularly after they've seen that many of their current proprietary schemes can coexist under MIDI-Tasking.

Inside MIDI-Tasking

So just what is MIDI-Tasking and how do you use it?

MIDI-Tasking is an extension of GEM. Multiple applications communicate through the internal desk-accessory pipeline. Memory permitting, MIDI-Tasking can support up to six applications simultaneously (which corresponds to the maximum of six desk accessories that GEM supports). The current beta version only provides for two. Desk accessories may still be present, up to the limit of six. All non-MIDI desk accessories I tried worked fine with the beta version, as did auxiliary programs such as G+Plus, Universal Item Selector II, RAM disks, etc.

Current hardware drivers support the MIDI In/Out and RS232 ports. The latter is provided only with a special version of Intelligent Music's RealTime sequencer.

You can detach MIDI functions from the GEM manager if you want to run non-MIDI applications. The shell program lets you launch multiple programs individually, manage memory allotments and save a set of applications to automatically load and run on startup. MIDI-Tasking can automatically assign memory to each program or you can assign it manually. A graphic display called from the shell program ( Figure 1) shows where and how memory is used among the system and active programs.

Specifically MIDI

For the MIDI programmer, MIDI-Tasking brings a host of centralized functions (currently 43) that are similar to standard BIOS and XBIOS operating-system calls. The main features are control of the MIDI data stream between applications and hardware devices, the ability to synchronize with internal or external timing sources, and simultaneous support of four software timers with different time bases.

Figure 2: MIDI-Tasking has handles for the MIDI In, MIDI Out and three RS232 MIDI Outs (for an external multiple MIDI Out device), along with RealTime and general TOS applications.

Under standard GEM, MIDI operations occur on the same level as user-interface actions, which results in such unacceptable situations as a mouse-click taking precedence over playing a note. To get around this, many developers supplant existing GEM routines with their own optimized code. Under MIDI-Tasking, MIDI data are played in the background under interrupt control; user-interface actions can't get in the way. Programmers can be as fancy as they want without compromising critical timing factors.

All hardware devices, as well as properly written applications, have unique handles within MIDI-Tasking that let you route MIDI data. This is easily done through a patchbay window, mapping sources to destinations just like internal MIDI chords. Figure 2 shows handles for the MIDI In, MIDI Out and three RS232 MIDI Outs (for an external multiple MIDI-Out device), along with RealTime and general TOS applications.

MIDI-Tasking provides a range of internal hardware clock resolutions to control how often interrupts occur. The nominal value is 1066.7 Hz, roughly one-millisecond intervals (compare that with the default GEM clock resolution of 50 Hz). SMPTE applications work better with a 2400 Hz resolution. At the upper limit of 3200 Hz you'll notice some system slowdown. Four software timers, derived from the hardware clock, provide different time bases for applications to use as needed: 768 ppqn, 960 ppqn, SMPTE and millisecond. Even if you use a (relatively) slow hardware clock resolution, you can maintain software-timer accuracy by interpolation.

That MIDI-Tasking provides centralized timing control is critical. Under standard GEM there is a single hardware clock for applications. A typical sequencer program contains specialized code that is called every clock beat. But if you run two sequencers together, both get confused and step on each other. Under MIDI-Tasking multiple clocks work concurrently.

Figure 3: PageStream and Master Plan happily co-exist under MIDI-Tasking.

Non MIDI Uses

With MIDI-Tasking installed, you'll see multiple programs run at the same time, each in its own window. This is what is known as "round-robin" multitasking. Though you work in only one window at a time, all windows receive the processor's time to keep applications steadily running (although the screen displays in unselected windows don't get updated).

Non-MIDI programs work the same way as MIDI programs. In Figure 3 PageStream and Master Plan happily co-exist. To switch between programs. either select an appropriate window or choose a program from the GEM shell-manager menu.

You cannot route non-MIDI data through the patchbay but you can exchange information through a system scrapbook. As applications get upgraded to use this feature, you should be able to cut/copy/paste between applications as you can already do with Multifinder on the Macintosh.

Going Forward

MIDI-Tasking is currently under heavy beta testing, as much to explore its capabilities as for developers to determine what changes will make their programs compatible. As you might expect, few programs run with little trouble--mostly due to problems with GEM. A demo version of the RealTime sequencer provided with the MIDI-Tasking package ran fine, as do more recent Dr. T's' programs. All other MIDI applications I tested bombed.

Response from MIDI developers is good, particularly in the United States. The German giants C-Lab and Steinberg/Jones have invested considerable effort in their proprietary multi-application systems and are more interested in getting their systems to work under MIDI-Tasking than to make individual programs compatible.

The next step is for MIDI applications to dial into the MIDI-Tasking functions and provide handles for inter-program communication. Additional hardware drivers are needed for existing interface boxes. After that, who knows? I'd like to see patchbay extensions to support realtime data manipulation such as filtering, rechanneling and controller remapping. A screen keyboard/controller to input MIDI data from your computer into ongoing applications would also be very nice.

The bottom line, however, is that Atari must get MIDI-Tasking out in a timely fashion and support it for developers. MIDI-Tasking cannot be treated as a luxury--it is rapidly becoming a question of survival in the only market niche where Atari has any dominance. Apple has already released a similar system called MIDI Manager that runs in concert with Multifinder and provides similar if not greater capabilities than MIDI-Tasking. While Apple has not taken an aggressive run at the MIDI market, they have the necessary system in place, support of Macintosh MIDI developers and Multifinder for non-MIDI needs. More importantly, Apple has taken a pro-active position to enforce compatibility among developers--an example of leadership that Atari needs to adopt. Atari must act and act now.

Jim Pierson-Perry is a chemical engineer, part-time musician and a registered Atari developer who lives in Elkton, Md. He is also START's MIDI/Music Editor.