A looping sample could sound wrong before a musician had written a single effect command. NoiseTracker addressed that kind of practical problem as well as making the Amiga’s tracker editor more comfortable to use. Its authors, Mahoney and Kaktus, described version 1.0 as an improved version of MnemoTroN’s Soundtracker 2.3. Their 1989 documentation lists changes to both the editor and the routine that plays its songs.
Editing without starting again
Mahoney’s notes describe an input routine that lets a user move within a line and delete individual characters, instead of clearing the line and retyping it. Keyboard commands select instruments, move between patterns and song positions, and copy tracks or whole patterns through buffers.
Other changes are less visible. The documentation explains a mismatch between sample-loop positions counted in bytes and values stored in words. Correcting that interpretation changes which part of a sound repeats. Compatibility therefore involves the player’s behaviour as well as whether it recognises a file. (NoiseTracker V1.0 documentation, “Corrected Loop-values”.)
A note can keep changing
NoiseTracker’s commands include tone portamento, which moves towards a target pitch, and vibrato, which repeatedly moves pitch around a note. The music routine must continue that work between the rows where new notes are read. The later NormalReplay source makes those separate paths visible: a new-row path reads pattern data, while intervening calls continue effects.
This is the connection to sound drivers. The pattern describes musical events; executable code turns them into timed changes to Paula’s audio registers.
Music outside the editor
The original documentation tells a programmer to initialise the supplied replay source, call its music routine every frame and stop it on exit. It explicitly says that this supplied routine is not itself interrupt-driven. The host program must arrange those calls.
That made the songs useful in demos and games, but also made the replay code part of the composition’s behaviour. The wider MOD family and later ProTracker continued this relationship between editor, data and player. A familiar module signature alone cannot explain every effect a particular replay routine will produce.
Sources
- Mahoney and Kaktus, NoiseTracker V1.0 documentation, July–August 1989: improvements, loop values, commands and replay integration. Original author text preserved in an archive.
- Mahoney and Kaktus, NoiseTracker 2.0 NormalReplay V1.1, E.A.S., 1990: original replay source, distinct from the earlier manual’s edition.