@database tracker.guide

@Master tracker.texinfo

@Width 72


This is the AmigaGuideŽ file tracker.guide, produced by Makeinfo-1.55 from 
the input file tracker.texinfo.


@Node Main "tracker.guide"
@Next "Introduction"
@Prev "Concept Index"

   This documentation describes tracker 4.42.

   tracker is a shareware soundtracker player that works on many
different architectures.

   It is now forbidden to redistribute tracker as a stand-alone
program. I'm fed up of getting incomplete bug-reports.  Be sure to at
lease include the documentation with your versions, and full directions
to get back to the source.

   @{i}Thanks@{ui}

   For @{i}any@{ui} bug-report, @{i}don't forget to include @{i}full@{ui} version information@{ui}
including
   @{b}*@{ub} tracker source version.

   @{b}*@{ub} the architecture on which you've compiled it.

   @{b}*@{ub} any change from the standard distribution as available from @{"aminet" Link "aminet"}.

   As I am a lazy person, this file tends to change more slowly than
the tracker program itself.  Some options may no longer exist, some may
have been added.  Many things may be different.  I mainly try to get
out a working, efficient reasonably bug-free program.  If I manage to
write corresponding docs, fine !  If I don't, tough luck ! Anyhow,
looking at the source file should provide you with enough insight for
everything.

   Copyright (C) 1995 Marc Espie.


 @{" Introduction " Link "Introduction"} 
 @{" Availability " Link "Availability"} 
 @{" Registration " Link "Registration"} 
 @{" Reporting bugs " Link "Reporting bugs"} 
 @{" Credits " Link "Credits"} 
 @{" History " Link "History"} 
 @{" Installation " Link "Installation"} 
 @{" Porting tracker " Link "Porting tracker"} 
 @{" Usage " Link "Usage"} 
 @{" Technical Information " Link "Technical Information"} 
 @{" Concept Index " Link "Concept Index"} 


@EndNode

@Node "Introduction" "tracker.guide/Introduction"
@Next "Availability"
@Prev "Main"
@Toc "Main"

Introduction
************

   "Soundtracker" is a family of music composition programs that exist
on the Amiga. The resulting data files (modules) have been appearing on
ftp sites for some time now.

   For a machine with sufficient horsepower and some audio capability,
it is possible to emulate the @{"Amiga audio hardware" Link "Amiga audio hardware"} in real time, and
play those modules. How close to an actual Amiga the resulting rendition
will sound depends only upon your machine's CPU and audio abilities.

   The Soundtracker format originated on the Amiga about ten years ago,
with the original sound tracker, written by Karsten Obarsky.  There
have been numerous variants built upon it, including then many versions
of Protracker (see @{"The Protracker format" Link "The Protracker format"}).

   A Soundtracker module is a binary format that mixes audio samples
with sequencing orders, making it possible to play rather long pieces
of digital music with reasonably good quality.

   Tracker is a portable player for these modules.  Its main features
are
   @{b}*@{ub} faithful rendition of all Protracker tunes. (1)

   @{b}*@{ub} portability. All the code is written in C.

   @{b}*@{ub} support of efficient compression methods.

@{"The Protracker format" Link "The Protracker format"} is historically limited by the Amiga audio
hardware, namely
   @{b}*@{ub} no more than four tracks.

   @{b}*@{ub} somewhat poor sample rendition.

   There have been some attempts to override these limitations, and some
offsprings of Soundtracker on other platforms that support 6 or 8
channels modules. Tracker tries its best to support these variant
formats.

   Liam Corner (see @{"Credits" Link "Credits"}) had the original idea of writing a
Soundtracker player for the Sunstation. His program, though imperfect,
proved it was possible (2) I wouldn't have thought of writing it
myself, but armed with his original code, I used my knowledge of the
Amiga tracker format to `add some improvements'.  Of course, I ended up
rewriting the whole code. At that point, it ran on Silicon Graphics
Indigos and Suns.

   After that point, lots of people (see @{"Credits" Link "Credits"}) found that tracker
was reasonably easy to port to their machines though quite buggy still.
These days, some two years later, tracker looks as if it works on many
more machines, though that may simply be a deceptive illusion.

   If you want to modify tracker or make it run on another machine, or
correct problems, please do so. Just try to keep in touch with me
(Marc.Espie@ens.fr).

   There are more architectures supported all the time. Check the
@{b}Makefile@{ub} for this version or See @{"Installation" Link "Installation"}.  Your machine should be
able to produce sounds, that goes without saying.  You also need tunes
to play (module files).  Some are available on @{b}nic.funet.fi@{ub} or @{"aminet" Link "aminet"},
for instance.

   @{i}Most@{ui} Soundtracker/Noiseplayer/Protracker modules should play out ok.
Due to various disagreements between all the Soundtracker versions
(never forget Soundtracker is a horrible hack, a big kludge), it is a
@{i}real@{ui} nightmare to try and make some commands work. What you have is my
best effort at trying to outguess every Soundtracker composer in
existence... Obviously, I haven't completely succeeded.

   MED, S3M, or XM support I've thought of, but don't forget, to make
tracker work, I need to reverse-engineer assembly routines coded like
spaghetti, and transform it into more or less human-readable, normal C
code.  So up till now, I haven't had time enough to support these.
Teijo's code is not exactly limpid, @{b}MEDplayer@{ub} itself tends to change
from release to release, but maybe one day...

   Actually, if you know other player programs, you will notice that
tracker is better at the compatibility game than most of them.

   ---------- Footnotes ----------

   (1)  Well almost all.  Since there are several distinct protracker
in existence, it is difficult to be compatible with all. I estimate
that more than 99% of modules are output correctly

   (2)  This is the original @{b}str15@{ub}/@{b}str31@{ub} that might still be available
on some sites, even though it is hopelessly outdated.


@EndNode

@Node "Availability" "tracker.guide/Availability"
@Next "Registration"
@Prev "Introduction"
@Toc "Main"

Various pointers
****************

Where to obtain tracker
=======================

The status of tracker
---------------------

   Tracker is @{i}Shareware@{ui}. If you use it much and feel like it, please
send me some money, or software you've written for the Amiga. This is
just a moral obligation, something between you and your conscience. Some
amount like $20 or FF 100 would be fine. (Note that you can still use
tracker without paying anything).  My postal address:
     Marc Espie
     60 rue du 4 septembre
     87100 Limoges
     France
   For commercial purposes, please negotiate with me.  @{i}As of today, I
haven't received any contribution... I feel like I'm lacking some
incentive to go on !@{ui}

The most recent version
-----------------------

   In case of trouble, please try to obtain the latest version. This
documentation describes tracker 4.42.

   It is available through anonymous ftp to @{"aminet" Link "aminet"} in the @{b}misc/unix@{ub}
subdirectory or other sources.  Some binaries may be available as well
as the source code.  All recent releases of tracker do display a
version number if started up without other arguments.

My Address
----------

   You can also contact me at the following e-mail address:
     Marc.Espie@ens.fr
   Please try to refrain from contacting me for trivial purposes,
especially questions for which this documentation already contains an
answer.  Encouragements are always welcome, though I would prefer some
real money.  See @{"Reporting bugs" Link "Reporting bugs"}.

Related utilities.
------------------

   Along with tracker, you might also need:
   @{b}*@{ub} some modules

   @{b}*@{ub}     @{b}zoo@{ub} and @{b}lha@{ub} for your machine.

   @{b}*@{ub} the @{b}shorten@{ub} utility.

   @{b}*@{ub} the @{b}ppunpack@{ub} program, available in this archive.


@EndNode

@Node "Registration" "tracker.guide/Registration"
@Next "Reporting bugs"
@Prev "Availability"
@Toc "Main"

Registration
============

   Tracker is @{i}Shareware@{ui}, but it is not crippled in any way.  What you
have got here is the full working version, except if somebody else
tampered with the distribution.

   Tracker registration is just a moral obligation. You can support what
I've done in several ways:
   - By sending me some money.

   - By giving me your software (registered copies of Amiga programs).

   - By porting it to other architectures.

   - By @{"Reporting bugs" Link "Reporting bugs"}.

   It is up to you to decide what to contribute. I would like to get
more money, but I won't force you. Some amount around $20 or FF 100
would be a fine price.  My postal address:
     Marc Espie
     60 rue du 4 septembre
     87100 Limoges
     France
   For commercial purposes, please negotiate with me.

   Even if you don't register because you don't have any money, don't
hesitate to send me praise, postcards, encouragements, bug-reports.

   If  you  have some money, and use tracker a lot, please consider
sending me some money.   I've sunk hundreds of hours into tracker.
This is mostly a passion for me, but it would provide me some incentive
to go on.

   As tracker is somewhat of a collective project, I would also like to
clear some things up: I feel that I've spent much more time developping
tracker than anybody else these days. I consider that all the people
that have helped me along the line (see @{"Credits" Link "Credits"}) have registered by
their work. If I ever get some significant amount of money thanks to
tracker, they will get their share. This doesn't seem likely for the
moment.


@EndNode

@Node "Reporting bugs" "tracker.guide/Reporting bugs"
@Next "Credits"
@Prev "Registration"
@Toc "Main"

Reporting bugs
==============

   Before you report bugs, try to obtain as recent a version of tracker
as possible.

   For @{i}any@{ui} bug-report, @{i}don't forget to include @{i}full@{ui} version information@{ui}
including
   @{b}*@{ub} tracker source version.

   @{b}*@{ub} the architecture on which you've compiled it.

   @{b}*@{ub} any change from the standard distribution as available from @{"aminet" Link "aminet"}.

   In case the problem occured with a specific module, give me full
directions to retrieve the module through ftp, or ask me what you can
do, if it is not available through ftp (I don't like to get binary
files in my e-mail without forenotice).

   I would prefer not to get bug-reports from outdated versions, or
from betas not coming from official beta testers...


@EndNode

@Node "History" "tracker.guide/History"
@Next "Installation"
@Prev "Credits"
@Toc "Main"

History
*******

   Unless you are one of tracker's beta-testers, you should only have
one of the official releases. In case of trouble, @{i}please verify you
have the latest version before contacting me.@{ui}

Release 4.44 @{i}(beta)@{ui}
...................

   @{b}*@{ub} Full documentation included in the package.

Release 4.43 @{i}(beta)@{ui}
...................

   @{b}*@{ub} works on the Amiga again thanks to slight changes. Merging the
     Amiga files into the main distribution slowly....

   @{b}*@{ub} Mixed up @{"Fine portamento up" Link "Fine portamento up"} and @{"Fine portamento down" Link "Fine portamento down"}, thanks Emil
     (see @{"Credits" Link "Credits"}).

Release 4.42 @{i}(beta)@{ui}
...................

   @{b}*@{ub} slight bugs in file reading....

   @{b}*@{ub} put back @{b}transpose@{ub} option where it belonged.

   @{b}*@{ub} experimented with audio dithering for 8 bit output. Removed it,
     does not seem to give better sound quality.

   @{b}*@{ub} option parsing code in order. All old options put back in.

   @{b}*@{ub} bugs with color handling fixed.

   @{b}*@{ub} Amiga version considered temporarily broken due to extensive
     changes.

   @{b}*@{ub} The list option is currently broken.

Release 4.41 @{i}(beta)@{ui}
...................

   @{b}*@{ub} corrected long-standing bug in effect 5.

   @{b}*@{ub} fixed stupid bug in older-style tempo.

   @{b}*@{ub} should compile correctly under solaris.

   @{b}*@{ub} new-style options.

Release 4.40 @{i}(beta)@{ui}
...................

   @{b}*@{ub} the player is now more sensible.

   @{b}*@{ub} added @{b}m@{ub}/@{b}M@{ub} runtime switch (mono/stereo).

   @{b}*@{ub} fixed up minor amiga problems.

   @{b}*@{ub} fixed up the audio recognition loop in the Sparc engine.

   @{b}*@{ub} removed transpose feature as it will be simpler to do it by
     changing sampling frequency and tempo.

   @{b}*@{ub} in case of an older soundtracker module with 15 samples, always use
     old-style set tempo command.

Release 4.39 @{i}(beta)@{ui}
-------------------

   @{b}*@{ub} fixed up data sizes mostly everywhere.

   @{b}*@{ub} added prototypes to @{b}Arch/Sparc/config.h@{ub}, and @{b}#define
     IOCTL_IS_REDUNDANT@{ub} to remove gcc warnings.

   @{b}*@{ub} made porting much easier.

Release 4.38 @{i}(beta)@{ui}
...................

   @{b}*@{ub} checked memory handling thanks to @{b}mung.c@{ub}. Various small memory bugs
     fixed.

   @{b}*@{ub} fixed bug in @{b}run_in_fg@{ub}.  It did sometimes reply that tracker was
     run in bg even though this was false.

   @{b}*@{ub} changed semantics of @{b}sync_audio@{ub}: we need a second function to be
     able to free data in @{b}remove_pending_tags@{ub}.

Release 4.37 @{i}(beta)@{ui}
...................

   @{b}*@{ub} fixed bug with tremolo.

   @{b}*@{ub} total duration working correctly.  Showing up in the title bar for
     xterms.

Release 4.36 @{i}(beta)@{ui}
-------------------

   @{b}*@{ub} the virtual player now computes the total song length.

   @{b}*@{ub} small bug-fixes.

   @{b}*@{ub} documentation rewritten using TeXinfo.

Release 4.35 @{i}(beta)@{ui}
...................

   @{b}*@{ub} start of virtual player: try computing the total song length...
     Not fully implemented yet.

   @{b}*@{ub} some more cleanup as far as note handling is concerned.

   @{b}*@{ub} pulled @{b}randomizer@{ub} inside of main code... now randomize correctly
     across directories. Better @{b}play_list@{ub} handling

Release 4.34 @{i}(beta)@{ui}
...................

   @{b}*@{ub} loads of compression in the song reading. sample numbers get
     remapped and we get rid of most redundant stuff.

   @{b}*@{ub} better memory allocation: does not store pitch any longer.
     Allocates all patterns as one big chunk (shouldn't be a problem
     since it's less than 128K anyway).

   @{b}*@{ub} specific setup for virtual player (soon to be implemented)

Release 4.33 @{i}(beta)@{ui}
...................

   @{b}*@{ub} separated @{b}SPECIAL_NOTE@{ub} (no known pitch) from @{b}NO_NOTE@{ub}.

   @{b}*@{ub} better disk/memory throughput: use @{b}read_file@{ub} where applicable.

   @{b}*@{ub} does not interpret unused patterns. Does not even read them, in
     fact.

   @{b}*@{ub} better event reading scheme: read the whole pattern, then interpret
     each track independently. First step to the virtual player.

Release 4.32 @{i}(beta)@{ui}
...................

   @{b}*@{ub} documentation update.

   @{b}*@{ub} player clean up.

   @{b}*@{ub} Sparc sound engine @{i}more@{ui} powerful.

Release 4.31
------------

   @{b}*@{ub} OS/2 version updated.

   @{b}*@{ub} HP versions updated.

   @{b}*@{ub} SGI minor bug fix.

Release 4.30 @{i}(beta)@{ui}
...................

   @{b}*@{ub} better interface for the Sparc, post-synchronized display, plus
     resample change on the fly. Maybe make it automatic ?

Release 4.29 @{i}(beta, official Amiga)@{ui}
-----------------------------------

   @{b}*@{ub} runs on the Amiga again.

   @{b}*@{ub} fixed up @{i}all@{ui} remaining Protracker problems. All Protracker effects
     are now functional !

   @{b}*@{ub} minor bugs fixed. Nothing serious under Unix, used to crash under
     AmigaOs.

Release 4.28 @{i}(beta)@{ui}
...................

   @{b}*@{ub} partial port to mm1

   @{b}*@{ub} renamed @{b}getopt.h@{ub} to @{b}getoption.h@{ub}

Release 4.27 @{i}(beta)@{ui}
...................

   @{b}*@{ub} minor bug fixes in @{b}Arch/common.c@{ub}. should work correctly on NeXt
     now.

   @{b}*@{ub} xterm stuff cleaned up.

   @{b}*@{ub}     @{b}ppunpack@{ub} is now @{i}officially@{ui} part of tracker. Nico Francois (see
     @{"Credits" Link "Credits"}) @{i}has@{ui} given his benediction.  @{i}You may redistribute @{b}ppunpack@{ub}
     as you wish.@{ui}

Release 4.26 @{i}(beta)@{ui}
...................

   @{b}*@{ub} title in window title bar for @{b}xterms@{ub}.

   @{b}*@{ub} version number cleaned up, now shows up in exactly @{i}one@{ui} place
     (@{b}Makefile@{ub})

Release 4.25 @{i}(beta)@{ui}
...................

   @{b}*@{ub} added remaining Protracker 1.1 effect: @{"Invert loop" Link "Invert loop"} (extended 15).

   @{b}*@{ub} fixed up (mostly) @{"Loop pattern" Link "Loop pattern"} (extended 6).

Release 4.24 @{i}(beta)@{ui}
...................

   @{b}*@{ub} network audio (see @{"NAS" Link "NAS"}) port... probably not working yet.

Release 4.22 @{i}(beta)@{ui}
...................

   @{b}*@{ub} implemented vibrato/tremolo control. See @{"Set vibrato waveform" Link "Set vibrato waveform"}, See
     @{"Set tremolo waveform" Link "Set tremolo waveform"}.

Release 4.20 @{i}(beta)@{ui}
...................

   @{b}*@{ub} notion of data width introduced, fixed some problems (more or
     less).

   @{b}*@{ub} corrected minor bug in @{b}Arch/Sparc/audio.c@{ub}: used to modify the
     volume at exit.

   @{b}*@{ub} some minor changes in commands according to the actual Protracker
     code.

Release 4.19 @{i}(beta)@{ui}
...................

   @{b}*@{ub} more sensible scrolling display.

   @{b}*@{ub} tremolo (see @{"Tremolo" Link "Tremolo"}) finally working.

   @{b}*@{ub} Rolf Grossman's patch (see @{"Credits" Link "Credits"}): cleaned up user interface,
     with less @{b}#defines@{ub}.

Release 4.18 @{i}(beta)@{ui}
...................

   @{b}*@{ub} New Sparc features: @{b}-sync@{ub} support, waiting at start for buffer to
     fill for unhashed audio output.

   @{b}*@{ub} lots of minor bugs everywhere fixed.

   @{b}*@{ub}     @{i}WARNING:@{ui} @{b}oversample=0@{ub} (linear resampling) is probably broken
     right now

Release 4.17 @{i}(beta)@{ui}
...................

   @{b}*@{ub} cleaned up architectural stuff. Even faster.

Release 4.16 @{i}(beta)@{ui}
...................

   @{b}*@{ub} much better optimization in @{b}resample.c@{ub}.

   @{b}*@{ub} optimization of the various @{b}audio.c@{ub} files.

Release 4.15 @{i}(beta)@{ui}
...................

   @{b}*@{ub} added missing @{"Tremolo" Link "Tremolo"} effect...  @{b}guitarslinger@{ub} now sounds
     correctly (I hope).

   @{b}*@{ub} fixed up @{"Set finetune" Link "Set finetune"}... was not updated instantly enough.

Release 4.14 @{i}(internal)@{ui}
.......................

   @{b}*@{ub} PowerPacker depacker.

Release 4.13 @{i}(full release)@{ui}
---------------------------

   @{b}*@{ub} cleaned up small bugs as compared to 4.11.

   @{b}*@{ub} much better technical documentation.

   @{b}*@{ub} upgraded Amiga version to 4.13.

Release 4.11 @{i}(internal release)@{ui}
...............................

   @{b}*@{ub} implemented color ANSI support.

   @{b}*@{ub} NeXt status: working with minor patch.

   @{b}*@{ub} linux status: working.

Release 4.8
...........

   @{b}*@{ub}     @{i}Note for programmers:@{ui} @{b}output_samples@{ub} size @{i}has@{ui} changed to 23
     bits, to allow for 16 bit samples, oversampling, volume, and so
     on...

   @{b}*@{ub} reorganized machine dependent code to @{b}Arch/@{ub}.

   @{b}*@{ub} cleaned up @{b}Makefile@{ub}.

   @{b}*@{ub} implemented buffered files (finally). Faster loading of some
     modules.

   @{b}*@{ub} clutter of includes moved to @{b}defs.h@{ub}.

Release 4.7 @{i}(internal release)@{ui}
..............................

   @{b}*@{ub} small bugfixes.

   @{b}*@{ub} compiling now on other architectures: NeXT, OS9. See
     @{"Architecture dependent problems" Link "Architecture dependent problems"}, See @{"Credits" Link "Credits"}.

Release 4.3
-----------

   @{b}*@{ub} full Amiga support. Good playing model.

   @{b}*@{ub} rewrote @{b}Makefile@{ub}.

   @{b}*@{ub} minor options changes.

   @{b}*@{ub} much easier to tinker with than the previous versions. Hooks for
     future upgrades everywhere.

   @{b}*@{ub} tracker 3.xx is no longer supported. I won't answer to bug reports
     concerning it except to redirect you to the newer version.

Release 3.19
------------

   @{b}*@{ub} Amiga support ! Finally.

   @{b}*@{ub} Solaris 2.2 support.

Release 3.11
------------

   @{b}*@{ub} general bug-fixes, plays some modules it goofed on (speed check,
     extended command @{"Loop pattern" Link "Loop pattern"} now works).

   @{b}*@{ub} repeat working better.

   @{b}*@{ub} should be rather difficult to get cores out of it.

   @{b}*@{ub} may fork when loading a new module, though not working
     satisfactorily yet.

   @{b}*@{ub} almost readable scrolling display.

   @{b}*@{ub} support for DECstations (thanks to @{"Andrew Leahy" Link "Credits"}.)

   @{b}*@{ub} support for hpux (thanks to Bjoern Stabell, see @{"Credits" Link "Credits"}).

   @{b}*@{ub} partial support for solaris.

Release 3.10 @{i}(internal release)@{ui}
...............................

   @{b}*@{ub} linux: small bug-fix, 16 bit support.

   @{b}*@{ub} general: bug in finetune fixed.

Release 3.9 @{i}(internal release)@{ui}
..............................

   @{b}*@{ub} background/foreground csh-aware mode, much cleaner termio.

Release 3.7 @{i}(internal release)@{ui}
..............................

   @{b}*@{ub} support for linux (thanks to Hannu Savolainen, see @{"Credits" Link "Credits"}).

   @{b}*@{ub} small bug fix in @{b}termio@{ub}: restore to a sane tty on exit.

Release 3.6 @{i}(internal release)@{ui}
..............................

   @{b}*@{ub} more efficient replay routine, works faster, all glitches finally
     removed (I hope).

   @{b}*@{ub} more options, better integrated.

   @{b}*@{ub} much cleaner source code.

Release 3.0 @{i}(internal release)@{ui}
..............................

   @{b}*@{ub} tracker knows about  the Sparcstation 10.

   @{b}*@{ub} bug fix for command 5 (see @{"Tone portamento + Volume slide" Link "Tone portamento + Volume slide"}), that
     now works like portamento (see @{"Tone portamento" Link "Tone portamento"}).  Mostly affects
     @{b}apocalypse@{ub} module.

   @{b}*@{ub} support for most protracker extended commands, including finetune.

   @{b}*@{ub} dynamic adjustements to the output frequency, fast skip, much
     better user-response overall.

   @{b}*@{ub} better runtime interface (without those strange signals sequences).

   @{b}*@{ub} better screen output.

   @{b}*@{ub} audio flush on the Sparc, don't have to wait 10sec+ to exit.


@EndNode

@Node "Installation" "tracker.guide/Installation"
@Next "Configure tracker"
@Prev "History"
@Toc "Main"

Installing tracker
******************


 @{" Configure tracker " Link "Configure tracker"}                   to know what you can change
 @{" Generic problems " Link "Generic problems"}                    check these things first
 @{" Architecture dependent problems " Link "Architecture dependent problems"}     if it doesn't work
 @{" Porting tracker " Link "Porting tracker"} 
 @{" Performance issues " Link "Performance issues"}                  to finetune tracker


@EndNode

@Node "Configure tracker" "tracker.guide/Configure tracker"
@Next "Generic problems"
@Prev "Installation"
@Toc "Installation"

Configuring tracker for your machine.
=====================================

   In order to compile tracker, you have to edit the @{b}Makefile@{ub} and
change several entries:

@{i}MACHINE@{ui}
     your type of machine or precise port.

@{i}PREFIX@{ui}
     where installed files will go.

@{i}CC@{ui}
     C compiler to use.

@{i}COMPRESSION_FILE@{ui}
     the default `compression known database' file.

   then type
     make

   @{b}make install@{ub} usually doesn't work, but tracker is quite easy to
install by hand anyway.  If everything didn't work ok, check the
@{"Generic problems" Link "Generic problems"} section.

   The only important part is to get @{i}MACHINE@{ui} and @{i}CC@{ui} right. Since Unix
installation tend to vary, you may have to delve further into the
Makefile and modify compiler switches.


@EndNode

@Node "Generic problems" "tracker.guide/Generic problems"
@Next "Architecture dependent problems"
@Prev "Configure tracker"
@Toc "Installation"

Program organization
====================

   Most files are system independent, with some exceptions.

The @{b}Arch@{ub} directory.
     holds a @{b}config.h@{ub} and an @{b}audio.c@{ub} for every configuration tracker
     has been compiled on.  @{b}config.h@{ub} specifies various things about the
     machine.  @{b}audio.c@{ub} is the audio driver itself.

@{b}Arch/Unix/ui.c@{ub} and @{b}Arch/OS2/ui.c@{ub}
     provide some `user interface' under Unix or OS/2.  Mainly deals
     with raw mode and stuff like that, plus color xterms recently.

The @{b}Amiga@{ub} directory
     the Amiga version of tracker holds more system specific code than
     the other versions. Namely, the audio drivers hooks in at the
     Amiga audio driver level (bypasses @{b}resample.c@{ub} completely, See
     @{"Amiga audio hardware" Link "Amiga audio hardware"}, See @{"Resampling details" Link "Resampling details"}, See
     @{"Amiga implementation" Link "Amiga implementation"}, for details).

   If you need to understand how tracker works, a good place to start
with is @{b}extern.h@{ub}, which holds commented prototypes for most functions.
Also, See @{"Resampling details" Link "Resampling details"}.

Generic problems
================

My computer barfs on the @{b}Makefile@{ub}
     your @{b}make@{ub} probably doesn't understand nested macros, like @{b}CFLAGS =
     $(CFLAGS_${MACHINE})@{ub}
    Quick fix
          edit the @{b}Makefile@{ub} and replace @{b}CFLAGS@{ub} and others with their
          definition, i.e., for a Silicon Graphics machine: @{b}CFLAGS_sgi
          = -O2@{ub}

    Real fix
          install a real @{b}make@{ub}, like @{b}gnumake@{ub}.

What's @{b}stricmp@{ub} ?
     that's `@{b}strcmp@{ub} without caring about cases'. On some machines,
     there is a function called @{b}strcasecmp@{ub} instead.  A @{b}#define
     strcasecmp@{ub} in your machine's @{b}config.h@{ub} will be enough.  If you
     really don't find it, it's easy to roll your own, or even replace
     it with @{b}strcmp@{ub} at low cost.

tracker does not recognize any module
     maybe the decompression isn't working correctly. First try out
     tracker with uncompressed modules. Be aware that tracker doesn't
     support XPK modules, and has only external support for
     PowerPacker. To achieve support for lha and other standard
     compressed formats, there is a good chance you'll have to edit the
     @{b}COMPRESSION_FILE@{ub} and install some utilities.  Also, don't forget
     that tracker supports only Soundtracker/Protracker modules for the
     time being.

I don't get any sound.
     Don't forget to check that your machine is audio capable. Do you
     have a sound card ? Do you manage to get sound out of other
     programs ? Is your loudspeaker hooked in ? Does your machine
     output sound through headphones by default ? Is the audio package
     installed... Sounds stupid, but this is the most probable problem.
     Try to keep a key depressed: if you get some hashed sound output,
     the user interface is broken. You'll have to check how to put your
     tty in cbreak mode.  Check the @{b}HAS_TERMIOS@{ub} and @{b}HAS_SGTTY@{ub} entries.

   If tracker doesn't compile more or less cleanly, check that it
pulled the right @{b}config.h@{ub} file, and check the definitions in that file.

   If you manage to get sound output from tracker, but if the result is
garbled you probably need to check @{"Performance issues" Link "Performance issues"}.


@EndNode

@Node "Performance issues" "tracker.guide/Performance issues"
@Next "Usage"
@Prev "Porting tracker"
@Toc "Installation"

Sound output problems
=====================

   @{i}Warning: most of these problems can only be fixed by changing the
code of tracker... non-programmers, beware !@{ui} You might wish to get a
look at @{"Resampling details" Link "Resampling details"} at this point.

The output is hashed
     your machine is not fast enough for the quality you ask.
     Experiment with optimizer flags. Try another compiler (gcc gives
     faster code on the sparc in this case). Downgrade the output
     frequency with -freq. Don't use scrolling display. Use -mono,
     especially when you have only one loudspeaker anyway :-)

The output sound like white noise
     Maybe you are trying to output 16 bit samples when your hardware
     supports 8 bits. Or you have overflows all the time. Or you are
     outputting unsigned data when your hardware expects signed data.
     You'll probably have to hack your own audio driver.

There are bursts of static through normally audible output
     Overflow. Your sound engine outputs, for instance, 9 bit data when
     your hardware expects 8 bits.

The output is strangely distorted
     Most probably, you are doing 16 bit linear to ulaw conversion,
     which coincidentally outputs 8 bit data which doesn't sound @{i}that@{ui}
     garbled if your hardware expects 8 bit linear.  Modify your sound
     engine to output 8 bit linear.

The output is still distorted and I'm using ulaw
     ulaw isn't that great a format for music output. Try to coerce
     your hardware to output linear data. If you can't, try oversample.
     Might sound a little better. Sorry about that.

Specific modules problems
=========================

Tracker doesn't recognize some modules
     Remember that tracker won't handle compressed modules unless
     carefully installed, and that you have to use @{b}ppunpack@{ub} to depack
     PowerPacked modules. Also, tracker doesn't yet know how to play
     MED, S3M, or xm modules.

Tracker barfs on some modules
     Try @{b}-tolerant@{ub}. If it still doesn't work, send a bug report.

The module doesn't sound like it should
     Check that carefully. Make sure you were using the right player on
     an Amiga.  Double check with several players if possible. If you
     still have something weird, you may have a bug. Try e-mailing me.

     The only thing I can't implement is the on/off switching of the
     low-pass filter for obvious reasons.


@EndNode

@Node "Architecture dependent problems" "tracker.guide/Architecture dependent problems"
@Next "Amiga"
@Prev "Generic problems"
@Toc "Installation"

Specific architectures problems
===============================


 @{" Amiga " Link "Amiga"} 
 @{" DECstation " Link "DECstation"} 
 @{" HP-UX " Link "HP-UX"} 
 @{" Linux-FreeBSD " Link "Linux-FreeBSD"} 
 @{" MM1-OS9 " Link "MM1-OS9"} 
 @{" NAS " Link "NAS"} 
 @{" NeXtStep " Link "NeXtStep"} 
 @{" OS-2 " Link "OS-2"} 
 @{" Silicon Graphics " Link "Silicon Graphics"} 
 @{" Sparc " Link "Sparc"} 

 @{" Other Architectures " Link "Porting tracker"} 


@EndNode

@Node "Amiga" "tracker.guide/Amiga"
@Next "DECstation"
@Prev "Architecture dependent problems"
@Toc "Architecture dependent problems"

Amiga
-----

   There is currently one Amiga version running under AmigaDos.  An
adaption of the @{"Linux-FreeBSD" Link "Linux-FreeBSD"} version to run under Amiga Linux or Amiga
netbsd would probably be reasonably simple, the most difficult part
being to get a working audio device.

   The status of the current version is experimental. I most often work
on a Sparc in my school, and can't check on my Amiga except during
vacations.

   Version 4.36 compiles cleanly with SAS/C and smake. It probably
doesn't compete with HippoPlayer or Delitracker. Its only advantages
are in terms of compatibility. I've taken steps to be dead sure that
tracker uses the system and only the system, isn't a CPU-hog and works
with terminal programs (and any weird hardware that hooks on the CIAs
for that matter).  Also, tracker probably will still run with new
Amigas with PA-Riscs or something, since all the code is in C.

   You will need to install KingCon on your machine. It is also a good
idea to replace the standard queue-handler with the one bundled with
HWRCS unless you don't intend to use compressed modules.

   See the Amiga version as an unobtrusive module player without bells
and whistles, a quick way for me to check that everything sounds as it
should.

   There might still be memory bugs lurking, so if tracker crashes, get
a more reliable module player, or hack the source.

   Some known problems
The user interface doesn't seem responsive at the end of modules
     Due to the asynchronous nature of tracker implementation.
     Computations for the current song are actually finished. The
     interface is locked waiting for the song to end in order to be
     able to release the memory used for sound samples.  I will need to
     add much smarter code to handle that: the player sits at a point
     where it has the last song loaded, is ready to unload it and load
     the next one. Just loading the next one before unloading the
     current one is not a good idea, since it consumes too much memory.

The scroll window doesn't open when I ask for it
     Performance reasons and  implementation hack. Scrolling
     information is only computed when you ask for the scroll window,
     and the scroll window opens magically when some scrolling
     information is ready.  Since the sound is buffered, you first have
     to listen to all the buffered sound before the scroll window
     appears.

I have 1.3 and tracker doesn't run
     Upgrade...

I'm confused about the menu speed items
     Their state doesn't accurately reflect what's going on, but PAL
     and NTSC work (once again, since the sound is buffered, there's
     some delay).  Custom is just a provision for the future.

The sound filter is always off
     Not implemented yet, even for the amiga !!!

Tracker doesn't understand powerpacked modules
     It doesn't need to. Install xpk and xfh and it'll work.

Tracker is much bigger than some other players and takes up more memory.
     But it should work on every amiga, is CPU-efficient, and supports
     some unique features.
        @{b}*@{ub}    plays lha modules

        @{b}*@{ub}    transpose modules

        @{b}*@{ub}    scroll-window, somewhat more readable than just plain
          ciphers.  It is also portable.

The Invert loop effect sounds weird
     too difficult to implement properly (call back...) right now

Tracker loses some memory sometimes
     There seems to be a bug with the @{b}CON:.../AUTO/WAIT@{ub} windows that
     stay around forever under the 3.1 beta I've got on my system.  I
     haven't been able to check whether the problem stays under other
     system versions.  As I said, the current release is experimental.


@EndNode

@Node "DECstation" "tracker.guide/DECstation"
@Next "HP-UX"
@Prev "Amiga"
@Toc "Architecture dependent problems"

DECstation
----------

   That port hasn't been upgraded for a loong time, so it will
certainly need extensive surgery to work.

   It uses a package called @{b}AudioFile@{ub}. It is a public domain audio
package available from DEC @{b}crl.dec.com@{ub} aka 192.58.206.2, @{b}/pub/DEC/AF@{ub}.
the software will run on a number of platforms: Sun/NeXT/SGI/DEC.  The
@{b}AF_audio.c@{ub} code sends the sound directly to the AudioFile server.
There is but a slight problem! It Seg Faults when closing the Audio
connection... dunno why, haven't been able to get rid of it!  Uses 2
environment variables:
@{b}AUDIOFILE@{ub}
     the name of the audio server to connect to for mono playback. And
     for the Left Channel in stereo playback. eg. @{b}"machine:0"@{ub}

@{b}AUDIORIGHT@{ub}
     the name of the audio server for the Right Channel when playing
     stereo.  This code is only tested for DEC 5000/20, 5000/25, Ultrix
4.2, Ultrix 4.3...  so I can't vouch for how well it'll work on other
machines !


@EndNode

@Node "HP-UX" "tracker.guide/HP-UX"
@Next "Linux-FreeBSD"
@Prev "DECstation"
@Toc "Architecture dependent problems"

The HP ports
------------

   There are currently three ports:

   hp3, hpalib and hplow. I've only been able to check personally
hplow, which is a horrible hack which accesses the audio hardware
directly, since hplib is not installed here. hpalib and hp3 are mostly
equivalent (done by different persons).

   Difference between hp3 and hpalib (by Bjoern Stabells, see @{"Credits" Link "Credits"}):
   -  my port, hpalib, uses AConvertBuffer(), while hp3 doesn't.  I'm
     actually not sure if it's necessary. :)

   - hp3 also supports 8bit linear, while hpalib only supports 16bit
     linear

   - hpalib does a 3 second wait to let the audio stream fill up, while
     hp3 doesn't, resulting in uneven playback (silent gaps in the
     music)

   - hp3 rounds the frequency to always use a legal frequency, while
     hpalib really should be able to handle all frequencies, but doesn't
     right now.

Old documentation for the hp3 port
..................................

   This documentation was written by Darryl Okahata, See @{"Credits" Link "Credits"}.

   @{i}NOTE: this is still undergoing development, and will probably be
enhanced, as some parts don't work very well.@{ui}

   This is a port of tracker, version 3.19, to HP-UX 7x5 machines with
audio devices that can handle 16-bit CD-quality stereo audio.  Tracker
plays Amiga MOD files, which are generally of much higher quality than
most computer music that most people have heard (however, MOD files
still aren't excellent in terms of sound quality--they are merely "very
good").

   Note that you must have an audio device that supports stereo and
16-bit data.  Other audio output devices are not supported, although
support may be added in the future.

   You also need HP-UX 9.01 to use this program, and you must have set
up audio services on your 7x5 workstation.  See the audio services
manual to see how to set this up.

Quickstart instructions:
........................

  1. Put these files in some convenient directory.  The tracker binary
     contains no hard-coded paths, and can be placed anywhere.

  2. The files whose names end with ".mod" are Amiga "MOD" files, which
     contain instructions on how to play a song.  Each .mod file is one
     song.

  3. To play a song to the headphone jack, do (for example):
          	tracker -volume -20 -mix 40 boesen.mod
        (You may have to add paths to the tracker binary or to
     @{b}boensen.mod@{ub})

     If you want the song to be output to the internal speaker, do:

          	tracker -speaker -volume 0 -mix 40 boesen.mod

     @{i}Important: do not use a volume level of zero (0) if you are
     listening using headphones.  A volume level of zero is loud, and
     could conceivably cause damage to your hearing.@{ui} Frankly, you
     probably shouldn't use anything above -5 if you are listening using
     headphones.


Other notes:
............

  1. The volume is specified in dB, and the default volume setting is
     -20dB.  Note that setting the volume to -5dB and higher could
     conceivably cause damage to your hearing if you listen to mod files
     using a headphone.

  2. After running tracker, X-Windows (vue) can no longer beep.  I have
     no idea why, although I'm looking into this.


@EndNode

@Node "Linux-FreeBSD" "tracker.guide/Linux-FreeBSD"
@Next "MM1-OS9"
@Prev "HP-UX"
@Toc "Architecture dependent problems"

Linux/FreeBSD ports
-------------------

   This port only concerns the PC versions of Linux and FreeBSD, as I
haven't been able to check what kind of audio driver there is on the
Amiga.

   The program currently needs to be told about your audio hardware (8
bits/16 bits, @{b}dsp_samplesize@{ub} constant in @{b}Arch/Pcux/audio.c@{ub}).  It should
be possible to analyze that automatically with the recent drivers
versions.  Also, you might need to fiddle with @{b}UNSIGNED8@{ub} and stuff (I
hope not).  In any case, do not try replacing @{b}/dev/dsp@{ub} with @{b}/dev/audio@{ub}
...  @{b}/dev/audio@{ub} is a sun-compatible driver that only accepts ulaw audio.
It's possible to modify tracker to output ulaw output, but in that case
it's stupid, since the whole shebang will go linear16bit, ulaw,
linear8/16bit, losing @{i}both@{ui} resolution @{i}and@{ui} cpu time.

   Since Linux/FreeBSD audio drivers change rapidly, check that your
audio driver is recent before blaming anything on tracker.

   If you have a problem which is specific to the Linux/FreeBSD port,
check with Hannu Savolainen (see @{"Credits" Link "Credits"}).


@EndNode

@Node "MM1-OS9" "tracker.guide/MM1-OS9"
@Next "NAS"
@Prev "Linux-FreeBSD"
@Toc "Architecture dependent problems"

MM1 Port
--------

   The plain MM/1 is a bit too slow to enjoy tracker in full.  Be
patient when you start--it takes a lot of time to initialize.  When the
processor is not fast enough, pauses will occur during playing.  This
can often be cured by selecting a smaller reproduction sampling
frequency with the command line parameter @{b}-frequency@{ub}.

   Mono output mode has been disabled since the MM/1 output is stereo.
To save the processor time in the critical loop, mixing between the left
and right channels has been disabled.

   The original program sends output to the sound driver in relatively
small pieces. I found that the quality of the output is improved when
the sound is played only if the buffer is full. The price for this is
that the tracker reacts rather slowly to the keyboard commands when
playing. The code in question is in the @{b}flush_buffer@{ub} function--it is
disabled right now.  If you prefer the faster keyboard reaction at the
cost of the quality, you may reenable it and recompile.

   Playing on MM/1 is done using the system call @{b}_ss_play@{ub} and using two
buffers, so that when the first buffer is played, the other is being
filled.


@EndNode

@Node "NAS" "tracker.guide/NAS"
@Next "NeXtStep"
@Prev "MM1-OS9"
@Toc "Architecture dependent problems"

Network Audio (NAS) port
------------------------

   The event oriented nature of NAS programming dictated a rather
unusual solution. Because NAS is built around an event loop, it demands
to be in control of the application. Instead of massively patching
tracker, or using co-routines with occasional snoops on the event queue
in order not to miss events, the port uses @{b}fork@{ub} with processes
squirting data down a pipe. The back end handles all the netaudio stuff,
processing events and requesting data from the pipe when necessary.
The front end waits until the backend returns an int saying what the
max frequency is (or 0 if it fails to make a connection).  Then it runs
along producing data and stuffing it down the pipe as normal.


@EndNode

@Node "NeXtStep" "tracker.guide/NeXtStep"
@Next "OS-2"
@Prev "NAS"
@Toc "Architecture dependent problems"

NeXtStep port
-------------

   There used to be a problem with big endians/little endians machines.
It should be solved these days. Look around in @{b}Arch/Next/audio.c@{ub} for
@{b}SNDSwapSoundToHost@{ub}.

   Please double-check that your machine does support audio output, as
this is not the case with all NeXtStep machines.

   In case you have a problem that is specific to the NeXtStep port,
you might ask Rolf Grossman (see @{"Credits" Link "Credits"}).

   The NeXTstep port of tracker was originally done on m68k hardware,
but other people have tried it on the other NeXTStep platforms as well
(and submitted patches when necessary ).

   These are the main changes Rolf had to make, in case someone is
interested:

   @{b}*@{ub} Added support for sgtty ("old" BSD) style terminal settings to
     @{b}Arch/Unix/ui.c@{ub}.  Also cleaned this up and made it architecture
     independent.  Verified that it works on Suns, too. See
     @{b}Arch/config.h.sample@{ub} for the way to use it.

   @{b}*@{ub} Created a new variable @{b}play_ahead@{ub} that tells how many buffer blocks
     are queued before waiting for the sound to actually play. The
     buffering is required to ensure continous play, even if the
     program is not running continously (like when you're actually
     working with the computer) the value could have been settable with
     a command line option, but this would be architecture dependent.
     Instead it uses the environment variable @{b}BUFFER_BLOCKS@{ub} right now.

   @{b}*@{ub} Added call to @{b}SNDSwapSoundToHost@{ub} before actually playing the
     sound, so it should work on NS/intel now.

   @{b}*@{ub} Thanks to recent changes to the @{b}Makefile@{ub} it should even work with
     NeXT's native make (at least it does for Rolf).


@EndNode

@Node "OS-2" "tracker.guide/OS-2"
@Next "Silicon Graphics"
@Prev "NeXtStep"
@Toc "Architecture dependent problems"

OS/2 port
---------

   I'm not aware of any problem. Everything uses the same drivers as for
Linux/FreeBSD (almost). Ask Bruno Monsuez directly.


@EndNode

@Node "Silicon Graphics" "tracker.guide/Silicon Graphics"
@Next "Sparc"
@Prev "OS-2"
@Toc "Architecture dependent problems"

Silicon Graphics port
---------------------

   Maybe you don't have any audio software. If you can't find audio
include files/libraries that's a good bet.

   Irix 5.3 includes the audio package as a default again. If you were
using Irix 5.2 or lower, upgrade. If you are using Irix 5.3, check that
the audio @{i}has@{ui} been installed.  Also, the standard SGI @{b}make@{ub} is crippled.
See @{"Generic problems" Link "Generic problems"}.

   If the audio output sounds like garbage, you probably botched the
@{b}typedef@{ub} of @{b}SAMPLE@{ub}. chars on Silicon Graphics are @{b}unsigned@{ub} by default,
and @{b}SAMPLE@{ub} needs to be @{b}signed char@{ub} (1).  This can happen very easily if
the @{b}config.h@{ub} tracker uses is not the Silicon Graphics one. Remove the
@{b}config.h@{ub} in the main directory, and let make replace it with the
correct one.

   ---------- Footnotes ----------

   (1)  I have not put this in every @{b}config.h@{ub} for compatibility with
old K&R compilers


@EndNode

@Node "Sparc" "tracker.guide/Sparc"
@Next "Porting tracker"
@Prev "Silicon Graphics"
@Toc "Architecture dependent problems"

Sparc port
----------

   The Sparc version is probably the most tested since this is the
architecture I happen to develop tracker under.

   Tracker has run on Sparc 1, 1+, 5, 10, 20, under both SunOS 4.3 and
Solaris 2.x.  There are still problems though, thanks to the brain
damaged way Sun are running their business (insert your favorite
expletives here).

   In case you don't have acc (ANSI C compiler), tracker also works
with the old K&R cc and also with gcc.  In fact, it is recommended to
compile tracker with gcc as gcc optimizes tracker better.

   If you have Solaris 2.x, use target name @{b}solaris@{ub} instead of @{b}sparc@{ub}
(thanks to Dave Tiller, See @{"Credits" Link "Credits"}.) include file names may change
between @{b}sun/audioio.h@{ub} and @{b}sys/audio.io.h@{ub} or some other weird
combination. Ask sun about that !

   If you don't hear any sound, don't forget to check that the Sparc
isn't sending its output to the audio jack instead of the headphones.

   There is a bug in older kernels of Sparc 5 that sometimes crashes
the machine when you play with @{b}ioctl@{ub} and @{b}audio@{ub}.  It's easy to check:
run tracker twice in quick succession. If the machine seems to hang
five seconds when lauching tracker the second time, you have it !
Upgrade, or you run the risk of crashing your machine !

   There is some intricate code in @{b}Arch/Sparc/audio.c@{ub} to check for the
precise hardware used in your Sparc.

   The @{b}AUDIO_GETDEV@{ub} ioctl changed between SunOs 4 and Solaris 2, hence
the two distinct checks.

   In case the code doesn't recognize your hardware, it reverts to base
8000Hz Ulaw, unless you explicitly asks for a different frequency. It
also informs you about what hardware you have. Report the result to me
together with your audio manpage, and I'll fix it for the next release
of tracker.

   For the adventurous, there is a possible change to tracker which I
haven't put into the Makefile because it's too complicated. It turns
out that tracker is linked with @{b}-static@{ub} because this consumes much less
cpu in the critical modules. In fact, these critical modules are just
@{b}resample.o@{ub} and @{b}Arch/Sparc/audio.o@{ub}. If you feel like it, you can use
your linker separately to link these statically (something like @{b}ld
-Bstatic -onew.o resample.o Arch/Sparc/audio.o@{ub}) and then link the whole
executable dynamically.

   On my setup, tracker shrinks from 188416 to 73728 bytes without any
performance degradation.


@EndNode

@Node "Porting tracker" "tracker.guide/Porting tracker"
@Next "Performance issues"
@Prev "Sparc"
@Toc "Installation"

Porting tracker to another architecture
***************************************

   If possible, you should use the same coding conventions as I do.
   @{b}*@{ub} All of tracker source code is archived with @{b}RCS@{ub}. Use @{b}RCS@{ub} to
     maintain tracker if you can.

   @{b}*@{ub} For me, tabs correspond to three spaces.

   @{b}*@{ub} Standard file header:
          /* st_read.c
             vi:ts=3 sw=3:
           */
          
          /* $Id$
           * $Log$
           * Revision 1.1  1995/09/03 15:44:31  espie
           * Initial revision
           *
           */
          
          /* description of the file if applicable */
          #include "defs.h"
          
          #include <system_files>
          
          #include <extern.h>
          
          ID("$Id$")
     The @{b}$Id$@{ub} and @{b}$Log$@{ub} entries are filled by RCS. @{b}defs.h@{ub} includes some
     standard header files: @{b}config.h@{ub}, @{b}stdio.h@{ub}, @{b}stdlib.h@{ub}, @{b}string.h@{ub}. It
     also includes some useful standard definitions. You are advised to
     read it.

   @{b}*@{ub} My C is ANSI, but should be acceptable to K&R compilers. This means
     that prototypes use the form @{b}function P((int param));@{ub}, where @{i}P@{ui}
     expands to a prototype or a @{b}()@{ub} according to @{b}config.h@{ub}, and that
     actual function declarations should use old type prototype.

   @{b}*@{ub} Tracker uses ANSI functions, with some smattering of Unix-isms
     where applicable. Be aware that tracker should stay portable, try
     to use ANSI C functions whenever possible, and to encapsulate
     system functions where needed.

   @{b}*@{ub} Tracker needs a decent address space, not a small model IBM PC.

   There are several parts of tracker that need porting.

The audio interface
===================

   In case samples need to be in a specific part of memory, add @{b}#define
SPECIAL_SAMPLE_MEMORY@{ub} to @{b}config.h@{ub} and provide suitable @{b}alloc_sample@{ub} and
@{b}free_sample@{ub} functions as per @{b}extern.h@{ub}.

   If your audio hardware cannot emulate an Amiga directly (see
@{"Amiga audio hardware" Link "Amiga audio hardware"}), you will have to use resampling, See
@{"Resampling details" Link "Resampling details"}.

   Basically, you will build a specific @{b}audio.c@{ub} file for your
architecture that holds two important functions:

   @{b}open_audio(freq, stereo)@{ub} opens the audio hardware for a given
resampling frequency, and stereo or mono mode. This returns the actual
resampling frequency nearest to the frequency asked that will actually
be used. For your first try, open the audio channel in a suitable
stereo or mono mode at a fixed rate.

   @{b}output_samples(left, right, n)@{ub} adds two audio samples to the stream
in progress. Both samples have n bit resolution.

   Other functions in @{b}audio.c@{ub} as documented in @{b}extern.h@{ub} can mostly be
replaced by suitable stubs.

   You have some templates of suitable configuration files in the
directory @{b}Arch/Port@{ub}. Specifically, this @{b}config.h@{ub} removes most of
tracker system dependencies. @{b}ui.c@{ub} is a minimal user interface file that
needs only stdio to work, and @{b}audio.c@{ub} is a minimalist audio interface
derived from the Sparc audio interface.

   Create a directory for your architecture, copy these files there,
update the @{b}Makefile@{ub} to add an entry for your architecture. You need to
edit @{b}config.h@{ub}, since as shipped it doesn't work, and to implement the
base functions as discussed in @{b}audio.c@{ub}. Don't forget to use the set of
routines in @{b}common.c@{ub}. With them, you can get most audio hardware
running.

   When this part works, try to implement the remaining of the audio
functions.  First, try to have parameters working, like different
sampling rates, mono and stereo, then try to add the advanced features.

The user interface
==================

   Once the audio works, try to fix the user interface up.  If your
system looks like a standard Unix, you'll just have to discover how to
put your terminal in cbreak mode....  Usually, the @{b}Arch/Unix/ui.c@{ub} file
together  @{b}#define USE_SGTTY@{ub} or @{b}#define USE_TERMIOS@{ub} will be enough.  If
you are not under Unix, this might be more difficult.  Also note
@{b}run_in_fg@{ub}, which decides whether to do all this stuff or not, since
background processes tend to fail if they try to output something.

   Recently, I've added support for xterms (triggered by @{b}PREF_XTERM@{ub})
and for colour terminals (triggered by @{b}PREF_COLOR@{ub}).  @{b}PREF_XTERM@{ub} is set
by the @{i}TERM@{ui} environment variable in @{b}main.c@{ub}, @{b}PREF_COLOR@{ub} is set according
to the compilation switch @{b}COLOR_IS_DEFAULT@{ub}. Note that both these
settings may be overriden by command line options.

   If your machine uses another color model, you will have to add
suitable definitions to @{b}color.c@{ub}. Note that I'm not satisfied with the
way color currently is defined, so I might change this stuff.

File systems
============

   To support compression, your system must have popen and pclose. If
it does not, you'll have to modify @{b}open.c@{ub} extensively if you want
compression.  Try to remove @{b}#define NO_PIPES@{ub} from @{b}config.h@{ub} and recompile
@{b}open.c@{ub} to check whether compression works or not.  You'll also have to
adapt @{b}compression_methods@{ub} to your system.

   I'm currently investigating into a more supple variant of tracker
that would use sockets instead, so that all the decompression shebang
would lie with a perl script (that could also cache file, access the
network, and everything).

   You also need @{b}stat@{ub}, @{b}S_ISDIR@{ub}, @{b}readdir@{ub} for the automatic expansion of
directories in @{b}play_list.c@{ub} to work(1).

Beyond the simple port
======================

   I would like some people to work on more interesting ports. The
Amiga version of tracker, for instance, includes some significant
improvements, but I have no time myself to be writing an X-Window port
of tracker.  Due to the asynchronous nature of tracker, the audio
output is usually buffered. Some events, like the scrolling display,
should occur when the corresponding audio event is played. The Amiga,
Sparc, and NeXT versions include a post-synchronization function. They
use the @{b}sync_audio@{ub} function(2)

   Basically, @{b}sync_audio@{ub} inserts a hook into the audio pipeline: a
function to call, with some parameters, when the audio stream finally
reaches the current point. More precisely, there are two functions: one
to call when the audio stream reaches this point, and an alternate
function to call to clean up if the audio stream never reaches this
point. For instance, when you depress @{b}n@{ub} on the keyboard, it would be
most unpractical to have all the accumulated scrolling info suddenly
appearing on the screen, so it is flushed. But there is some memory
accounting involved, hence the flushing function calls @{b}free@{ub} on each
line involved.

   ---------- Footnotes ----------

   (1)  I'm going to make this much more portable soon

   (2)  Well... the Amiga version does not, but it should.  I just
haven't updated it yet.


@EndNode

@Node "Usage" "tracker.guide/Usage"
@Next "Technical Information"
@Prev "Performance issues"
@Toc "Main"

How to use tracker
******************

Compression
===========

   Various compression methods are supported through pipes.  There is a
simple-minded configuration file @{b}compression_methods@{ub} (check @{b}Makefile@{ub} to
see where you want to install it). Its format is:
     extension              command line in printf format.

   For instance,
     .gz	gzip -dc %s
   (simple, isn't it ?)

Environment variables
=====================

TRACKER_DEFAULTS
     The set of options invoked by default, e.g., my options are
          -scroll -freq 44 -color -tolerant

MODPATH
     A path where you wish to look for mod files. This is a sh-styled
     path: setenv MODPATH dir1:dir2:...

TRACKER_COMPRESSION
     Overrides the default @{b}compression_methods@{ub} file... Very useful
     when, for example, you want to use a binary fetched from the net.

Command line switches:
======================

   Note that tracker now accepts directories as arguments. It will
automatically recurse down the tree to find modules.
@{b}-stereo/-mono@{ub}
     switch between stereo and mono output. Some modules need mono
     output to sound right. Apart from that, on stereo-capable
     machines, mono output uses less CPU usually.

@{b}-mix <percent>@{ub}
     for stereo output, decide how to mix left/right channels.  0 is
     spatial stereo, 100 is mono. The change tends to be exponential,
     so you may want to experiment with values around 90+.

@{b}-frequency <freq>@{ub}
     set the audio utput frequency (kHz). The normal output frequency
     is a `normal' frequency for your machine. Normally <freq> will be
     rounded to an actual output frequency available on your machine.

@{b}-oversample <n>@{ub}
     where n is usually 1, 2 or 4. Controls the accuracy of the sound
     reproduction by trying to use 1,2 or 4 sample values to render a
     given sample. The higher, the better, but the more CPU it uses.
     Changing the frequency usually works better, but there are cases
     where 2 or 4 will give you a better rendering for some module.
     The default value (1) is quite good at high frequencies, but not
     so good on, for instance a sparc station 1 at 8000 Hz.  The code
     in @{b}resample.c@{ub} is optimized to get oversample 2 and 4 to be
     reasonably efficient... After 4, you probably won't hear any
     significant improvement.  0 is a special mode, called linear
     resampling. See @{b}resample.c@{ub} for details.

@{b}-new/old/both@{ub}
     select a soundtracker format, between new (31 instr), old (15
     instr) and both (auto-detect what's going on). You should only use
     it if tracker gets very confused on a module.

@{b}-picky@{ub}
     do not allow for any problems in a module.

@{b}-tolerant@{ub}
     allow for many problems that would normally stop a module

@{b}-repeats / -repeats <n>@{ub}
     repeat each module n times. With no value (or a 0), repeat the
     module forever.

@{b}-looping@{ub}
     make module list loop as a whole.

@{b}-verbose@{ub}
     show a sample listing for the module.

@{b}-scroll@{ub}
     scroll-display the module being played.

@{b}-color/-bw@{ub}
     use with terminals with color-ansi capability (e.g., kterm) to get
     a colorful scroll.

@{b}-speed <n>@{ub}
     change the base tempo to n. The normal value is 50 (PAL video
     frequency). Some modules have been written on a buggy NTSC
     composer, so you may wish to use -speed 60. Weird values like
     -speed 10 or -speed 2000 are allowable.  Note that the samples may
     sound a bit strange since you only change the tempo, but the
     samples till play at the same speed.

@{b}-pal/-ntsc@{ub}
     PAL or NTSC tempo. Shortcut for the @{b}speed@{ub} option.

@{b}-speedmode (normal|old|finefirst|normalfirst|alter)@{ub}
     compatibily hack for old soundtracker tunes and various variants.
     @{b}old@{ub} (also known as VBLANK mode) will force all speed commands to
     affect only the major tempo. @{b}alter@{ub} is an alternate version of the
     automaton found in some soundtracker tunes. Other options are
     mostly there for debugging purposes.

@{b}-transpose <k>@{ub}
     transpose the song up k half-notes. If k is negative, obviously
     transpose the song down. The results will vary according to the
     module. This command changes only the pitch independently from the
     speed, so modules which use samples as `strictly instruments' will
     work better. Of use when you get bored....

@{b}-start n@{ub}
     start the module at pattern number n instead of number 0.

@{b}-randomize@{ub}
     plays the module list in random order.

@{b}-list file@{ub}
     plays the modules listed in the given file (one module name per
     line, spaces are significant).

Sample control
==============

@{b}-cut 012...abcd@{ub}
     suppress samples from the audio output.

@{b}-add 012...abcd@{ub}
     add samples to the audio output (exclusive with cut).

@{b}-halve 012...abcd@{ub}
     halve these samples volume.

@{b}-double 012...abcd@{ub}
     double these samples volume (exclusive with halve).

Runtime controls
================

@{b}n@{ub}
     go to next song.

@{b}p@{ub}
     restart current song/go to previous song.

@{b}>@{ub}
     fast forward.

@{b}<@{ub}
     rewind.

@{b}S@{ub}
     NTSC tempo (60 Hz). @{"Amiga audio hardware" Link "Amiga audio hardware"} for the reason this
     exists.

@{b}s@{ub}
     PAL tempo (50 Hz).

@{b}q@{ub}
@{b}x@{ub}
@{b}e@{ub}
     quit right away.

@{b}m@{ub}
     switch to monaural mode.(1)

@{b}M@{ub}
     go back to stereo mode.

@{b}+@{ub}
     (Sparc only) increase sampling rate.(2)

@{b}-@{ub}
     (Sparc only) decrease sampling rate.

   ---------- Footnotes ----------

   (1)  This key is equivalent to @{b}-mix 100@{ub}, i.e., it does not reduce
the CPU bandwidth used by tracker as when in true mono mode.

   (2)  Warning: there is a bug in the SunOS 4.1.3 kernel that may
manifest itself when using this option


@EndNode

@Node "Technical Information" "tracker.guide/Technical Information"
@Next "Tracker memory consumption"
@Prev "Usage"
@Toc "Main"

Technical information
*********************

   Throughout tracker, I'm trying to establish a trend of well
thought-ou and intelligent music playing programs.  Tracker's code is
relatively high-level, and I'm trying my best to substitute an
intelligent approach to the traditional `brute-force' system of ASM
playing routines.


 @{" Tracker memory consumption " Link "Tracker memory consumption"} 
 @{" The Protracker format " Link "The Protracker format"} 
 @{" Amiga audio hardware " Link "Amiga audio hardware"} 
 @{" Resampling details " Link "Resampling details"} 
 @{" Amiga implementation " Link "Amiga implementation"} 


@EndNode

@Node "Tracker memory consumption" "tracker.guide/Tracker memory consumption"
@Next "The Protracker format"
@Prev "Technical Information"
@Toc "Technical Information"

   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" Link "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 @{b}short@{ub} occupy 2 bytes and @{b}long@{ub} 4 bytes:

   @{b}*@{ub} pitch table for 17 finetunes and 120 notes. Weighs in at 4080
     bytes.

   @{b}*@{ub} 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'.

   @{b}*@{ub} sample memory for used samples only. Precious chip memory on the
     Amiga.

   @{b}*@{ub} 4 bytes per event, 1036 bytes per used pattern (for 4 tracks
     songs).

   @{b}*@{ub} song data structure, approximately 300 bytes.

   @{b}*@{ub} sine table for vibrato and tremolo (see @{"Base effects" Link "Base effects"}),
     approximately 768 bytes.

   @{b}*@{ub} buffered extendedfile, 15K.

   @{b}*@{ub} audio buffer, when applicable. Usually set for one second of sound
     (around 100K usually).

   @{b}*@{ub} 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
(@{b}mung.c@{ub}). To use it, you just have to recompile tracker with @{b}-DMUNG@{ub}
and add @{b}mung$O@{ub} to the list of object files.  Tracker will then log all
of its memory activity to @{b}logfile@{ub}.  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.


@EndNode

@Node "The Protracker format" "tracker.guide/The Protracker format"
@Next "The Protracker file format"
@Prev "Tracker memory consumption"
@Toc "Technical Information"

A description of the Protracker format
**************************************

   As it is very difficult to get a good description of the Protracker
format, I've tried to write my own. If you find any mistakes, please
send me corrections at Marc.Espie@ens.fr.


 @{" The Protracker file format " Link "The Protracker file format"} 
 @{" Decoding pattern information " Link "Decoding pattern information"} 
 @{" Soundtracker and Protracker tempo " Link "Soundtracker and Protracker tempo"} 
 @{" Protracker finetunes " Link "Protracker finetunes"} 
 @{" Sample numbers and note periods " Link "Sample numbers and note periods"} 
 @{" Base effects " Link "Base effects"} 
 @{" Protracker extended effects " Link "Protracker extended effects"} 


@EndNode

@Node "The Protracker file format" "tracker.guide/The Protracker file format"
@Next "Decoding pattern information"
@Prev "The Protracker format"
@Toc "The Protracker format"

The binary Protracker file format
=================================

     Offset
     ---------------------------------------
       0        20 bytes        Song Name (1)
      20        22 bytes        Sample name
      42         1 word         sample length (2)
      43         1 byte         finetune (3)
      44         1 byte         volume (4)
      46         1 word         looping start point
      48         1 word         looping length
               ---------
                30 bytes (5)
     
     20+30*n     1 byte         length of song (6)
     21+30*n     1 byte         number of patterns to load (7)
     22+30*n   128 bytes        pattern indices (8)
     
     1080        4 bytes        signature (31 samples modules only)
     
     150+30*n 1024 bytes        each pattern (9)
     
     150+30*n                   sample data (10)
     +1024*p

   ---------- Footnotes ----------

   (1)  Song names and sample names will be converted to a
null-terminated string.  Be very careful as to what to allow there...

   (2)  Sample length, looping start point, looping length are normally
stored as a number of words. Occasionally, in very old modules, the
looping start point might be stored in bytes (case in point: @{b}kawai-k1@{ub}).
Checking looping start point + looping length against sample length
might discover the problem. Sound samples are 8-bit signed

   (3)  Finetune does only exist for protracker modules: if the
signature isn't M.K./M!K!, it should be 0. Normal values are 0-15.
Signature M!K! should only occur if the number of patterns is greater
than 64.

   (4)  This is the sample default volume, when no specific values have
been given.  Normal values are 0-64. Some songs include out of range
values. Be sure to normalize to 0-64

   (5)  There are 15 sample info entries in old soundtracker files, 31
in newer protracker/noisetracker ones.  The difference lies in the
signature. Valid signatures are M.K. / M!K! (for Mahoney & Kaktus),
FLT4/FLT8 for startrekker modules.

   (6)  Range 1-128

   (7)  Do not trust this byte !  Very old trackers used it to indicate
the number of pattern indices, so it's set to 127 by protracker to
enable old trackers to load this module. Noisetracker uses this byte
for restart.

   (8)  This is a sequencing order: like in play pattern #2, then #4,
then #2 again, and so on...

   (9)  We use the highest pattern number in the pattern indices table
to determine the number of patterns p to load. Older trackers saved it
as `number of patterns to load'.

   (10)  Sample data is given for each existing sample.  Non-existing
samples have a length of 0 or 1 (usually 1).  Sample values are signed
bytes, in 2-complement notation. Each sample length is a multiple of 2
in bytes.


@EndNode

@Node "Decoding pattern information" "tracker.guide/Decoding pattern information"
@Next "Soundtracker and Protracker tempo"
@Prev "The Protracker file format"
@Toc "The Protracker format"

Decoding pattern information
============================

   Each pattern holds 64 sets of 4 events, one for each Amiga track,
numbered 0 to 3 in the usual Amiga way (0-3: left channels, 1-2: right
channels, see @{"Amiga audio hardware" Link "Amiga audio hardware"}).  Some modules programmed on PC
have a special signature @{b}6CHN@{ub} or @{b}8CHN@{ub}, and accordingly, they feature
more channels.

   The four bytes per event are to be decoded as follows:

         _____byte 1_____   byte2_    _____byte 3_____   byte4_
        |                | |      |  |                | |      |
        0000          0000-00000000  0000          0000-00000000
     
        Upper four    12 bits for    Lower four    Effect/parameters
        bits of sam-  note period.   bits of sam-
        ple number.                  ple number.

   Sample number should be in the range 0-31... anything else is an
error, and should be flagged as such.  For standard protracker modules,
the note period can be converted to a note n with the following lookup
table:
C-1 to B-1
     856,808,762,720,678,640,604,570,538,508,480,453

C-2 to B-2
     428,404,381,360,339,320,302,285,269,254,240,226

C-3 to B-3
     214,202,190,180,170,160,151,143,135,127,120,113

   Older tracker modules may use highly non-standard periods.  I have
yet to encounter some, though. As a result tracker converts these pitch
values to notes and stores notes internally.  These pitch values @{i}are@{ui}
Amiga-dependent. See @{"Amiga audio hardware" Link "Amiga audio hardware"}, for further details.

   The effect command has two parts: an effect and parameters. You
should actually decode it as three independent nibble: e (effect) phi
(parameter, hi-part), plow (parameter, low-part).  The interpretation
is very dependent of the actual command involved. In many cases, phi
and plow are read as a single byte parameter (para=phi<<4 | plow)


@EndNode

@Node "Soundtracker and Protracker tempo" "tracker.guide/Soundtracker and Protracker tempo"
@Next "Protracker finetunes"
@Prev "Decoding pattern information"
@Toc "The Protracker format"

Protracker tempo
================

   The player uses two tempo values: fundamental tempo (t1) and fine
tempo (t2, invention of protracker).

   By default, t1=6 and t2=125.  A tick occurs with a frequency of
50*t2/125 Hz (some specific tracker tunes have been developped on NTSC
machines with a buggy tracker and the frequency is 60*t2/125 Hz in that
case).

   The basic play-sequence takes t1 ticks: 0st tick: read new series of
event and applies them. Do @{i}not@{ui} apply on-going effects (violent contrast
with MED).  1st to t1-1th ticks: apply effects.  then start again.


@EndNode

@Node "Protracker finetunes" "tracker.guide/Protracker finetunes"
@Next "Sample numbers and note periods"
@Prev "Soundtracker and Protracker tempo"
@Toc "The Protracker format"

The finetune concept
====================

   Finetune is a weird invention of protracker. Since it is used very
often, we can't avoid it.

   It must be decoded as follows: (1)
     Value:    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
     Finetune: 0 +1 +2 +3 +4 +5 +6 +7 -8 -7 -6 -5 -4 -3 -2 -1
   Its interpretation is as follows: an instrument with a current
finetune of f should be played offset by f/8 halftones up.  In the end,
to find the correct pitch to play a note at, you take the note period
@{i}as stored in the table for f=0@{ui}, convert it to a note value, and then
offset it to finetune f, compute the correct pitch [look it up] and
play the note. Loading a sample (as in sample number != 0) will
obviously update the finetune for the corresponding channel. There is
also an extended command to change a sample finetune without loading a
new sample (see module @{b}crystal_rain@{ub} for instance). See @{"Set finetune" Link "Set finetune"}.

   In a module, the stored pitch always use the base table and never
takes finetune into account. So, to play a Protracker note you need to
   - decode the note from the pitch value using the base pitch table.

   - look up the new pitch according to the current finetune for that
     channel.

   - play the note at the corrected frequency.

   ---------- Footnotes ----------

   (1)  This is actually a two-complement value, but over a nibble,
which is a bit unusual.


@EndNode

@Node "Sample numbers and note periods" "tracker.guide/Sample numbers and note periods"
@Next "Base effects"
@Prev "Protracker finetunes"
@Toc "The Protracker format"

How to set sample numbers and note periods
==========================================

   There has to exist a separate automaton for each of the four channels
of a Protracker song. To have a sample number != 0 means to load a
number of parameters from the sample information:
   - its default volume (special case: see @{"Set volume" Link "Set volume"})

   - its finetune (see @{"Protracker finetunes" Link "Protracker finetunes"}, see @{"Set finetune" Link "Set finetune"}, for the
     extended finetune command) Likewise, to have a note period
different from 0 means to change the note period immediately, except
for the @{"Tone portamento" Link "Tone portamento"} and @{"Tone portamento + Volume slide" Link "Tone portamento + Volume slide"} commands.


@EndNode

@Node "Base effects" "tracker.guide/Base effects"
@Next "Arpeggio"
@Prev "Sample numbers and note periods"
@Toc "The Protracker format"

Base effects
============

   The first trackers didn't have many effects. The only program that
knows something about them is ProWizard, for the Amiga.  Here is a
rundown of the standardized Amiga effects:


 @{" No effect " Link "Arpeggio"}                                     effect 0
 @{" Arpeggio " Link "Arpeggio"}                                      effect 0
 @{" Portamento up " Link "Portamento up"}                                 effect 1
 @{" Portamento down " Link "Portamento down"}                               effect 2
 @{" Tone portamento " Link "Tone portamento"}                               effect 3
 @{" Vibrato " Link "Vibrato"}                                       effect 4
 @{" Tone portamento + Volume slide " Link "Tone portamento + Volume slide"}                effect 5
 @{" Vibrato + Volume slide " Link "Vibrato + Volume slide"}                        effect 6
 @{" Tremolo " Link "Tremolo"}                                       effect 7
 @{" Set sample offset " Link "Set sample offset"}                             effect 9 (1)
 @{" Slide volume " Link "Slide volume"}                                  effect 10
 @{" Far jump " Link "Far jump"}                                      effect 11
 @{" Set volume " Link "Set volume"}                                    effect 12
 @{" Pattern break " Link "Pattern break"}                                 effect 13
 @{" Extended command " Link "Protracker extended effects"}                              under effect 14
 @{" Set tempo " Link "Set tempo"}                                     effect 15

   ---------- Footnotes ----------

   (1)  Note there is no effect 8


@EndNode

@Node "Arpeggio" "tracker.guide/Arpeggio"
@Next "Portamento up"
@Prev "Base effects"
@Toc "Base effects"

0 Arpeggio/No effect
--------------------

   The actual effect depends upon the parameters.  if phi and plow are
both null, there is no effect, else, the pitch changes at each tick,
cycling through notes n, n+phi, n+plow in this order (phi and plow in
half-tones up) Previous @{"Tone portamento" Link "Tone portamento"} effects will be forgotten,
since a note value is needed.

   Scrolling mode for no effect:
     	1 A-4
   sample number/note

   Scrolling mode for arpeggio:
     	1 A-4 B-4 A#4
   sample number/note/arpeggiated note 1/arpeggiated note 2


@EndNode

@Node "Portamento up" "tracker.guide/Portamento up"
@Next "Portamento down"
@Prev "Arpeggio"
@Toc "Base effects"

1 Portamento up
---------------

   Slide the note pitch up from the current pitch at the rate of para
each tick.  There normally is an upper boundary of B-3/pitch 113,
meaning that the slide up stops at that pitch.

   Note that there is @{i}no@{ui} default value to keep: `Portamento up with a
null para' means `don't do anything'.

   Scrolling mode:
     	1 A-4   -5


@EndNode

@Node "Portamento down" "tracker.guide/Portamento down"
@Next "Tone portamento"
@Prev "Portamento up"
@Toc "Base effects"

2 Portamento down
-----------------

   Slide the note pitch down from the currenty pitch at the rate of
para each tick.  There normally is a lower boundary of C-1/pitch 856,
meaning that the slide down stops at that pitch.

   Note that there is @{i}no@{ui} default value to keep: `Portamento down with a
null para' means `don't do anything'.

   Scrolling mode:
     	1 A-4   +5


@EndNode

@Node "Tone portamento" "tracker.guide/Tone portamento"
@Next "Vibrato"
@Prev "Portamento down"
@Toc "Base effects"

3 Tone portamento
-----------------

   Slide the note pitch from the current pitch to the given note pitch
at the rate of para each tick. You can keep on sliding without having
to specify a new para nor a new note.
The goal is reset to 0 when reached, so if you reach the note, no Tone
portamento without a goal will have an effect.
You can change the rate without having to specify a new note.
If you specify a new note, the current pitch is used as a starting
point, not the previous goal or anything like that.
A Tone portamento when the goal is already reached has no effect.

   If @{"Glissando control" Link "Glissando control"} has been applied, the pitch is rounded to the
nearest note for the actual sound output, but this value is not stored
anywhere, and has not any other influence on the player's behaviour.

   Scrolling mode:
     	1 --> A-4 (  5)
   sample number/->note to slide(rate of slide)


@EndNode

@Node "Vibrato" "tracker.guide/Vibrato"
@Next "Tone portamento + Volume slide"
@Prev "Tone portamento"
@Toc "Base effects"

4 Vibrato
---------

   phi is the speed of the vibrato and plow the depth of the vibrato.
Null values for phi or plow just mean `keep the previous value.'
The basic vibrato waveform is a sine waveform.  It can be changed to a
square waveform, or a rampdown waveform.

   Here are the actual shapes used, with origin et all.
         ****                     ********                     **
       **    **                                              **
      *        *                                           **
     *          *                                        **
                 *        *                                          **
                  **    **                                         **
                    ****                  *******                **
     
        Sine 0                     Square 1                Rampdown 2
   (see @{"Set vibrato waveform" Link "Set vibrato waveform"}, for a detailled discussion of some
aspects of that effect).

   The resulting waveform has an amplitude of 2*depth, e.g., its values
are in the range [-2*depth, 2*depth], and its full period is 64/speed
ticks.

   The position in the waveform is reset at each and every new note on
the channel.

   Scrolling mode:
     	1 A-4 vb 5/3
   sample number / note / depth/speed.


@EndNode

@Node "Tone portamento + Volume slide" "tracker.guide/Tone portamento + Volume slide"
@Next "Vibrato + Volume slide"
@Prev "Vibrato"
@Toc "Base effects"

5 Tone-portamento + Volume slide
--------------------------------

   Continue the current @{"Tone portamento" Link "Tone portamento"} while applying a @{"Slide volume" Link "Slide volume"}.
The parameters are used for the Volume slide. The Tone portamento
parameters currently in effect still apply.

   Scrolling mode:
        1 --> A-4  -5
   sample number/note to slide to/volume slide rate


@EndNode

@Node "Vibrato + Volume slide" "tracker.guide/Vibrato + Volume slide"
@Next "Tremolo"
@Prev "Tone portamento + Volume slide"
@Toc "Base effects"

6 Vibrato + Volume slide
------------------------

   Works like @{"Tone portamento + Volume slide" Link "Tone portamento + Volume slide"}: continue the current
@{"Vibrato" Link "Vibrato"} while applying a @{"Slide volume" Link "Slide volume"}.

   Scrolling mode:
        1 A-4 vibs +5
   sample number/note number/volume slide rate


@EndNode

@Node "Tremolo" "tracker.guide/Tremolo"
@Next "Set sample offset"
@Prev "Vibrato + Volume slide"
@Toc "Base effects"

7 Tremolo
---------

   Just like @{"Vibrato" Link "Vibrato"} except it affects the volume instead of the pitch.
Note that the amplitude is TWICE that of Vibrato as per protracker 1.1
source.  Also note that there is a range check since the volume must
stay in the 0,64 range.

   Scrolling mode:
     	1 A-4 tr 5/3
   sample number / note / depth/speed.


@EndNode

@Node "Set sample offset" "tracker.guide/Set sample offset"
@Next "Slide volume"
@Prev "Tremolo"
@Toc "Base effects"

9 Set Sample offset
-------------------

   Play the sample from an offset instead of from the start. The offset
(in bytes) is para * 256. If para is null, we use the last para instead.
If offset exceeds the sample length, just play a null sample.

   Scrolling mode:
        1 A-4 off%50
   sample number / note / start position (percentage of sample length)


@EndNode

@Node "Slide volume" "tracker.guide/Slide volume"
@Next "Far jump"
@Prev "Set sample offset"
@Toc "Base effects"

10 Slide volume
---------------

   If phi is not null slide the volume up by phi each tick, else slide
the volume down by plow each tick.  Note: phi and plow can be zero,
there will simply be no volume change.

   A good test is the module @{b}ghouls and ghosts@{ub}: if you mix up the test
for phi and plo, you won't hear the flute solo.


@EndNode

@Node "Far jump" "tracker.guide/Far jump"
@Next "Set volume"
@Prev "Slide volume"
@Toc "Base effects"

11 Far jump/Position jump
-------------------------

   The next events will be read from pattern index para instead of the
normal position. para has the normal range 0-127...  Protracker code
can be confusing since it is somewhat confused and intricate there.


@EndNode

@Node "Set volume" "tracker.guide/Set volume"
@Next "Pattern break"
@Prev "Far jump"
@Toc "Base effects"

12 Set volume/Volume change
---------------------------

   Set volume for the associated channel to para. The value is pure
binary, the volume is normalized to the range 0-64.


@EndNode

@Node "Pattern break" "tracker.guide/Pattern break"
@Next "Protracker extended effects"
@Prev "Set volume"
@Toc "Base effects"

13 Small jump/Pattern break
---------------------------

   The next events will be read from the next pattern starting at
position phi*10+plow instead of 0. (1) Values greater than 64 are
reduced to 0 !

   ---------- Footnotes ----------

   (1)  for strange reasons, we have a BCD value here.


@EndNode

@Node "Set tempo" "tracker.guide/Set tempo"
@Next "Amiga audio hardware"
@Prev "Invert loop"
@Toc "Base effects"

15 Set tempo
------------

   If 0 <= para <= 31, set t1=para, reset t2 to 125.  Else, set t2=para
(for Protracker).  Older trackers don't ever change t2, but always set
t1=para.  Special value 0 is supposed to end the module with Protracker.
Special case: several set speed commands in the same events. The later
ones do take precedence upon the earlier ones if both are supposed to
affect t1 or t2. If one set speed command affects t1 and the other t2,
the most likely guess is to set t1 and t2 accordingly, but you @{i}can't@{ui} be
sure... you have to either provide some switch to change your player
behavior according to the value you got, or to apply some heuristic to
go on playing...  See @{"Soundtracker and Protracker tempo" Link "Soundtracker and Protracker tempo"}, for more
details.


@EndNode

@Node "Protracker extended effects" "tracker.guide/Protracker extended effects"
@Next "Set filter"
@Prev "Pattern break"
@Toc "Base effects"

The extended command 14
=======================

   For older soundtrackers, extended command 14 was simply a toggle for
the filter (see @{"Set filter" Link "Set filter"}).  Protracker extended this: in the case of
command 14, phi is interpreted as a secondary command number, so the
parameter is actually plow for these commands.


 @{" Set filter " Link "Set filter"}              effect 14-0
 @{" Fine portamento up " Link "Fine portamento up"}      effect 14-1
 @{" Fine portamento down " Link "Fine portamento down"}    effect 14-2
 @{" Glissando control " Link "Glissando control"}       effect 14-3
 @{" Set vibrato waveform " Link "Set vibrato waveform"}    effect 14-4
 @{" Set finetune " Link "Set finetune"}            effect 14-5
 @{" Loop pattern " Link "Loop pattern"}            effect 14-6
 @{" Set tremolo waveform " Link "Set tremolo waveform"}    effect 14-7
 @{" Retrig note " Link "Retrig note"}             effect 14-9(1)
 @{" Fine volume slide up " Link "Fine volume slide up"}    effect 14-10
 @{" Fine volume slide down " Link "Fine volume slide down"}  effect 14-11
 @{" Cut note " Link "Cut note"}                effect 14-12
 @{" Delay note " Link "Delay note"}              effect 14-13
 @{" Delay pattern " Link "Delay pattern"}           effect 14-14
 @{" Invert loop " Link "Invert loop"}             effect 14-15

   Note that @{"Glissando control" Link "Glissando control"} and @{"Invert loop" Link "Invert loop"} are rarely used.

   ---------- Footnotes ----------

   (1)  Note there is not effect 14-8


@EndNode

@Node "Set filter" "tracker.guide/Set filter"
@Next "Fine portamento up"
@Prev "Protracker extended effects"
@Toc "Protracker extended effects"

14-0 Set filter   [not implemented in tracker]
----------------------------------------------

   Change the state of the Amiga low-pass filter, See
@{"Amiga audio hardware" Link "Amiga audio hardware"}.


@EndNode

@Node "Fine portamento up" "tracker.guide/Fine portamento up"
@Next "Fine portamento down"
@Prev "Set filter"
@Toc "Protracker extended effects"

14-1 Fine portamento up
-----------------------

   Like @{"Portamento up" Link "Portamento up"} except it occurs only on the 0th tick, this means
at the precise instant the command is interpreted, not later as for
Portamento up.  The exact opposite of @{"Fine portamento down" Link "Fine portamento down"}.


@EndNode

@Node "Fine portamento down" "tracker.guide/Fine portamento down"
@Next "Glissando control"
@Prev "Fine portamento up"
@Toc "Protracker extended effects"

14-2 Fine portamento down
-------------------------

   Like @{"Portamento down" Link "Portamento down"} except it occurs only on the 0th tick, this
means at the precise instant the command is interpreted, not later as
for Portamento down.  The exact opposite of @{"Fine portamento up" Link "Fine portamento up"}.


@EndNode

@Node "Glissando control" "tracker.guide/Glissando control"
@Next "Set vibrato waveform"
@Prev "Fine portamento down"
@Toc "Protracker extended effects"

14-3 Glissando control
----------------------

   Set funk glissando if para is not null. Clear funk glissando if para
is null.  While funk glissando is null @{"Tone portamento" Link "Tone portamento"}s will round each
pitch value to the nearest entire note.


@EndNode

@Node "Set vibrato waveform" "tracker.guide/Set vibrato waveform"
@Next "Set finetune"
@Prev "Glissando control"
@Toc "Protracker extended effects"

14-4 Set vibrato waveform
-------------------------

   Acceptable range is 0-3: 0 is the default sine, 1 the square, and 2
the rampdown. Protracker docs speak of 3 being a random waveform, but
I've yet to see it implemented ! Neither pt1-1, pt1-2 nor pt2-0
implement it.  You're supposed to add 4 to control whether the
viboffset is reset at each note (if 4, not reset, but this looks buggy
as hell to me...) See @{"Vibrato" Link "Vibrato"}, for the waveforms used.


@EndNode

@Node "Set finetune" "tracker.guide/Set finetune"
@Next "Loop pattern"
@Prev "Set vibrato waveform"
@Toc "Protracker extended effects"

14-5 Set finetune
-----------------

   Set finetune for the current channel to the given para right away,
instead of the current sample finetune (see @{"Protracker finetunes" Link "Protracker finetunes"}).


@EndNode

@Node "Loop pattern" "tracker.guide/Loop pattern"
@Next "Set tremolo waveform"
@Prev "Set finetune"
@Toc "Protracker extended effects"

14-6 Loop pattern
-----------------

   if para is null, set start of loop to remember, else loop to loop
start para+1 times before playing on.

   This effect is channel-dependent, so you can use several channels and
interleave loops...


@EndNode

@Node "Set tremolo waveform" "tracker.guide/Set tremolo waveform"
@Next "Retrig note"
@Prev "Loop pattern"
@Toc "Protracker extended effects"

14-7 Set tremolo waveform
-------------------------

   Like @{"Set vibrato waveform" Link "Set vibrato waveform"}, except it applies to @{"Tremolo" Link "Tremolo"}.


@EndNode

@Node "Retrig note" "tracker.guide/Retrig note"
@Next "Fine volume slide up"
@Prev "Set tremolo waveform"
@Toc "Protracker extended effects"

14-9 Retrig note
----------------

   Retrig note on para-th, 2para-th,... tick.


@EndNode

@Node "Fine volume slide up" "tracker.guide/Fine volume slide up"
@Next "Fine volume slide down"
@Prev "Retrig note"
@Toc "Protracker extended effects"

14-10 Fine volume slide up
--------------------------

   Like @{"Slide volume" Link "Slide volume"} up, except it occurs only once on the 0th tick


@EndNode

@Node "Fine volume slide down" "tracker.guide/Fine volume slide down"
@Next "Cut note"
@Prev "Fine volume slide up"
@Toc "Protracker extended effects"

14-11 Fine volume slide down
----------------------------

   Like @{"Slide volume" Link "Slide volume"} down, except it occurs only once on the 0th tick


@EndNode

@Node "Cut note" "tracker.guide/Cut note"
@Next "Delay note"
@Prev "Fine volume slide down"
@Toc "Protracker extended effects"

14-12 Cut note
--------------

   Set volume of current note to 0 on para-th tick.  @{i}Note that this
does cut the sound, but the note continues playing@{ui}.


@EndNode

@Node "Delay note" "tracker.guide/Delay note"
@Next "Delay pattern"
@Prev "Cut note"
@Toc "Protracker extended effects"

14-13 Delay note
----------------

   Start note on para-th tick instead of now.


@EndNode

@Node "Delay pattern" "tracker.guide/Delay pattern"
@Next "Invert loop"
@Prev "Delay note"
@Toc "Protracker extended effects"

14-14 Delay pattern
-------------------

   Wait for para times t1 ticks before processing new entries.  Note
that effects do proceed as usual, except that they @{i}don't@{ui} occur once
every speed-th tick (the event change is inhibited).  Delay pattern is
a global effect.


@EndNode

@Node "Invert loop" "tracker.guide/Invert loop"
@Next "Set tempo"
@Prev "Delay pattern"
@Toc "Protracker extended effects"

14-15 Invert loop
-----------------

   See code for that weird effect.


@EndNode

@Node "Amiga audio hardware" "tracker.guide/Amiga audio hardware"
@Next "Resampling details"
@Prev "Set tempo"
@Toc "Technical Information"

The Amiga audio hardware
========================

   Since part of the behavior of soundtracker-like programs depend
heavily on the Amiga audio hardware, it is only suitable that there be
a description of this hardware here.(1)

   The Amiga has four completely independant audio channels, numbered
from 0 to 3.  Channel 0 and 3 are connected to the left-side stereo
output, 1 and 2 to the right-side--hence the strange numbering in
soundtracker programs.

   Sound data is 8 bit signed in standard 2 complement (-128<=v<=127).

   The volume is also set independently from 0 to 64 (0<=v<=64).  There
is no typo there ! In terms of the hardware, the 64 value means that the
hardware dampening is disconnected.

   The volume is linear. Sample values as follows:
     Volume   db
     ---------------
     64         0
     48       - 2.5
     32       - 6.0
     16       -12.0

   The sampling period is limited by the number of DMA cycles allocated
to an audio channel, and traditionally linked to the video frequency.
The formulas are of little interest. The result is used in notes.c for
instance.

   The Amiga features a low-pass filter that can be disconnected through
software. The filter becomes active around 4KHz and gradually begins to
attenuate the signal. Generally, you cannot hear frequencies higher
than 7KHz.  Most soundtrackers disable the low-pass filter, and use it
only for special effects.

   Finally, tracker is also tied to the Amiga display hardware, oddly
enough. Older versions of soundtracker used the video @{b}VBLANK@{ub} interrupt
for timing, hence soundtracker is based upon 50 Hz ticks. This also
explains why some older files sound better when played with 60 Hz ticks
(NTSC instead of PAL).

   ---------- Footnotes ----------

   (1)  A more precise description can be found in the Amiga Rom Kernel
Manual: Hardware, published by Addison Westley


@EndNode

@Node "Resampling details" "tracker.guide/Resampling details"
@Next "Amiga implementation"
@Prev "Amiga audio hardware"
@Toc "Technical Information"

The core of tracker: the resampling engine
==========================================

   Any profiler will tell you that tracker spends most of its time
emulating the Amiga hardware in @{b}resample.c@{ub} (except on the Amiga, of
course).  Basically, the machine has to compute the actual stream of
bytes to output.  There are several things to do:
   - choose the right sample value in the sample. This is what the
     simple automaton @{b}DO_NOTHING@{ub}/@{b}PLAY@{ub}/@{b}REPLAY@{ub} does. Each pitch value
     gives rise to a @{b}step@{ub} value (see @{b}notes.c@{ub} for the step value table).
     tracker runs down the sample `by hand' using fixed-point
     arithmetic.

   - Mix samples in the right proportions. There is a volume table for
     each sample (computed in @{b}st_read.c@{ub}) that is used to scale the
     sample value. Then sample values are added according to left
     side/right side.

   - Outputting both sides. Some further mixing occur in the various
     @{b}Arch/.../audio.c@{ub} files: for a convincing stereo effect, some part
     of the right side has to go out on the left side and vice-versa.
     This is usually accomplished thanks to a generic routine of
     @{b}Arch/common.c@{ub}.

   - Converting the output for the hardware used. At this point, the
     hardware output frequency has already been taken into account,
     stereo has been taken care of as well. It remains to convert the
     sample from linear to ulaw, swap bytes, handle buffers, scale the
     sample to the right size/signedness. This is the only really
     hardware-dependent part.

   There is also some provision for oversampling: instead of using one
sample value for each sample output, we add several sample values
distributed in the right area.
   - Multiply the output frequency by @{b}oversample@{ub}. That way, we get
     @{b}oversample@{ub} values for each value output.

   - Collate all sample values and downscale accordingly. In the latest
     version, since the output size can vary, this is easiest when
     @{b}oversample@{ub} is a power of two, since it is enough in this case to
     augment the output size accordingly.

   All this can take a lot of time, too much for your cpu maybe.  What
can be done to alleviate the problem ?

   - On any machine with hardware sufficiently similar to the Amiga
     hardware (at least four channels and independent replay speed),
     write routines similar to the Amiga.

   - Keep it simple... Even a stupid test might slow the routine down.
     Hence, the duplicated code according to the value of @{b}oversample@{ub},
     the special `empty' sample and its properties ( @{b}samp->fix_length
     == 0 && samp->rp_start == NULL@{ub}).

   As a consequence, new sample styles (like 16 bit samples) should be
implemented as new types of commands like @{b}DO_NOTHING@{ub}, @{b}PLAY@{ub}, @{b}REPLAY@{ub}
(@{b}PLAY16@{ub} and @{b}REPLAY16@{ub} come to mind), even though this will
duplicate loads of code.

   Recently, the code has changed to allow for more than four channels.
This incurs a slight overcost (two more additions), which is actually
negligible for oversampled replay, and has been deemed acceptable for
simple replay.

   The lookup table for converting 0-64 volumes to a linear scale is a
cheap way to allow for all sorts of manipulations on the sample volumes
at a low cost, and also to use n-bit samples in an almost transparent
way, even with n not being an integral multiple of 8.

   If your machine is really slow, and uses ulaw, computing a complete
lookup table (all 16384 values of it) might speed things up somewhat.
Removing the oversampling test altogether might do it also. Then you
can unroll the @{b}for(i = 0; i < number; i++) loop@{ub}, not initialising
@{b}value[LEFT_SIDE]@{ub} and @{b}value[RIGHT_SIDE]@{ub} to 0, but giving them their
initial real value.

   If all that fails, you can still find a better compiler, check
whether your audio bandwidth is not too limited, downgrade the audio
output to a lower acceptable frequency (stuttering and outputting
several times the same sample is possible). Lastly, you can still go to
assembly language@{b}@{ub}

   An important optimization may exists if your machine uses dynamic
libraries and dynamic linking: on some Unixes (Sparcs for instance),
some table lookup and dynamic linking occurs at runtime, which means
that functions calls may be slightly slower. In that case, coercing you
linker to use static linking may be a good idea. If you can, link only
@{b}Arch/machine/audio.c@{ub} and @{b}resample.c@{ub} statically, since this is the place
where the speed bottleneck occurs. This way, you will get both the
advantages of static linking (speed) and dynamic linking (size).

   Maybe the specific audio code for your architecture may be improved.
Recently, I've added some optimization to @{b}Arch/common.c@{ub}.  Checking
where tracker was spending time, I discovered that almost all the time
was spent computing divisions/multiplications, like for the stereo
mixing.  Instead of computing:
     realLeft = left*primary + right*secondary
     realRight = right*primary + left*secondary

   computing

     sum = (left+right) * (primary+secondary)/2
     diff = (left-right) * (primary-secondary)/2
     realLeft = sum+diff
     realRight = sum-diff

   gains two multiplications ! Just realize that @{b}(primary+secondary)/2@{ub}
and @{b}(primary-secondary)/2@{ub} don't change and can be precomputed.

   Apart from primitive architectures where multiplication and addition
costs are the same, this gains a lot. On a Sparc 5, this makes the
difference between being able to use @{b}-over 2 -freq 44@{ub} and not !

   There is a switch in @{b}Arch/common.c@{ub} (@{b}NEW_OUTPUT_SAMPLES_AWARE@{ub}) used
for compatibility. In older implementations of tracker, the resample
code called @{b}output_samples(left_value, right_value)@{ub}, where left and
right values where 23 bits signed. The newer version call is
@{b}output_samples(left-value, right_value, width)@{ub}, with width the number
of bits used. Newer ports should define @{b}NEW_OUTPUT_SAMPLES_AWARE@{ub} and
use the code of @{b}Arch/common.c@{ub} whenever possible.

   This gains a lot when, for instance, oversample is used, since this
keeps the shifting of data left or right to a minimum.  Check whether
your implementation uses the new form of @{b}output_samples@{ub}.  if it does
not, it is a good idea to convert it.

   Also, the audio routine should give its output resolution when
needed. Right now, tracker doesn't use it, but when I get around to
adding 16 bit samples, tracker will routinely convert them down to 8
bit if the audio output is only 8 bits.

   As a rule, the Sparc version is the most complete. Try to refer to
it in case of doubt.


@EndNode

@Node "Amiga implementation" "tracker.guide/Amiga implementation"
@Next "Concept Index"
@Prev "Resampling details"
@Toc "Technical Information"

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 are quite different,
and Delitracker is most certainly the best at what it does.

   Anyway, tracker yields some very interesting features, probably
unique.
   - it's written entirely in C.

   - it's portable.

   - it goes through the OS for everything (except the audio filter
     toggling, but that's not provided for right now).

   - you can steal audio from under it without any trouble !

   - it reads archive files (like lha or zoo).

   - it buffers its sound output, so that it runs at about the same
     pace on every machine @{i}without needing any kludge@{ui}.

   The old version used the timer @{b}WAIT_EBLANK@{ub} 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, wait
for the right time to act on them, perform the sound changes, and send
the message back to task 1.

   This offers lots of advantages.
   @{b}*@{ub} time-critical code is bundled in one simple routine that basically
     only has to wait for the right instant and send very simple events
     to the audio device. I've upped the priority of this task to 90
     since it waits most of the time.

   @{b}*@{ub} tracker modules do not always need the same amount of processing
     power, the load might even vary (and does vary) during one given
     module. Using buffering means you equalize the load and you can
     then play very complex modules on a small Amiga even with
     unoptimized code.  For instance, scrolling output with @{b}scroll@{ub}
     works on almost any Amiga and any module unless you @{i}really@{ui} need
     too much processing power for it to work.(1)

   @{b}*@{ub} because of the buffer, we @{i}do@{ui} know about the samples we'll have to
     play with some look-ahead. It should be feasible to load them from
     normal ram to chip without much trouble....

   and some drawbacks too:
   @{b}*@{ub} even though sas/c tries and help you, it's still difficult to debug
     multithreaded programs. I've circumvented that difficulty by
     adding conditional code that split tracker into two distinct
     programs.

   @{b}*@{ub} handshaking is easy to get wrong. Forgetting to take some messages
     into account can lead you to lose some, and end up with a deadlock
     when no message is left.

   @{b}*@{ub} since audio output is buffered, the interface tends to react with
     some delay unless you program things carefully.  Part of the
     problem is alleviated by using @{b}ReadEClock()@{ub} to get some feedback
     in the necessary buffer.

   Another stupid problem I got in while programming the Amiga support
was using the standard @{b}WAIT@{ub} unit of the @{b}timer.device@{ub}, the one based on
@{b}VBLANK@{ub}.  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 @{b}events.c@{ub}.  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 @{b}BuildEasyRequest()@{ub} instead of directly @{b}EasyRequestArgs()@{ub}'d, but
it enables us to add a filerequester (the @{b}reqtools@{ub} one since Amigados
@{b}asl@{ub}'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 uses interface.
After all, I've got an incredible amount of data and switchs about a
module that I don't use at the time:
   @{b}*@{ub} global volume,

   @{b}*@{ub} volume on a per-instrument basis,

   @{b}*@{ub} volume on a track per track basis,

   @{b}*@{ub} non-linear volume scaling,

   @{b}*@{ub} on-the-fly transposition,

   @{b}*@{ub} switching instruments on/off...  obviously, the most difficult
part is to write the interface itself.  All of this is possible today !

   ---------- Footnotes ----------

   (1)  This means that, once again, thinking a lot about how to code
things wins hand 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.


@EndNode

@Node "aminet" "tracker.guide/aminet"
@Next "Finding a specific file"
@Prev "Background information"
@Toc "Main"

The aminet network
******************

   Aminet is a network of ftp sites for Amiga software. They offer a
comprehensive array of Amiga programs, and press new CD-Roms
periodically. Aminet is the official repository of tracker, the place
where you can find the latest version.

   The following is adapted from aminet's official @{b}readme@{ub}.


 @{" Finding a specific file " Link "Finding a specific file"} 
 @{" Mirror sites of Aminet " Link "Mirror sites of Aminet"} 
 @{" Accessing Aminet on the Internet " Link "Accessing Aminet on the Internet"} 
 @{" Accessing Aminet without Internet " Link "Accessing Aminet without Internet"} 
 @{" Copyright status and disclaimer " Link "Copyright status and disclaimer"} 
 @{" Background information " Link "Background information"} 


@EndNode

@Node "Finding a specific file" "tracker.guide/Finding a specific file"
@Next "Mirror sites of Aminet"
@Prev "aminet"
@Toc "aminet"

Finding a specific file
=======================

   Before you start looking, you should be aware that not all Aminet
sites are complete. Most delete older files. So if you don't find
something at your 'home' mirror, use one of the big sites that keep
everything online like @{b}ftp.wustl.edu@{ub}, @{b}ftp.uni-paderborn.de@{ub} or
@{b}ftp.doc.ic.ac.uk@{ub}

   Sometimes you are looking for a certain category of file without
knowing a name. You then best go by directory. The directories within
@{b}/pub/aminet/@{ub} are:

     new/     New files, upload here. (See new/README.BEFORE.UPLOAD)
     priv/    Private uploads.        (See new/README.BEFORE.UPLOAD)
     
     biz/     Business software       hard/    Hardware related
     comm/    Communications          info/    Site information
     demo/    Euro style demos        misc/    Miscellaneous
     docs/    Text documents          mods/    Music modules
     dev/     Developer software      mus/     Music software
     disk/    Disk tools              pix/     Pictures
     game/    Games software          text/    Text related
     gfx/     Graphics software       util/    Utilities

   A complete list of the sub-directories can be found in the file @{b}TREE@{ub}.
A local @{b}INDEX@{ub} with descriptions is in each subdirectory, however it only
lists the files that exist on that site, not the ones available
elsewhere on Aminet.


@EndNode

@Node "Mirror sites of Aminet" "tracker.guide/Mirror sites of Aminet"
@Next "Accessing Aminet on the Internet"
@Prev "Finding a specific file"
@Toc "aminet"

Aminet mirrors
==============

   These are the members of Aminet and have the files from here.  All
mirrors have the new files but most delete old files, however
@{b}ftp.wustl.edu@{ub}, @{b}ftp.uni-paderborn.de@{ub} and @{b}ftp.doc.ic.ac.uk@{ub}  keep all
files.  @{i}Whenever possible, use the mirror that is the closest to your
place.  Most mirrors get updated three times a day.@{ui}

     Location     Name                     IP Address      Path         Files
     
     USA (MO)     ftp.wustl.edu            128.252.135.4   pub/aminet/    ALL
     USA (WI)     ftp.netnet.net           198.70.64.3     pub/aminet/    ALL
     Scandinavia  ftp.luth.se              130.240.18.2    pub/aminet/    ALL
     Switzerland  ftp.eunet.ch             146.228.10.16   pub/aminet/    ALL
     Switzerland  ftp.math.ethz.ch         129.132.104.6   pub/aminet/   1000
     Germany      kelly.uni-paderborn.de   131.234.128.206 pub/aminet/    ALL
     Germany      ftp.uni-paderborn.de     131.234.2.42    pub/aminet/    ALL
     Germany      ftp.uni-stuttgart.de     129.69.18.15    cd  aminet    4000
     Germany      ftp.uni-erlangen.de      131.188.3.2     pub/aminet/   7000
     Germany      ftp.uni-trier.de         136.199.8.81    pub/aminet/   4500
     Germany      ftp.cs.tu-berlin.de      130.149.17.7    pub/aminet/   4000
     Germany      ftp.tu-chemnitz.de       192.108.33.193  pub/aminet/   4000
     Germany      ftp.fh-augsburg.de       141.82.16.242   pub/aminet/   3000
     Germany      ftp.uni-oldenburg.de     134.106.40.9    pub/aminet/   2500
     Germany      ftp.uni-bremen.de        134.102.228.2   pub/aminet/   2000
     Germany      ftp.uni-kl.de            131.246.9.95    pub/aminet/   1500
     Germany      ftp.uni-siegen.de        141.99.128.1    pub/aminet/   1500
     Germany      ftp.rz.uni-wuerzburg.de  132.187.1.2     pub/aminet/    700
     France       ftp.cnam.fr              163.173.128.15  pub/aminet/   8000
     Portugal     ftp.ci.ua.pt             193.136.80.6    pub/aminet/   2000
     UK           ftp.doc.ic.ac.uk         155.198.1.40    pub/aminet/    ALL
     UK           micros.hensa.ac.uk       148.88.8.84     pub/aminet/   8500


@EndNode

@Node "Accessing Aminet on the Internet" "tracker.guide/Accessing Aminet on the Internet"
@Next "Accessing Aminet without Internet"
@Prev "Mirror sites of Aminet"
@Toc "aminet"

Accessing Aminet on the Internet
================================

   There are many other ways than FTP to access Aminet. On the Internet:

ADT
     This is a front end for FTP that allows easy access to Aminet. Get
     it from @{b}misc/unix/adt*.c@{ub} and compile it on your UNIX box by typing
     @{b}sh adt.c@{ub}.

WWW
     Mosaic or Lynx are a very decent way to access Aminet. Try the
     URLs @{b}http://ftp.wustl.edu/~aminet/@{ub} or @{b}http://ftp.eunet.ch/~aminet/@{ub}
     where you can also find pointers to other Aminet sites with WWW
     support.

FSP
     Aminet Files can be downloaded from the FSP site @{b}ftp.luth.se@{ub} at
     port 6969. @{b}ftp.wustl.edu@{ub} and @{b}ftp.doc.ic.ac.uk@{ub} have FSP on port 21,
     but can't be reached from everywhere (just try). Uploads are
     accepted at wustl and luth.

telnet
     @{b}ftp.doc.ic.ac.uk@{ub} strikes again. You can telnet to 146.169.2.1 and
     log in as 'sources', which gives you a UNIX account where you can
     download the files on src using commands like 'sz' and 'kermit', or
     just browse around.

NFS
     The only Aminet site that allows NFS mounting of the archives is
     @{b}ftp.wustl.edu@{ub}. FTP there and read the details in /README.NFS

IRC
     On Internet Relay Chat, you can talk to various server robots like
     Mama, LitBot and MerBot, to do queries and retrievals. Find out
     more about them using '/msg mama help', for example.

finger
     To find out what's been uploaded to Aminet within the last week,
     enter @{b}finger aminet@ftp.wustl.edu@{ub} or @{b}finger aminet@ftp.eunet.ch@{ub}

gopher
     Gopher is specially supported by several Aminet sites. Just type
     @{b}gopher <sitename>@{ub} or @{b}gopher -p <startpoint> <sitename>@{ub}.

            USA (MO)    ftp.wustl.edu        1/pub/aminet/info/goph
            USA (TX)    ftp.etsu.edu         1/AmigaArchives/Aminet
            SWITZERLAND ftp.eunet.ch         1/pub/aminet/info/goph
            GERMANY     ftp.uni-paderborn.de 1/Service/FTP/Direct/ftp-server/aminet
            UK          ftp.doc.ic.ac.uk     1/pub/aminet/info/goph


@EndNode

@Node "Accessing Aminet without Internet" "tracker.guide/Accessing Aminet without Internet"
@Next "Copyright status and disclaimer"
@Prev "Accessing Aminet on the Internet"
@Toc "aminet"

Accessing Aminet without Internet
=================================

   - Get internet access. Certainly the most comfortable way to access
     Aminet but sometimes expensive. Some Internet providers are:
            USA         Portal  Voice 1.408.973.9111  Modem 1.408.973.8091
                        Netcom  Voice 1.408.554.UNIX
            GERMANY     EUnet   Voice +49.231.972.00  Fax +49.231.972.1111
            SWITZERLAND EUnet   Voice +41.1.291.45.80 Fax +41.1.291.46.42
            UK          Demon   Voice +44-81-349-0063 Fax +44-81-349-0309

   - Aminet mailserver. The Aminet mail server can do various things
     for you,   like doing finds and accepting uploads, but it does not
     send out   binaries. Send HELP to
     aminet-server@wuarchive.wustl.edu to find out   more.

   - Bin mailserver. The Aminet site src.doc.ic.ac.uk has an email
     server   that sends out uuencoded binaries. Send a message with
     HELP in the body   to ftpmail@doc.ic.ac.uk or ftpmail@ftp.luth.se
     . You can also use   ftpmail@decwrl.dec.com to retrieve files from
     any Aminet site, but   please use an American one to save
     bandwidth. Send HELP there for   information, too. Germans try
     ftpmail@uni-paderborn.de , Canadians   send HELP to
     MRCserv@MtRoyal.AB.CA .

   - Modem. The following BBSes carry up-to-date Aminet files. Most have
      more phone numbers than we can mention here, call to see a list
     of   the others. List sorted by phone number.

            Country     Name        FIDO          Phone            ISDN
            -------     ----        ----          -----            ----
            USA (MS)    The Gateway 1:3604/60     (+1)601 374 2697
            USA (CA)    Heavy Metal 1:202/1112    (+1)619 232 4919
            USA (NC)    The C: Dir                (+1)919 787 6211
            Canada      RCN Networks              (+1)418 653 3099
            Canada      TunnelVisio 1:153/910     (+1)604 535 9826
            Canada      MidnightMag               (+1)905 796 2931,
            France      Ramses      2:320/104     (+33)1 45845623
            Italy       Glass Globe 2:332/118     (+39)577 959054
            Italy       SpeedOfLife 2:335/533     (+39)931 833773
            Switzerland Amiga Micro 2:301/819     (+41)1 3001008   (+41)1 3001009
            Switzerland Helvetica   2:301/723     (+41)1 3130879   (+41)1 3101016
            Switzerland Dolphins                  (+41)1 8450936   (+41)1 8846028
            Switzerland AmiCall     2:301/722     (+41)1 9804297
            Switzerland Turicum                   (+41)1 9918501   (+41)1 9918503
            Switzerland Dive-Inn    2:301/325     (+41)22 7518103  (+41)22 7518105
            Switzerland Alphanet                  (+41)38 414081
            Switzerland LogicPalace 2:301/706     (+41)31 7320051  (+41)31 7320044
            Switzerland LINKSys                   (+41)61 3215643  (+41)61 3832007
            Switzerland AUGS BBS                  (+41)62 445041   (+41)62 445041
            Austria     Amiga World 2:310/72      (+43)1 5044269   (+43)1 5047701
            Denmark     Scala BBS   2:230/418     (+45)44680300    (+45)44861540
            Germany     Surprise                  (+49)201 329761  (+49)201 8315005
            Germany     Art-Line                  (+49)202 596003  (+49)202 2546013
            Germany     T.O.M.                    (+49)202 595267
            Germany     Pleasure                  (+49)203 431366
            Germany     SMachine                  (+49)203 4061447 (+49)203 9940127
            Germany     Grisubox                  (+49)2065 24447
            Germany     Karma Designs             (+49)208 670722
            Germany     Future Line               (+49)2041 686829
            Germany     Blue Moon                 (+49)2065 66407
            Germany     TrkPool                   (+49)208 808640
            Germany     Delvinor                  (+49)2131 549457 (+49)2131 951253
            Germany     Newswire                  (+49)2154 5011
            Germany     Debuwi                    (+49)2236 83233
            Germany     Candys                    ---              (+49)221 462138
            Germany     Darkness                  (+49)2273 1096   (+49)2273 910062
            Germany     X-RAY                     (+49)228 455893
            Germany     CBonn                     (+49)228 666588
            Germany     Blanker                   (+49)231 815739  (+49)231 9812094
            Germany     SID                       (+49)231 448496
            Germany     Fantasie                  (+49)2381 675700
            Germany     Stingray                  (+49)2385 6542   (+49)2385 910031
            Germany     ASBM                      (+49)251 791650
            Germany     Circus                    (+49)281 24001
            Germany     Amiga Mbx                 (+49)30 3739293
            Germany     TERM                      (+49)30 4537288  (+49)30 45470171
            Germany     Quick                     (+49)40 5479638
            Germany     ITHH                      (+49)40 6064098  (+49)40 60680341
            Germany     DOOM                      (+49)4223 8355   (+49)4223 95004
            Germany     Flight                    (+49)4442 72138  (+49)4442 920362
            Germany     Delbox                    (+49)5250 53785  (+49)5250 99952
            Germany     MultiCom                  (+49)5321 45440  (+49)5321 305373
            Germany     Black-Z                   (+49)6142 46278  (+49)6142 924080
            Germany     SLTO                      (+49)615 264898
            Germany     TecMania                  (+49)6157 87427  (+49)6157 910121
            Germany     48'er       2:2468/6020   (+49)6203 180293
            Germany     WestCoast   2:2468/9718.0 (+49)6221 761304
            Germany     RudisBox                  (+49)6253 86677  (+49)6253 972100
            Germany     HIT                       (+49)681 399426  (+49)681 372552
            Germany     Groenland                 (+49)6824 8444
            Germany     Titan                     (+49)6826 800391
            Germany     Outworld                  (+49)6831 52995  (+49)6831 995003
            Germany     ***elOutside              (+49)6838 84739
            Germany     BrainWave   2:246/2006.0  (+49)7071 78729  (+49)7071 971213
            Germany     Amiga Univ. 2:246/1416.0  (+49)7195 920677 (+49)7195 940130
            Germany     Amiga Inside2:2476/539.0  (+49)721 841292
            Germany     Uplink      2:246/2320    (+49)751 96217
            Germany     Fairytale   2:246/2300    (+49)7541 24362  (+49)7541 930232
            Germany     Melting Point 2:2476/825  (+49)7663 50103  (+49)7663 912013
            Germany     Predator    2:2490/1140   (+49)9131 14439
            Germany     LSD                       (+49)9133 9591
            Germany     Turtle      2:2490/1092   (+49)911 3241044 (+49)911 3241055
            Germany     Lizard                    (+49)911 476948
            Germany     Incubus                   (+49)931 781464  (+49)931 7900200
            Australia   Continental               (+61)2949 4256
            Australia   1990 Multi  3:690/758.0   (+61)9370 3333

   - Anonymous UUCP. In Germany, you can access the Aminet files at the
      phone numbers of Brainwave BBS (see above) using the following
     entry.    Download the file "Aminet:INFO" for more information.
     anarchy Any SER 38400 ATD<Phone> BBS. ..\c ogin: uanon sword: uanon
      In Switzerland you can use the Alphanet BBS, ~/archives/aminet,
     with the login nuucp.

   - FIDO. If you want to file-request Aminet files, you can do so by
     requesting the file INFO from 2:246/2006.0. The BBSes which have
     a FIDO node number mentioned above allow file requests.

   - Mailing lists. If you want to get the list of new uploads mailed
     every   week, send a mail with 'SUBSCRIBE aminet-weekly
     foo@bar.edu' in the   body to listserv@wunet.wustl.edu or if you
     want daily updates, just use   'SUBSCRIBE aminet-daily' instead.
     Replace foo@bar.edu with your email   address, of course. Keep the
     welcome mail in case you forget how to   unsubscribe...

   - Usenet. A list of recent uploads is posted every week to the
     newsgroups   comp.sys.Amiga.misc and de.comp.sys.Amiga.archive.

   - EZINFO. This is an internet BBS in Switzerland. Here you can
     download by   Kermit or ZMODEM, but you need to be verified to
     become user. Modem dial   01 251 20 02, then type 'telnet b050' to
     connect to EZINFO. Also try   telnet kometh.ethz.ch and 'call
     b050' from internet.

   - CD-ROM. Aminet CD 5 and up are available from Stefan Ossowski,
     Germany   (stefano@tchest.e.eunet.de) or Fred Fish
     (orders@amigalib.com). The   CD costs DM 25 or US$ 20. You can
     also buy the complete Aminet as of   Jan 95 on 4 CDs for DM60 or
     US$ 40. For further details, have a look at
     @{b}docs/misc/CD-Orders.txt@{ub}.

   - Aminet-on-disk. You can order single Aminet files (3 DM per disk)
     or per-directory subscriptions (2 DM per disk) from Martin
     Schulze,   Parkstr. 14,  66806 Ensdorf, Germany.  Phone: +49 (0)
     6831 506171,   email masc@coli.uni-sb.de . Send 3 DM in stamps or
     $2 to get an   index disk with instructions.    Aminet-on-disk is
     available on Amiga-Floppy (880k: 3DM, 1.76MB: 5DM),   SyQuest
     88/105/270MB and 128MB-Magneto-Optical. (DM 0.40 per Megabyte
     without media costs)


@EndNode

@Node "Copyright status and disclaimer" "tracker.guide/Copyright status and disclaimer"
@Next "Background information"
@Prev "Accessing Aminet without Internet"
@Toc "aminet"

Copyright status and disclaimer
===============================

   While the files from Aminet are freely distributable, the collection
is Copyright 1995 Urban D. Mueller. Making a CD-ROM with more than 200M
of files from our collection or mirroring it on a regular basis requires
permission from the administrators. That permission will be granted to
mirrors if they provide an upload facility. If you as an uploader do
not like this policy, don't upload or have your uploads removed.

   The administrators of Aminet give no warranties concerning the files
stored.  Use at your own risk.  Specifically, we cannot guarantee that
the programs are virus-free, uncorrupted, freely distributable or even
useful in any way, although we do our best to ensure the above.


@EndNode

@Node "Background information" "tracker.guide/Background information"
@Next "aminet"
@Prev "Copyright status and disclaimer"
@Toc "aminet"

History
=======

   Aminet was founded by members of ICU (computer science students'
club) in   Zurich, Switzerland, using an A3000UX donated by Commodore
Switzerland.  In   the beginning it was one FTP site among many, but
when the formerly biggest   site (@{b}ab20.larc.nasa.gov@{ub})   shut down,
people started adopting Amiga.physik   as the replacement.  In order to
share the burden both performance- and   network load wise, two mirror
sites were installed.  The new 1GB harddisk   donated by Walnut Creek
and the user community allowed us to keep all old   files, while at the
same time number of mirror FTP sites increased   constantly to
currently 10.  Today, Aminet is the leading Internet source   for Amiga
software, giving authors a far-reaching distribution medium and   the
user community a place to look for both new and old freely
distributable software.

Contact addresses
=================

   Please direct reports about corrupt, illegal or infected files
immediately   to aminet@ftp.wustl.edu (do not rely on someone else
doing it!). People   who report a copyrighted file on Aminet get a free
CD. For problems local   to one mirror, check the local README's to
find out about the administrator   there.  Some of the the people
involved:
       Moderators
     
         Urban D. Mueller   umueller@wuarchive.wustl.edu
         Matthias Scheler   mscheler@wuarchive.wustl.edu
     
       Default contact address:
     
         aminet@wuarchive.wustl.edu
   We hope you enjoy the service.


@EndNode

@Node "Credits" "tracker.guide/Credits"
@Next "History"
@Prev "Reporting bugs"
@Toc "Main"

Credits
=======

   Lots of people have contributed to tracker in one way or another.  I
may have forgotten some guys. Please forgive me. If you feel you should
be included in this list, or if your e-mail address is out of date,
feel free to send me a note.

@{i}Oleg Bartunov (megera@sai.msu.su)@{ui}
     Minor bug report

@{i}Mike Battersby@{ui}
     Linux, Makefile design

@{i}Andrew A. Chernov (ache@astral.msk.su)@{ui}
     FreeBSD port, various

@{i}Doug Cook (cook@sgi.com)@{ui}
     SG Wiz

@{i}Liam Corner@{ui}
     original program

@{i}Yannis Delmas-Rigoutsos (Yannis.Delmas@ens.fr)@{ui}
     nit-picking

@{i}Matthew Donaldson@{ui}
     bug-report

@{i}Roger Espel Llima (espel@ens.fr)@{ui}
     bug-report

@{i}Nico Francois (nico.francois@scala.com)@{ui}
     permission to use ppdecrunch

@{i}Loīc Grenié (Loic.Grenie@ens.fr)@{ui}
     bug-report

@{i}Rolf Grossmann (grossman@informatik.tu-muenchen.de)@{ui}
     NextStep port, ui cleanup

@{i}Markus Gyger (mgyger@itr.ch)@{ui}
     hp port

@{i}Steve Haehnichen (shaehnic@ucsd.edu)@{ui}
     first PC port

@{i}Stephen Hocking (sysseh@devetir.qld.gov.au)@{ui}
     Network audio port

@{i}Joerg-Cyril Hoehle@{ui}
     bug-report

@{i}Emil Johansson@{ui}
     Protracker semantics

@{i}Reinhard Katzmann@{ui}
     Amiga help

@{i}Andrzej Kotanski (kotanski@zeus02.desy.de)@{ui}
     MM1 port

@{i}Petri Kuittinen (eye@niksula.cs.hut.fi)@{ui}
     SG beta test

@{i}Bo Kullmar (bk@kullmar.se)@{ui}
     bug-report

@{i}Thomas R. Lawrence@{ui}
     old port to the macintosh

@{i}Andrew Leahy (A.Leahy@st.nepean.uws.edu.au)@{ui}
     Dec port

@{i}Kang-Jin Lee (lee@tengu.in-berlin.de)@{ui}
     bug-report

@{i}Jim Leonard (trixter@trxhome.mwc.com)@{ui}
     useful discussions

@{i}Dev Mazumbar (dev@netcom.com)@{ui}
     AudioWare port

@{i}Cyrille Micheneau@{ui}
     volunteered some help

@{i}Bruno Monsuez (Bruno.Monsuez@ens.fr)@{ui}
     OS/2 port

@{i}Francis Mouthaud (u220@esigetel.fr)@{ui}
     much stuff

@{i}Darryl Okahata (darrylo@sr.hp.com)@{ui}
     hp 3 port

@{i}Andreas Pahlsson (z94an0pa@isy.liu.se)@{ui}
     bug-report

@{i}Pascal Rullier@{ui}
     volunteered some help

@{i}Hannu Savolainen (hannu@voxware.pp.fi)@{ui}
     Linux port

@{i}Frank M. Siegert (frank@miranda.tue.schwaben.de)@{ui}
     NeXTStep port

@{i}Bjoern Stabell (bjoerns@staff.cs.uit.no)@{ui}
     hp port

@{i}Dave Tiller (dtiller@cscsun.rmc.edu)@{ui}
     Solaris/sun incompatibilities

@{i}Lukas Wunner@{ui}
     bug-report


@EndNode

@Node "Concept Index" "tracker.guide/Concept Index"
@Next "Main"
@Prev "Amiga implementation"

Concept Index
*************

@Index "Concept Index"



 @{" Aminet " Link "aminet"}                               aminet
 @{" Contacting the author " Link "Availability"}                Availability
 @{" Decoding soundtracker files " Link "The Protracker format"}          The Protracker format
 @{" History " Link "History"}                              History
 @{" History of Protracker " Link "Introduction"}                Introduction
 @{" How to register tracker " Link "Registration"}              Registration
 @{" In case of bugs " Link "Reporting bugs"}                      Reporting bugs
 @{" MED " Link "Introduction"}                                  Introduction
 @{" Module definition " Link "Introduction"}                    Introduction
 @{" Module format " Link "The Protracker format"}                        The Protracker format
 @{" Obtaining tracker " Link "aminet"}                    aminet
 @{" Protracker " Link "Introduction"}                           Introduction
 @{" Shareware concept " Link "Registration"}                    Registration
 @{" Soundtracker " Link "Introduction"}                         Introduction
 @{" Soundtracker format " Link "The Protracker format"}                  The Protracker format
 @{" The Protracker format " Link "The Protracker format"}                The Protracker format
 @{" Tracker latest version " Link "Availability"}               Availability
 @{" Tracker, what is it " Link "Introduction"}                  Introduction
 @{" Where to obtain tracker " Link "Availability"}              Availability

@EndNode

