Having seen those rather nifty little demos using tracker routines I said to myself "Gee, that could be useful in STOS." (Yeah I'm sad enough to talk to myself).
Some while ago ST User gave away a demo(?) of AN Cool's TCB Tracker. Up until that point I'd not seen a tracker program, so I jumped straight in and created some of the worst tracker music ever. Using it within STOS was a no-no. A month or so later the same mag gave some assembler routines and little proggies to use with STOS. "Yippee!", I cried and sank into a mist of propeller headed coding frenzy. Some two days later I resurfaced dismayed at the routines inability to be coaxed into operating with STOS. Killing all interrupts and only allowing the space bar is NOT what I call useful.
Hang in there baby the STOS Tracker bit is coming...
The idea of ever getting a functioning STOS environment running alongside
a tracker tune faded into my wish list. Although I did try on occasion,
hoping for divine inspiration. Whilst browsing through a PD catalogue (Newage
PDL) I noticed a disk, 'STOS Tracker extension. Allows the playing of tracker
tunes within STOS'.
"Yippee!", I cried once again to the annoyance of my neighbours, "Now
I can cure the world of sickness, poverty and I can do something constructive
with STOS".
A postal order for œ1.50 and a 2 day wait and it arrived. Still clad only in my cerimonial sleeping garb, I tore open the package and thrust the disk manfully into the drive. And lo the world was at peace. erm..It arrived and I had a look at the disk.
There were a number of files on the disk. Among them a compiled exampleprogram and the traditional readme file. I double clicked on the example. "Wow!", I exclaimed moistly, "Moving graphics AND a tracker playing!" I investigated further. Problem number one. The readme file, giving command details and intructions, was a grand total of 4k and 104 lines long (ooer). This could only mean one of two things. Either it was so simple that this was all that was needed to get it up and running, or, the program was cobbled together badly. Read the rest and decide.
Nine commands are added to STOS through the extension:
| TRACK LOAD "filename.abk",b | Loads an .ABK file into bank b |
| TRACK PLAY n | Plays the currently selected .ABK |
| TRACK STOP | err..stops playing it |
| TRACK BANK b | Changes the bank number. In theory you can have 2 or more modules in memory. This changes the current one. |
| TRACK TEMPO t | Changes the tempo |
| TRACK VOLUME v | Changes the volume (for fade in/outs) |
| =TRACK SCAN | Scans the keyboard for keys. The tracker kills all keyboard and mouse activity. |
| TRACK KEY k | Sets the 'kill player' routine as a panic button. Useful if you forget to include an escape routine. |
| =TRACK VU(v) | Gives the current volume status of track number v. This means that you can program VU meter type thingys |
7Khz - Gives you the lowest quality, but the biggest amount of processor time. However the quality is really bad, and the amount of time left is woefully small. Compiling helps - but more of that later. On replaying a tracker tune, the high notes sounded like a cat gut string being plucked - with the cat still attached.
14Khz - Gives the "best" quality of sound and NO processor time. No processor time is almost literal. I tried to copy a screen bank to the logical screen - and saw almost every line being copied accross! Interesting but only of use for static screens.
10Khz - Supposedly the best of both worlds. A halfway house of quality and speed. I found that it took up too much time to do anything but the simplest of scrollers (cheating like hell) and the quality narked too much.
When I got the extension I knew I would lose a lot of processor time,but how much I lost was quite ridiculous. Demo crews can get trackerroutines running at 7Khz in about 15 scanlines. So WHY does the STOSroutine take 100+ (at 14Khz I'm sure it takes 1000)
To continue the saga; Having put the relevant extensions into theappropriate folders, I fired up STOS. On the disk are a few exampleprograms showing the basics of operation. All were very simple buteffective. One demo program caught my eye, instead of using the TRACKcommands it accessed a machine code program. I could not at the timeunderstand why, and put it down to sloppyness when compiling the disk.
I could dwell on the speed problems at great length, but I'll stick toother hassles with the extension.
Problem two arose when I discovered that the .MODs had to be convertedinto the .ABK format. UGH! Why? A BASIC program is provided to do thisconversion, and is nippy enough and even nippier when compiled. Ireally don't know why this is required and it is very annoying. I endedup with disks full of .MODs and an equal number of disks with .ABKfiles on it.
Problem three reared it's head when I tried to compile my program. I'lldescribe the program simply. A static screen with a lame scroller atthe bottom and a tracker tune in bank 7. A very simple program, yes?When I tried to compile the program the compiler choked.ADDRESS ERROR AT LINE xxx. AAARGH! line xxx was the last line of theprogram. Having came accross similar problems, (overwriting thecompiler or mis-assigning banks), I rebooted the whole kit andkaboodle. I tried again. ADDRESS ERROR AT LINE xxx. Right git, I erasedthe last line. I recompiled and got ADDRESS ERROR AT LINE xxx. Thishappened repeatedly until I had a two line program.
At this point I lay down in a dark room for half an hour with a damptowel
over my face. Computers and programs do this to me sometimes.
I returned refreshed, filled with hope, optimism and a plan! I lookedat
the distribution disk again. There tucked away in the darkestrecesses of
a folder named UPGRADE was a program called COMP_207.PRG.Aha! After looking
at my compiler folder and seeing I had version 206,I realised my error
and replaced version 206 with 207. Happy I rebootedSTOS, loaded my program
and tried to compile. Urgh! BUS ERROR. "Why, Ohlord give me strength. Why
won't this f$%^&* program work. Where insatans bottom does Loinet come
from." An hour or so of fiddlingamounted to nothing. ADDRESS ERRORs and
BUS ERRORs leaped eagerly to myscreen. When EXTENSION NOT PRESENT LINE
xxx appeared on the monitor Ilay down again, swearing I would become a
celibate and live on amountain.
I surrendered completely and ignored the program and the extension fora few days. However being scottish, œ1.50 is money I'd prefer not togive up on. I tried the disk again. Randomly clicking on every file onthe disk brought results. The little file COMP_207.PRG is an upgradeinstallation program. "Aargh! Bastard! Mr.Lionet you dumb assed twat!What was wrong with calling it UPGRADE.PRG or even a little readme fileto say 'please double click on this program'" Of course it wouldexplain why the new compiler program was 90k+ in length!.
"Hurrah - hurrah we are the STOS boys! Hurrah - hurrah You'll here us by our noise, We'll scream and kick and shout and swear kick Fran‡ios in his balls Oh - yes - we - are - the STOS boys"
Okay, success comes at last I can now compile my lame program."Wahay!", I ejaculated sponaneously, "It compiled". I saved the file todisk, came out of STOS and double clicked on my lame masterpiece. "Ohmy grannies balls", I muttered desperation reaching it's climacticconlusion, "an Illegal Function Call, now what!"
Believing I was to blame I fired up STOS - yet again - and examined mycode. Nothing that could cause an error. So I stripped it down to the'bone' and just left the tracker routine. This time I compiled toBASIC. ILLEGAL FUNCTION CALL. You know the drill, I lay down for awhile. In cases like this it's very important to keep a clear head. Ion the other hand went out and got pissed. If you can't solve it, hidefrom it.
Another week passed, (busy with other things), before I got back toSTOS. I tried to compile the stripped down version of the programagain, just in case the first time was a fluke. No such luck. I wentthrough the commands one at a time and discovered the problem. At thispoint I embarked on a relentless and purile bout of name calling - justto release tension you understand.
The problem it seems is that Monsewer Lionet for reasons best known tohimself didn't think anyone would want to compile a music bank alongwith the program. Instead you have to use TRACK LOAD every time youwant to use the TRACK BANK command. A flicker of understanding waftedthrough my head, but found no resting place at this time. What thismeant was that the TRACK BANK command is less than useless. Mostsituations only need the one module but you will have to leave it lyingaround on the disk, just waiting for someone to come along and ripp itor lose it. URGH!
The understanding flicker came bouncing into my mind and leapt straightout again. Still half believing that it was my fault, I changed TRACKBANK 7 to (7) to start(7) to ADR (which equalled start(7)) all failed.The flicker was now quite aggressive and demanded to be noticed.
I loaded up the demo program - remember the one that had a machine codeprogram instead of the commands? - and had another look at it. Ah! thegit faced twit. This program was here, not because he was sloppy whenhe was compiling the disk, but rather he knew full well that theextension fell over when you wanted a tracker tune compiled in theprogram. At this point I once again lay down, plotted revenge thenrealised that if nothing else - the program was free.
The extension is actually quite good. The sound quality is, sadly, verypoor in relation to some other routines. It does have one overriding benefit that can't be ignored. You have control of the STOSenvironment. And that is nothing to be sneezed at.
The biggest annoyance, as far as I'm concerned, is the inability tocompile a tracker tune along with the program. Now it has to be saidthat it may be because of my set up (4Mb STE) but I somehow doubt it.It may also be a corrupt extension, if so then why do all threeextensions have the same error. The machine code program is a cop out.It seems to run at 7Khz so is lousy in quality and of course it can'tbe changed. It does allow you compile both tracker tune and programtogether, so it's a botch up but a functioning one.
Finally, get the extension. I would reccomend this extension, but youhave to take the drawbacks seriously. It has it's uses so go forth anduse it.
Ease of use : 65% It would be higher if all the commands worked as you would expect them to work.
Value for money : 80% At œ1-œ2.50 and free if you get a copy from a friend, then it's excellent value. It's drawbacks are indeed many, but it does at least allow control within STOS. If a little slowly.
Overall : 70% Just too little (and probably too late) to justify a higher score. The quality lets it down and the speed restrictions make it generally impractical. It's still a MASSIVE improvement on bleepy chip music though.
bob goodfellow 1993