I got a phone call the other day from a programmer who works for one of the major music hardware manufacturers. The enquiry centred on converting a program from the Atari ST to the Apple Macintosh. Whereas the trend for computer games has always been for titles to be released across several formats simultaneously, the much smaller market for music software often means a long wait. It has taken several years for Steinberg to transfer Cubase from its ST roots across to the Mac, and most recently Windows on the PC, whilst Emagic's Notator Logic currently offers two somewhat 'out-of-step' versions on the ST and Mac.
Recession, however, forces change. PG Music's Band-in-a-Box program is available for all music computer formats (ST, Mac, PC and Amiga) and Dr.T have products for most computer platforms as well. These exceptions will become the norm as the polarization of music computers begins to blur away from the ST. Cheap Macs, cheaper Amigas and the rise of the PC/Windows 3.1 all mean that the Atari Falcon will be just another music computer, instead of becoming the '90s equivalent of the Atari ST 'industry standard music computer' that we had in the late '80s.
So, conversion from one platform to another makes sense from a marketing point of view, but it may be viewed differently by programmers... But should it? The key lies in how you write the software in the first place. If it is designed from the start to work on more than one computer platform, then customising the individual versions is much easier. Microsoft now claim that about 80% of the code for their major products on the PC and Mac (Word, Excel, PowerPoint, etc.) is common. Writing the core of your software once also allows you to concentrate on getting it right, and the same probably applies to the interfacing routines for the versions. Such an approach is not restricted to large corporations like Microsoft — there are several software publishers who offer programming environments where the interfacing is already written, and all you need to do is write the core, although these tend to concentrate on PC, Macintosh, NeXT and OSF/Motif platforms. (Outside of the music business, the Atari ST is not quite in the same league as these in terms of popularity, so the ST loses out)
Actually, the way that Graphical User Interfaces (GUIs) like Windows, Gem and the Mac work is very similar. The names change, and some of the operations change slightly, but the nature of a GUI forces a way of working that is surprisingly similar across all computer platforms. The underlying approach is very different from the way most people think a computer works. Take this 'traditional' program:
FOR a = 1 TO 10
Here the program appears to be in control. It tells the computer to assign the values from 1 to 10 to a variable called 'a', and thus to print out the string "Hello" 10 times. This fits in nicely with the computer-as-tool, person-as-operator view of things.
With most GUIs things work rather differently. First, the program spends most of its time waiting for messages from the computer, and when it receives a message, it does whatever is required and then goes back to waiting. For example, when you select a menu item, all GUIs send a message to the program which says something like: 'menu item x has been selected'. The program does something in response to this, and then waits for the next message. The messages in all GUIs have the same sort of meanings: open a window, scroll a window down, close a file, select an item and so on. This is the key to producing software which can be easily moved from one machine to another — you write the bits of program which interface to the specific messages and formats on that machine, and all the rest of the program is independent of the GUI or computer.
This is rather like learning a new musical instrument. It makes a great deal of difference if you can already play one, because being able to read music, interacting with other musicians, improvising and even performing have many common elements which are independent of the instrument. The bit you have to learn again for each new instrument is the interfacing: your fingers have to acquire the knowledge of what a scale or chord 'feels' like, and your brain has to make all the connections again — but it isn't as difficult as the first time.
So, having written a program on one computer, it ought to be easy to transfer it. Unfortunately, it depends on how much you depended on the special character of the particular computer you used. The more you separate the user interface away from the number manipulation part of the program, the easier it will be. The speed with which ST and Mac programs have been converted for Windows 3 on the PC shows that many people do it right. The problems come when you only know the ST, and so your programs make use of its features without separating the processing from the interfacing.
It really does look as if the ideal course of action is to learn not only GEM, but to learn how to program the Mac and PC as well, so that you know enough to take all the 'machine-specific' stuff out. If this sounds like a person who plays guitar, but also dabbles on keyboards, and can play drums if the need arises, then it should. I would argue that the multi-instrumentalist is a more all-round capable musician. Applying this formula to a computer programmer produces the formidable task of learning three or more computers, but there is also the computer user too...
Atari ST programs designed for music have tended to evolve into 'do it all' systems. You boot up into the sequencer, work on your music, format a disk, save some SysEx data, print out a score, and then power the ST down. The ST is nothing more than the platform on which the sequencer runs. Working on the principle that familiarity with other aspects of a subject broadens and expands your abilities, then perhaps the Cubase user should really try and use Notator for the next project, and vice-versa. And there may be unexpected surprises — that tricky edit that you always have to do to sort the hi-hats out might be easier in another program. It is a strange fact that looking at something in a new way can often suggest a better solution — you may be very experienced with your favourite sequencer, but learning another will definitely make you see it in a new light.
Feature by Martin Russ
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!