PREV UP NEXT Tracker 4.44

8.10: Peculiarities of the Amiga implementation: tracker versus Delitracker ?

In fact, this title is a joke... tracker doesn't compare with Delitracker at all. The purpose of the two programs is quite different, and Delitracker is most certainly the best at what it does.

Anyway, tracker yields some very interesting features, probably unique.

The old version used the timer WAIT_EBLANK unit for all its timings and assumed everything was done fast enough that the new audio commands would fall on the right beat.

This new version uses a two tasks model: task 1 fills messages telling what to do at a given time until it has no messages left and sends them to task 2. Task 2 peeks at the messages it received, waits for the right time to act on them, performs the sound changes, and sends the message back to task 1.

This offers lots of advantages.

and some drawbacks too:

Another stupid problem I got in while programming the Amiga support was using the standard WAIT unit of the timer.device, the one based on VBLANK. This was very stupid: using a timer unit of the same resolution (or about so) as the events I was wanting to measure. Since I got unlucky, it appeared to work correctly for quite some time... I'm usually looking at a rock-solid ntsc 60Hz display.

Some new add-ons: the event handling is completely decentralized. See `events.c'. This is an interesting way to bridge the gap between the usual programming model and the event-driven model.

There is some problem with arq not recognizing requesters built through BuildEasyRequest() instead of using EasyRequestArgs() directly, but it enables us to add a filerequester (the reqtools one since Amigados asl's doesn't support truly asynchronous operation... Yet another blunder from Commodore).

I haven't put any iconifying possibility in the main window. I feel that Menufy/Iconify provide very nicely for it... and they work for me, so why should I care. Already tracker weighs in at 60 K bytes, that's a true monster of a player program!

In the future, I will try to add more controls to the user interface. After all, I've got an incredible amount of data and switches about a module that I don't use at the time:

obviously, the most difficult part is to write the interface itself. All of this is possible today!


[1] This means that, once again, thinking a lot about how to code things wins hands down over the brute force approach. Assembly, no-system hackers, eat your hearts out! Tracker does not use any assembly code, is probably badly optimized in places, but what do we care ? It runs on anything at a decent pace.