STEINBERG

GO FASTER STRIPES

Improving the performance of your computer can offer you significant advantages, such as quicker screen redraws and shorter calculation times. Sounds good, right? There are two routes to a more powerful machine: buy a newer, faster computer, or upgrade the performance of your present equipment. The first option may seem more expensive in terms of initial cost, not least because it may be hard to get a decent price for your current, near-obsolete machine. You may find the prospect of selling it for so little rather hard to handle — but consider the use you've had out of it already. So what of the second, apparently cheaper, option?

There are many accelerators on the market, from upgraded CPUs running at higher clock speeds to whole new processor boards that fit inside your computer and use your old hardware for basic tasks only — all the hard work is handled by the new electronics.

Before we look at the technical aspects of such upgrades, let's take a moment to consider the economics of it. If you decide to modify your current hardware, how good an investment is the upgrade? Let's say you decide to fit an accelerator to your computer because the secondhand value of the machine was so low — the thing is, this only postpones the re-sale problem. When you come to sell the computer — and you will, eventually — will the added value of the accelerator be appreciated by potential buyers? Probably not.

To use a crude analogy, putting a new engine in an old banger and expecting potential buyers to fully reward you for the expense is an act of wild optimism. It's not that all accelerators are bad news economically — but do think carefully about putting several hundred pounds worth of new hardware in a machine that is actually worth less than that.

Economics aside, what of the technical advantages of accelerator boards? What are the potential problems? Depending on the particular product, there may be many, or none at all. For example, Steinberg make software for Atari computers — obvious statement. Suppose you install a new chunk of third-party hardware, and Cubase no longer runs properly — who do you call? People call the Steinberg helpline, of course. What can we say? We make software for Atari computers, and this is still an Atari, right? Wrong. What you have now is an Atari with something added. An Atari computer is a specific item, designed, documented and supported by Atari, and it is for this machine that Steinberg produce software. We cannot design software for whatever variations on the Atari that third-party boards may produce. As a rule of thumb, if you add anything to your computer that would void your warranty (check on this), maybe you should think twice about it.

Yes, we know that certain manufacturers claim 100% software compatibility, but do they claim 100% hardware compatibility? Our design philosophy works, and we follow Atari's guidelines as closely as we can. The results are obvious: the Falcon 030 appears, and Cubase works straight away. I hope you have been counting the question marks in this piece. If you go for the 'major accelerator' solution, you may have to answer some of the questions yourself.

The point of these warnings is not to cast such doubt on some very clever hardware enhancements that no-one ever considers using them — some will work very well indeed. But if you're looking at such hardware, make sure that you're going to end up with a working system. Try before you buy, if possible.

On a more positive note, you can do a lot with software alone to improve the graphic performance of most Ataris, and keep your warranty intact. Here at Steinberg we use a commercial product called NVDI on our Ataris. This replaces some of the Atari's graphic routines with optimised versions. It's very good and very safe, and if you find a piece of software with which it isn't compatible (we haven't come across any), you just boot up your computer without it. It makes a dramatic difference. Most computer shops should be able to supply it. Maybe you could use this while you figure out how to get your go faster stripes to stick.

DR.T's KCS

Picking up from last month, we're now going to look at an example of how to use control sequences to build up a more complex musical structure — in this case a drum part.

Seq 1 DrumCRL1

Sequences 2 through 5 are 4-bar patterns; sequence 6 is a 1-bar fill which is being treated in a rather special way — more about this in a second. First of all, note how each sequence is being started at a specific point rather than via the Wait statement; you could use this quite happily, but you won't be able to see the exact time each one is being started and it also means that you'd have to keep mental track of the length of the sequences in use. The first four sequences are being treated in a fairly conventional fashion — that is, they're simply being triggered one after the other.

Sequence 6, however, is handled rather differently; although it is ostensibly a 1-bar fill, we're doing something special with it. Notice the use of the XX construct to stop the sequence playing immediately after the first beat, but also notice that the command is placed one clockstep before the second beat; if we were to stop the sequence on the beat there would be good chance of an audible glitch occurring, assuming that there is note data on the first clockstep of sequence 6. Doing this allows us to use only the first fragment of sequence 6 creating a scratch-like effect — in general, if you want to stop a sequence at a specific point, do it one clock before the 'logical' point to prevent spurious events from happening.

Play continues from bar 18 with our four sequences being played in a different order, and at bar 33 the whole sequence is started again simply by calling itself. The XX event just before bar 33 is slightly superfluous; as the sequence is only four bars long, play would have terminated anyway, but if for any reason you need to change the length of the sequence the XX event will stop this sequence at the appropriate point without further worry. As sequence 1 is a self-contained unit it can now be called by another; what we've effectively done is to create a kind of macro which can now form part of a larger structure.

Because sequence 1 is self-referential, the sequence will play forever even though you might only call it once from your master control sequence. To stop it you'll need to use an XX event at the appropriate point. An XL event will not work, as this will only stop the sequence once it has reached the end of its play cycle; as the final event restarts itself, this will effectively override the function of the XL event.