APPENDIX: Trackers, modules and sampling

In the computer scene, one often bumps into a peculiar way of making music, namely tracking. Tracking refers to a paradigm in which one uses a certain type of music making software, called a tracker to produce some form of module music files. Considerable history and a whole musical subculture have developed around tracking and module music and they play an important role in the computer hobbyist circles around the Western world. In this section a brief look at the relevant aspects of tracker technology and module music is taken.

It should be noted that tracking is rather a marginal method of music making. It has a history rivalling that of MIDI, but has never gained as much popular attention—personal computers as instruments of artistic expression are a relatively new phenomenon. After the Internet revolution, PCs have become ubiquitous, however. This means that trackers, with their availability and low cost (most are either free or shareware and can be used on any current PC with rudimentary multimedia hardware in place) and excellent portability of the resulting modules (trackers read each other’s files and encode music much more compactly than, for instance, common audio editors) are a cheap and accessible tool of musical expression.


Tracking began a while after the Commodore Amiga came out. From the first models, the Amiga had an integrated four voice sample playback capability. Even the first utility software releases contained some sort of music editing and playback software, but these were severely restricted by the scarcity of sampling equipment. Most sounds were single cycle waveforms and music was in the line of beeps and chip. Around 1987 the story of SoundTracker, practically a one man project of Karsten Obarski, began. Using samples, a relatively new invention among the digital sound community, he built a simple program that could store four channel music. Storage was based on separate song and sample files. Only 15 samples could be used at a time.

SoundTrakker became extremely popular. In the spirit of the Amiga scene of the eighties, many groups disassembled and enhanced the program. Clones and improved versions became available. Most of these suffered a quiet death later, but one survived—ProTracker. It soon became the new standard and is the archetype of current trackers with its integrated sample editor, scrolling pattern display, module file format support (a dump format dating back to Mahoney and Kaktus’s work in 1989) and graphical user interface. After ProTracker, few notable trackers developed on the Amiga: Studio 16 was a 16‐bit version of ProTracker and OctaMed had support for more than four channels.

On the PC, though, the story was only beginning. The first tracker to surface on PC platform, then purely text based, was ScreamTracker, or ST. Version 2 of ST ruled the PC scene for a couple of years. ST2 was a text mode, four channel proprietary solution coded by one of the FutureCrew members for their demo work. The first tracker to get a graphical user interface (much akin to the Amiga ProTracker) was FastTracker. With the new versions (ST3 and FastTracker 2), these still are the trackers of choice for PC sceners. A new contender, Impulse Tracker, has also challenged the older programs with its innovative instrument architecture and ample features. Its retro text mode interface is also quite interesting.

One of the reasons trackers are not very well known is that there have been few trackers available on the Windows platform. This is beginning to change, however, especially since some rather highend composition software (buzz, rebirth etc.) have taken influences from the trackers of the past.

This section is based on The Origins of Tracking whose author is not known, found on the Internet Music Monitor website.

Score: tracks, patterns and orders

The basic structure of trackers has remained the same since ProTracker first appeared. It consists of a fixed, sample based synthesis algorithm and a strictly metric, multichannel score.

The score of a tracker is composed of a hierarchy of increasingly complex structures. The most simple is the line. It is composed of some fixed number of cells, one for each output channel. The line represents the smallest completely controllable time quantum in a tracker. It is further subdivided into ticks, which in newer trackers also have variable length (given by the bpm value). The number of ticks in a line is determined by a variable called tempo. Each cell on a line holds a fixed set of parameters describing what happens during the line on the channel. Typically this set consists of a note (giving the pitch of the sample to be played on the channel, starting with the current line or blank if the previous sample/silence is to resume), an instrument number (the index of the sample/instrument that is to be played starting with the line or blank if there is no change) and an effect (giving one of a set of simple time and pitch related synthesis instructions, such as silence the channel on the second tick of the current line, or a score control command, e.g. delaying the progression of the score time by one tick). Additionally, there may be room for a second command and/or a separate volume (or volume/reduced command, as in FT2) field.

Lines are aggregated into patterns. In older trackers these were always of fixed length, invariably being 64 lines long. A pattern has little semantic value, except for the possibility of repeating portions of the pattern selectively under the control of effects commands. The 64 line structure is too heavily geared towards simple four‐to‐the‐bar rhythms, so the possibility of interrupting a pattern is provided. Nowadays this is rarely used since current trackers offer patterns of varible length. Patterns, in case, are gathered into an order, which lists the order in which patterns are to be played as well as a loop start value which tells where the tracker should jump after the last pattern in the order has been finished. The number of channels and fields per channel remain constant throughout a song and the song (i.e. module) is customarily represented as a listing of lines with time advancing downwards. In trackers this view, channel structure disregarded rather similar to a MIDI event list, scrolls in real time to aid in locating note events and effects while they take place.

This ample structure helps the composer in many ways. First, the view of sound events is extremely uniform and simple. This means the rather intricate sampling constructions used are easy to manage and perceive. Second, patterns, editing commands and navigation facilities make for easy editing and straight forward score reuse. Third, the representation is a compact fit on screen—information density can be quite high without sacrificing ergonomy. On the downside, trackers are very much tied to the Western metric musical structure, four‐to‐the‐bar rhythms and point‐like sound events—natural evolution of sound textures is difficult to express in the chosen score notation. As only one sample can play on a track at a time, the tracker feel is quite different from that of synthesizers. The inherent need to distribute chords and melody lines across channels can make vertical structure difficult to identify in music. In some cases score reuse is insufficient too, since only whole patterns can be repeated. In newer trackers most of these limitations have been relaxed somewhat—notes need to end when the next one on the same channel starts, manipulating line time spans is easier and patterns may be decomposed vertically into independent, reusable tracks. The most extreme form of the latter is the one adopted in Buzz, which mostly rejects the idea of patterns and instead allows independent tracks to be placed on a linear timeline.

Samples and instruments—synthesis architecture in trackers

The synthesis architecture employed by early trackers was exceedingly simple. This was because of the limited capability of the Amiga—only vanilla sample playback with pitch shift and volume could be achieved in hardware. On the software side, the low processing power of Motorola MC68000 cpu limited the programmer’s options. This lead to samples being used as is. The samples were tied to channels which directly corresponded to the Amiga hardware output channels—only a single sample could play at a channel at any one time. As there were only four channels, the number of simultaneous voices was limited to four, too. This made trackers an exceedingly quirky tool—four channel modules are excruciatingly slow and intricate to prepare. Sample memory was also quite limited in the original Amiga, since there was only some megabyte worth of RAM on board and the first trackers could use just a portion of that (called chip, the portion which the sound hardware could directly access). The result was that 200 kilobytes worth of samples in a single module was considered rich. To add expressiveness, a small array of simple effects was implemented—they controlled the pitch, volume and sample playback position of the currently playing sample. Examples of widespread effects are volume and pitch slides, setting the volume, setting the sample offset (playing position) to some specific point in the sample, quickly alterating between three pitches (arpeggio, used for making primitive chords—with single cycle waveforms this was a handy, memory efficient alternative to using full, sampled chords), vibrato and tremolo of different kinds, abruptly cutting the sound in between score lines and various score control commands. On tuning, only equal temperament was available in early trackers, a tradition that holds even today. Needless to say, most serious musicians find the concept of trackers fairly repulsive, at least at first sight. Nevertheless, some fine tunes have been composed on them.

Nowadays, most trackers follow the lines of their predecessors, but extend the architecture—the basic principle has been the one of offering more of everything. The number of channels has increased from 4 to 32 and beyond, becoming variable as well. The number of effects has also increased a bit after stereo playback became available—panning is now often included. A separate volume control in addition to a single effect command time unit has surfaced. Sample memory, sum total, has grown from under 100kB to over 10MB at best. The number of separate samples has grown first from 15 to 31 (in ProTracker), then beyond (currently at least 127). The maximum size of a single sample has breached the 64kB barrier and 16‐bit samples are the norm. Sample rates have also gone through the roof with 44.1kHz considered mandatory for quality compositions. Sample looping modes have gone from no looping to looping (early trackers) to looping with explicit loop points (ProTracker) to the possibility of ping‐pong loops (FastTracker 2—the origins are in FT2’s GUS support).

The most notable changes are not in the numbers, though. In recent years after the inception of FT2, trackers have began incorporating ideas from synth design. The most notable is the concept of instruments, introduced by FastTracker 2. Instruments are collections of samples and auxiliary data which can be used very similarly to the bare, original samples used in trackers, yet which provide the sound with a lot more realism and adjustability—instruments are the tracker equivalent of synth patches. Instruments permit, to a degree, pitch splitting and multisampling, as well as the incorporation of automatic vibrato plus pitch, volume and panning envelopes. All these are needed for plausible duplication of existing instruments, such as violins, fat synths and the ephemeral grand piano. Instruments also avoid many of the effects based hacks earlier trackers used to convey their musical ideas. Along the same lines, they have made patch interchange a breeze compared to the old times of having to decipher the score to understand how a particular bass line is built up.

Of pure trackers, Impulse Tracker probably takes the instrument paradigm farthest. New in IT is the possibility to allocate output channels dynamically, which for the first time makes it possible to decouple an instrument from the score channel it plays on. An instrument, with all its dynamic conntrol (vibrato, tremolo, multiple envelopes and volume/pitch dependent panning and multisampling) is allowed to play independently of following notes on the channel. This makes IT tracks more like the MIDI event list so familiar to a more traditional synthesist. It is also representative of the current trend in the tracker world: disentangling the score and the synthesis architecture. On the same note, some trackers have even included support for non‐sample based hardware synthesizers such as adlib (which is based on Yamaha’s OPL implementation of FM synthesis). This tact was taken by ST3 and portrays the first attempt in incorporating multiple synthesis algorithms in a tracker.

Recently, an even more radical departure from the classical tracker architecture has been seen in Buzz, a Windows tracker/modular synthesizer hybrid from the Finnish group Jeskola. However, Buzz is not discussed here but in another appendix, alongside other algorithmic synthesis software.

Support facilities

Thus far it may sound like trackers are a model of Spartan design. This is not entirely true. Although most trackers are produced by die‐hard computer freaks and run on bare metal, they have been designed to be very ergonomic and efficient to use, once learned. They can incorporate some rather fancy GUI features, like context sensitive help, selectable fonts and extensive facilities for customization. Trackers are also phenomenally responsive—the guis are steady as rock with no signs of flicker or delay anywhere. Trackers tend to be quality software, if rather eccentric at first sight.

Most importantly, though, trackers are largely designed to be standalone programs. Most distributions incorporate all one needs to use the tracker, including documentation, sound and gui hardware support, an instrument editor, a disk manager or librarian for both instruments and songs, often a sampler, perhaps hard disk recording (the possibility of dumping to a wave file), support for multiple file formats, perhaps some demo songs and in some cases even recrerational facilities.

Playing Nibbles while watching your latest musical innovation scroll by can be quite surreal…

Of those mentioned above, sample/instrument editors are the most important. This is because little support for the instrument file formats used by trackers exists outside the trackers themselves. The only exception is the XI format of FastTracker 2. Some trackers incorporate exceptionally powerful editing features, like effects, mixing and support for automatic loop finding operations and loop crossfades. In others the support is limited to rudimentary cut‐and‐paste type operations. When choosing a tracker or coding one, this is an area which is almost too easy to forget.

It is also customary for new trackers to include at least partial support for MIDI input/output. Usually this comes in the form of response to incoming MIDI note‐on and note‐off messages. In better trackers, such as IT, MIDI output can be driven by a specially rigged module while at the same time playing conventional tracks on the remaining channels. Some even support sysex and controllers, which makes it possible to drive an entire studio from a single, easy to use interface. The downside is that integration to other programs and the studio hardware is seldom tight—there is bound to be some slack between what is basically a standalone platform built by independent coders and an open, music industry driven studio architecture.

Frontiers: what cannot (yet) be done by trackers?

Mainly due to historical reasons, the architecture of trackers has been fairly rigid. (This has to do with the abovementioned bare metal attitudes, the view of people who build tracker software and the inner workings of the computer scene.) However, recently it has become apparent that some of the underlying assumptions of tracker design are rather weak and do not fit well into the current way of commercial music production. This is why there are now some pressure to incorporate new functionality into the tracker architecture—or even redesign parts of it.

It has already been pointed out that trackers are standalone programs by intention. This does not work well today with desktop environments, common guis and all that. This is why most new coding projects involving tracker software concentrate on the Windows platform. And on Windows, one needs to consider object orientation. This has meant a complete design overhaul for most projects and has influenced the way people think about the need for modularity. Of course, the next logical step is to modularize the synthesis architecture. This is exactly what is to be expected from such new upcoming trackers as Impulse Tracker 3. In these, the synthesis architecture has been split off from the main tracker and can be changed at will. As trackers are implemented on general purpose cpu’s, new algorithms can easily be added and used in parallel. Buzz stands out as one existing example of how to do this. If synthesis algorithms other than sample playback could be incorporated (and with a little advance design, they can), it would vastly expand the area covered by trackers. The simplest example is the addition of real filters to some recent trackers—all that would still need to be done is to include these into the instrument architecture. Seeing what filters lead to when introduced into the early commercial samplers should give a fair indication of how useful they can be. Moreover there is nothing to stop us from going further—current PC hardware is powerful enough to do in real time many things commercial synthesizers cannot. And there is always the possibility of non‐realtime calculation, something which does not come into picture when building studio hardware.

Another improvement is something brought on by an age old debate of whether modules beat MIDI or vice versa. One of the primary arguments of the MIDI camp has been that it is almost impossible to achieve professional sound quality with a tracker. The main reason is, of course, that the mangling enabled by external effects processors and mixer boards is not available in the lower cost architecture. No reverb equals no ambience/feeling equals lower than professional quality. Now, implementing effects digitally and fitting them into the framework of trackers is not especially difficult, witness Buzz. Such functionality greatly enhances the tracker platform and is bound to become the norm in the upcoming years.

For a program to really work for a musician, it needs to be controllable in real time. To achieve this, a tracker should respond to MIDI messages, both notes and controllers plus possibly support bidirectional sysex. In synthesizers, controllers affect the sound throughout the evolution of a melodic line. Trackers need similar functionality if trial and error and modulation are going to be used as compositional tools. There would need to be realtime response to MIDI cc stretching over multiple notes. As examples of genres in which such methods are invaluable are ambient and techno—both operate not so much on melody or harmony as they do with evolving timbre. Combining more than one synthesized voice would also be a useful capability: the vocoder sounds so familiar to hip‐hop fans are difficult to achieve without.

Since music is made in studios, trackers should integrate better with other studio equipment. In this, synchronisation plays a pivotal role. A tracker originating sync signals could be used to drive sequencers and MIDI composition and A/V authoring environments. An ability to sync, for instance, to SMPTE would make it a breeze to integrate a tape based studio. This would enable trackers to be used in commercial studios and would pave way for their wider adoption.

As trackers are proprietary programs shared mainly by computer hobbyists, they do not exactly shine in the interoperability arena. Trackers work with trackers but not with other software. Moreover, if even part of the above enhancements to the synthesis algorithms are ever to be implemented, they make even instrument interchange difficult. This is why voluntary, cooperative file format standards would be a great boost for the breed. Similarly, they would enable larger common instrument libraries to be established—presets sell synthesis, as we know.

Nowadays stupid digital audio has also reared its ugly head. This shows in the popularity of MP3s and the fact that most commercial computer composition environments support the use of plain, streaming audio in addition to MIDI. Similar support would add value to trackers as well, though it is doubtful whether it fits into the tracker architecture very well. Compressed audio (e.g. MP3) is something that should be supported, however, as it is now immensely popular as a distribution format and because it is a natural enhancement to the dump‐to‐wave facility already present in prominent trackers. It is also a virtual necessity for supporting multichannel audio, something which is required goods if tracking is to survive the millennium. Furthermore, no standard software APIs exist for 3+ channel audio—realtime output is really not an option, here.

Current trackers on the x86 platform

To get a more concrete view of what trackers are and what one can do with them, some of the more salient features of three trackers are highlighted. These examples come from the x86 (PC) platform, since that is what I’ve mostly come in contact with. They do not represent the whole spectrum of trackers at the moment, and certainly a lot more could be said about Windows trackers, but I think these three have been influential enough so that they deserve their place in this text. A complete review is not attempted, so the reader is invited to seek the programs out and try.

ScreamTracker 3.21

Scream Tracker is the precursor of most current PC trackers. The first released and commonly used version was ST2, back in the days of yore. ST2 was the first PC tracker to be taken seriously, and surfaced at about the same time as the 80286. It has been put together by Psi of FutureCrew and was originally used for FC’s own demo and music work. After a long pause, a new version was released in the first half of the 90’s, dubbed ST3. The difference to the original program was vast, both in features and in ergonomics.

The user interface of Scream Tracker displays some hard core attitude—it runs entirely in text mode. Yes, up to and including version 3. Some clever tweaking of the character sets results in limited graphics being available as well. At its time ST3 represented the tried and true more of everything attitude towards software construction. The tracker portrays 16 channels, expanded limits on module size (though samples are still limited to 64kB), support for multiple sound cards, a sample librarian (in ST, instruments equal samples, which was common back then), some visualisation functions for the tunes, a very usable editor and, later, panning. It also introduced the separate volume column to the PC scene. Most of these had been present in Amiga trackers for many years (and indeed some earlier PC trackers) but ST really brought the technical side upto par with the best Amiga ones. The user interface was not as friendly, but then again, the software was primarily meant for FutureCrew’s own work.

The architecture of ST3’s sequencer is very traditional: an order which lists fixed length patterns. Only one real difference to the model propagated by ProTracker is seen. The number of channels can change. The selection of effects is tried and true with a couple of trivial new commands. The same goes for the sampling engine—unlike in newer trackers the fine distinctions between samples, instruments, aux data and so on are not made. A funky addition to the synthesis engine is the possibility of using an external ADLIB synthesizer to augment the sample playback machine. In this case, a separate instrument format with its own FM specific parameters is used. The librarian is very efficient, as well.

All in all, ST3 filled a definite need at its time: there were no good 4+ channel trackers on the market. ST3 was dependable, efficient and included some must‐have features. It was a defininte success. Most musicians of the time migrated to the platform and some use ST3 still. I’ve heard it is good for techno and drum work. In other areas, time has gone by ST3’s architecture.

FastTracker 2.08

Like ST, FastTracker is not a newcomer to the scene. FT’s first version came out a while after ST2. It was a four channel traditional tracker (basically a PC ProTracker clone) coded by Mr.H of the Swedish demo group Triton. The only real merit of FT, as compared to Amiga trackers, was its speed. Amazingly it could run four channels in real time on a ’286 and achieve interactivity. It also boasted a proper mouse controlled GUI, something pretty much unknown in the PC scene of the time. But FT isn’t the issue. FT2 is. FastTracker 2 came out a couple of years after ST3 and immediately blew the bank.

Looking simply at the sequencer side of the program, the popularity is surprising. The sequencer is a very conventional orders and patterns one. The only real enhancements is a variable number of channels (upto 32), variable length patterns (which did not work in the original releases) and an additional volume/effects column for each channel. The user interface follows the path set out by the first version, it is graphical, reactive and comprehensive with a well designed layout. In the support facilities side, a disk manager for samples, instruments, modules, tracks and songs is present. Multiple formats are supported. A sampler/sample editor is included (which ST3 does not have), as well as online help and workable editing tools. And everything under graphical control. But not much an Amiga tracker wouldn’t have. If it weren’t for the instrument architecture.

FT2 was the first tracker in history to make a proper distinction between instruments and samples. Whereas older trackers at most allowed a loop setting, a base pitch and a default volume for a sample, FT2 went the whole nine yards. In FT2 we have instruments composed of at most 16 samples. The architecture selects the correct sample to use based on pitch. The samples are conventional, except for bidi looping support. Each sample has its own base pitch, volume and pan settings. Each instrument has loopable volume and panning envelopes and vibrato. Sustain with note‐off events has finally been added. All this means that the instruments in FT2 are closer to sampler patches than tracker samples, yet the sequencer interface essentially stays the same. This was a huge leap when FT2 came out.

FT2 has some rudimentary MIDI support—it can play instruments in response to incoming MIDI events and instruments can be configured to send MIDI messages. This is important for the professional musician, since all studio equipment uses MIDI exclusively. There is no sync support, though.

Putting together all of the above, we have one solid, easy to use package with everything one needs. It is well documented, bug fixes have come in time and generally speaking, it’s quality software. It even has nibbles builtin. It isn’t a surprise FT2 took the Scene by storm.

Impulse Tracker 2.14

Of the three trackers mentioned here, Impulse Tracker is the newest. As such it is quite surprising that its user interface follows ST instead of going GUI like FT. Basically, IT is an ST3 lookalike with a similar level of support facilities, but whose synthesis architecture implements all the features of both FT2 and ST3. IT also supports the file formats of FT and ST, plus some. It is exquisitely compatible. There’s also support for song messages, a feature mostly popular in more proprietary tracker architectures.

It may sound like IT is a boring derivative of older work. But it has some very advanced (by tracker standards) features. The most important are the considerable number of extensions to the instrument architecture (loopable volume, pitch and pan envelopes and the possibility of routing the modulations a bit), dynamic voice allocation and, now, filtering. Voice allocation is what really makes IT different—it breaks off from the age old sample per channel paradigm. Amazingly enough, the musician’s interface stays essentially the same. IT supports 32 user, 128 virtual and 64 physical channels.

It was said that IT supports filtering. This is true to a point, just like it is true that limited MIDI support is available. The integration is so poor, however, that few people use the feature. The filters (like MIDI) are not a part of the instrument architecture and filter settings do not transport in instrument files. This is too bad, since proper DSP effects and a filter capable instrument architecture would be nice to see in a tracker. As for the future of IT, the final release of the current version has gone. It may be that a 32‐bit Windows version will be coming from a third party (from Pulse members—the group disintegrated a while back), but there are no guarantees when.