APPENDIX: Trackers, modules and sampling

History

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.

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.

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