Tracker memory consumption

Tracker 4.44

I've gone to some length to ensure that tracker doesn't use too much memory, and is still fast enough. Specifically, I'm storing note values instead of actual pitches (see The Protracker format).

Some modules don't use all the patterns stored within the file, and in fact, only junk is stored in the unused patterns. For that reason, tracker now analyses a module to remove unused patterns and unused samples. This ensures that note values will be correct, reduces memory consumption slightly, and junks binary files in a quick way.

Here is a rundown of tracker memory consumption, for a typical machine where `short` values occupy 2 bytes and `long` values 4 bytes:

- pitch table for 17 finetunes and 120 notes. Weighs in at 4080 bytes.
- sample info for all used samples. Each sample info is about 200 bytes long, including sample name, and 100 bytes of volume scaling table. Only as many sample infos as samples are used, add one sample info for an `empty sample'.
- sample memory for used samples only. Precious chip memory on the Amiga. Since I've seen `The player' from Jaarno Paarnen, I'm thinking of adding decompression code for the samples on-the-fly. Also, a real resampling mode on the Amiga or a sample cache would be cool.
- 4 bytes per event, 1036 bytes per used pattern (for 4 tracks songs).
- song data structure, approximately 300 bytes.
- sine table for vibrato and tremolo (see Base effects), approximately 768 bytes.
- buffered extendedfile, 15K.
- audio buffer, when applicable. Usually set for one second of sound (around 100K usually).
- pattern load buffer, 1K.

In the end, memory consumption is very close to the actual length of the file on disk (sometimes less). As a benefit, the file is scatter-loaded into memory. Tracker works well even when the memory is somewhat fragmented.

Recently, I've added a memory allocation logging tool to tracker (``mung.c`'). To use it, you just have to recompile tracker with ``-DMUNG`' and add ``mung$O`' to the list of object files. Tracker will then log all of its memory activity to ``logfile`'. It is then trivial to write, for instance, a perl script that will analyze this file and retrieve interesting statistics about tracker.

I was able to trace several minor memory leaks thanks to this tool, and discover that tracker uses very little memory of its own. In fact, tracker uses most of its memory for audio samples (some 500K out of 660K) on a real life example.

This shows quite clearly why it might be useful to load samples on need instead of having them in memory all the time.