This is tracker.info, produced by makeinfo version 4.2 from
tracker.texinfo.

INFO-DIR-SECTION Miscellaneous
START-INFO-DIR-ENTRY
* Tracker: (tracker).		Amiga modules player.
END-INFO-DIR-ENTRY


File: tracker.info,  Node: Top,  Next: Introduction,  Prev: Concept Index,  Up: (dir)

   This documentation describes tracker 5.3-OpenBSD edition.

   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
least include the documentation with your versions, and full directions
to get back to the source.

   *Thanks*

   For _any_ bug-report, _don't forget to include *full* version
information_ including
   * tracker source version.

   * the architecture on which you've compiled it.

   * any change from the standard distribution as available from *Note
     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.

* Menu:

* Introduction::
* Availability::
* Registration::
* Reporting bugs::
* Credits::
* History::
* Installation::
* Porting tracker::
* Usage::
* Technical Information::
* Concept Index::


File: tracker.info,  Node: Introduction,  Next: Availability,  Prev: Top,  Up: Top

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 *Note 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 the many versions
of Protracker (*note 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
   * faithful rendition of all Protracker tunes. (1)

   * portability. All the code is written in C.

   * support of efficient compression methods.

   *Note The Protracker format:: is historically limited by the Amiga
audio hardware, namely
   * no more than four tracks.

   * 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 (*note 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 (*note 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@openbsd.org).

   There are more architectures supported all the time. Check the
`Makefile' for this version or see *Note 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
`nic.funet.fi' or check *Note aminet::, for instance.

   _Most_ 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
_real_ 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, `MEDplayer' 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 `str15'/`str31' that might still be
available on some sites, even though it is hopelessly outdated.


File: tracker.info,  Node: Availability,  Next: Registration,  Prev: Introduction,  Up: Top

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

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

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

   Tracker is _Shareware_. 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.  _As of today, I
haven't received any contribution... I feel like I'm lacking some
incentive to go on!_

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

   In case of trouble, please try to obtain the latest version. This
documentation describes tracker 5.3-OpenBSD edition.

   It is available through anonymous ftp to *Note aminet:: in the
`misc/unix' 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@openbsd.org
   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.  *Note Reporting bugs::.

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

   Along with tracker, you might also need:
   * some modules

   * `zoo' and `lha' for your machine.

   * the `shorten' utility.

   * the `ppunpack' program, distributed with the tracker archive.


File: tracker.info,  Node: Registration,  Next: Reporting bugs,  Prev: Availability,  Up: Top

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

   Tracker is _Shareware_, but it is not crippled in any way.  What you
get 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 *Note 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 developing
tracker than anybody else these days. I consider that all the people
that have helped me along the line (*note 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.


File: tracker.info,  Node: Reporting bugs,  Next: Credits,  Prev: Registration,  Up: Top

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

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

   For _any_ bug-report, _don't forget to include *full* version
information_ including
   * tracker source version.

   * the architecture on which you've compiled it.

   * any change from the standard distribution as available from *Note
     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...


File: tracker.info,  Node: History,  Next: Installation,  Prev: Credits,  Up: Top

History
*******

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

Release 4.44 (official release)
-------------------------------

   I've finally decided to release 4.44 as an official release, since it
appears to be quite stable, and I'm currently changing a lot for 5.0.
Problems to note:
   * The OS/2 version seems to crash from time to time, and Bruno has
     been unable to track the problem down.

   * AIX internals seem to have changed quite a bit recently. There
     will be a patch available as soon as the problem is fixed.

Release 4.44 (beta)
...................

   * Full documentation included in the package.

Release 4.43 (beta)
...................

   * works on the Amiga again thanks to slight changes. Merging the
     Amiga files into the main distribution slowly....

   * Mixed up *Note Fine portamento up:: and *Note Fine portamento
     down::, thanks Emil (*note Credits::).

Release 4.42 (beta)
...................

   * slight bugs in file reading....

   * put back `transpose' option where it belonged.

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

   * option parsing code in order. All old options put back in.

   * bugs with color handling fixed.

   * Amiga version considered temporarily broken due to extensive
     changes.

   * The list option is currently broken.

Release 4.41 (beta)
...................

   * corrected long-standing bug in effect 5.

   * fixed stupid bug in older-style tempo.

   * should compile correctly under solaris.

   * new-style options.

Release 4.40 (beta)
...................

   * the player is now more sensible.

   * added `m'/`M' runtime switch (mono/stereo).

   * fixed up minor amiga problems.

   * fixed up the audio recognition loop in the Sparc engine.

   * removed transpose feature as it will be simpler to do it by
     changing sampling frequency and tempo.

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

Release 4.39 (beta)
-------------------

   * fixed up data sizes mostly everywhere.

   * added prototypes to `Arch/Sparc/config.h', and `#define
     IOCTL_IS_REDUNDANT' to remove gcc warnings.

   * made porting much easier.

Release 4.38 (beta)
...................

   * checked memory handling thanks to `mung.c'. Various small memory
     bugs fixed.

   * fixed bug in `run_in_fg'.  It did sometimes reply that tracker was
     run in bg even though this was false.

   * changed semantics of `sync_audio': we need a second function to be
     able to free data in `remove_pending_tags'.


Release 4.37 (beta)
...................

   * fixed bug with tremolo.

   * total duration working correctly.  Showing up in the title bar for
     xterms.

Release 4.36 (beta)
...................

   * the virtual player now computes the total song length.

   * small bug-fixes.

   * documentation rewritten using TeXinfo.

Release 4.35 (beta)
...................

   * start of virtual player: try computing the total song length...
     Not fully implemented yet.

   * some more cleanup as far as note handling is concerned.

   * pulled `randomizer' inside of main code... now randomize correctly
     across directories. Better `play_list' handling

Release 4.34 (beta)
...................

   * loads of compression in the song reading. sample numbers get
     remapped and we get rid of most redundant stuff.

   * 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).

   * specific setup for virtual player (soon to be implemented)

Release 4.33 (beta)
...................

   * separated `SPECIAL_NOTE' (no known pitch) from `NO_NOTE'.

   * better disk/memory throughput: use `read_file' where applicable.

   * does not interpret unused patterns. Does not even read them, in
     fact.

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

Release 4.32 (beta)
...................

   * documentation update.

   * player clean up.

   * Sparc sound engine _more_ powerful.

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

   * OS/2 version updated.

   * HP versions updated.

   * SGI minor bug fix.

Release 4.30 (beta)
...................

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

Release 4.29 (beta, official Amiga)
-----------------------------------

   * runs on the Amiga again.

   * fixed up _all_ remaining Protracker problems. All Protracker
     effects are now functional!

   * minor bugs fixed. Nothing serious under Unix, used to crash under
     AmigaOs.

Release 4.28 (beta)
...................

   * partial port to mm1

   * renamed `getopt.h' to `getoption.h'

Release 4.27 (beta)
...................

   * minor bug fixes in `Arch/common.c'. should work correctly on
     NextStep now.

   * xterm stuff cleaned up.

   * `ppunpack' is now _officially_ part of tracker. Nico Francois
     (*note Credits::) _has_ given his benediction.  *You may
     redistribute `ppunpack' as you wish.*

Release 4.26 (beta)
...................

   * title in window title bar for `xterms'.

   * version number cleaned up, now shows up in exactly _one_ place
     (`Makefile')

Release 4.25 (beta)
...................

   * added remaining Protracker 1.1 effect: *Note Invert loop::
     (extended 15).

   * fixed up (mostly) *Note Loop pattern:: (extended 6).

Release 4.24 (beta)
...................

   * network audio (*note NAS::) port... probably not working yet.

Release 4.22 (beta)
...................

   * implemented vibrato/tremolo control. *Note Set vibrato waveform::,
     *Note Set tremolo waveform::.

Release 4.20 (beta)
...................

   * notion of data width introduced, fixed some problems (more or
     less).

   * corrected minor bug in `Arch/Sparc/audio.c': used to modify the
     volume at exit.

   * some minor changes in commands according to the actual Protracker
     code.

Release 4.19 (beta)
...................

   * more sensible scrolling display.

   * tremolo (*note Tremolo::) finally working.

   * Rolf Grossmann's patch (*note Credits::): cleaned up user
     interface, with less `#defines'.

Release 4.18 (beta)
...................

   * New Sparc features: `-sync' support, waiting at start for buffer
     to fill for unhashed audio output.

   * lots of minor bugs everywhere fixed.

   * *WARNING:* `oversample=0' (linear resampling) is probably broken
     right now

Release 4.17 (beta)
...................

   * cleaned up architectural stuff. Even faster.

Release 4.16 (beta)
...................

   * much better optimization in `resample.c'.

   * optimization of the various `audio.c' files.

Release 4.15 (beta)
...................

   * added missing *Note Tremolo:: effect...  `guitarslinger' now
     sounds correctly (I hope).

   * fixed up *Note Set finetune::... was not updated instantly enough.

Release 4.14 (internal)
.......................

   * PowerPacker depacker.

Release 4.13 (full release)
---------------------------

   * cleaned up small bugs as compared to 4.11.

   * much better technical documentation.

   * upgraded Amiga version to 4.13.

Release 4.11 (internal release)
...............................

   * implemented color ANSI support.

   * NextStep status: working with minor patch.

   * linux status: working.

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

   * _Note for programmers:_ `output_samples' size _has_ changed to 23
     bits, to allow for 16 bit samples, oversampling, volume, and so
     on...

   * reorganized machine dependent code to `Arch/'.

   * cleaned up `Makefile'.

   * implemented buffered files (finally). Faster loading of some
     modules.

   * clutter of includes moved to `defs.h'.

Release 4.7 (internal release)
..............................

   * small bugfixes.

   * compiling now on other architectures: NeXT, OS9. *Note
     Architecture dependent problems::, *Note Credits::.

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

   * full Amiga support. Good playing model.

   * rewrote `Makefile'.

   * minor options changes.

   * much easier to tinker with than the previous versions. Hooks for
     future upgrades everywhere.

   * 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
------------

   * Amiga support! Finally.

   * Solaris 2.2 support.

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

   * general bug-fixes, plays some modules it goofed on (speed check,
     extended command *Note Loop pattern:: now works).

   * repeat working better.

   * should be rather difficult to get cores out of it.

   * may fork when loading a new module, though not working
     satisfactorily yet.

   * almost readable scrolling display.

   * support for DECstations (thanks to Andrew Leahy, *note Credits::) .

   * support for hpux (thanks to Bjoern Stabell, *note Credits::).

   * partial support for solaris.

Release 3.10 (internal release)
...............................

   * linux: small bug-fix, 16 bit support.

   * general: bug in finetune fixed.

Release 3.9 (internal release)
..............................

   * background/foreground csh-aware mode, much cleaner termio.

Release 3.7 (internal release)
..............................

   * support for linux (thanks to Hannu Savolainen, *note Credits::).

   * small bug fix in `termio': restore to a sane tty on exit.

Release 3.6 (internal release)
..............................

   * more efficient replay routine, works faster, all glitches finally
     removed (I hope).

   * more options, better integrated.

   * much cleaner source code.

Release 3.0 (internal release)
..............................

   * tracker knows about  the Sparcstation 10.

   * bug fix for command 5 (*note Tone portamento + Volume slide::),
     that now works like portamento (*note Tone portamento::).  Mostly
     affects `apocalypse' module.

   * support for most protracker extended commands, including finetune.

   * dynamic adjustements to the output frequency, fast skip, much
     better user-response overall.

   * better runtime interface (without those strange signals sequences).

   * better screen output.

   * audio flush on the Sparc, don't have to wait 10sec+ to exit.


File: tracker.info,  Node: Installation,  Next: Configure tracker,  Prev: History,  Up: Top

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

* Menu:

* Configure tracker::                  to know what you can change
* Generic problems::                   check these things first
* Architecture dependent problems::    if it doesn't work
* Porting tracker::
* Performance issues::                 to finetune tracker


File: tracker.info,  Node: Configure tracker,  Next: Generic problems,  Prev: Installation,  Up: Installation

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

   In order to compile tracker, you have to edit the `Makefile' and
change several entries:

MACHINE
     your type of machine or precise port.

PREFIX
     where installed files will go.

CC
     C compiler to use.

COMPRESSION_FILE
     the default `compression known database' file.

   then type
     make

   `make install' usually doesn't work, but tracker is quite easy to
install by hand anyway.  If everything didn't work ok, check the *Note
Generic problems:: section.

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


File: tracker.info,  Node: Generic problems,  Next: Architecture dependent problems,  Prev: Configure tracker,  Up: Installation

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

   Most files are system independent, with some exceptions.

The `Arch' directory.
     holds a `config.h' and an `audio.c' file for every configuration
     tracker has been compiled on.  `config.h' specifies various things
     about the machine.  `audio.c' is the audio driver itself.

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

The `Arch/Amiga' 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 `resample.c' completely, *Note
     Amiga audio hardware::, *Note Resampling details::, *Note Amiga
     implementation::, for details).

   If you need to understand how tracker works, a good place to start
with is `extern.h', which holds commented prototypes for most functions.
Also, *Note Resampling details::.

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

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

    Real fix
          install a real `make', like `gnumake'.

What's `stricmp' ?
     that's ``strcmp' without caring about cases'. On some machines,
     there is a function called `strcasecmp' instead.  A `#define
     strcasecmp' in your machine's `config.h' will be enough.  If you
     really don't find it, it's easy to roll your own, or even replace
     it with `strcmp' 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
     `COMPRESSION_FILE' 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 `HAS_TERMIOS' and `HAS_SGTTY'
     entries.

   If tracker doesn't compile more or less cleanly, check that it
pulled the right `config.h' 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 *Note Performance issues::.


File: tracker.info,  Node: Performance issues,  Next: Usage,  Prev: Porting tracker,  Up: Installation

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

   _Warning: most of these problems can only be fixed by changing the
code of tracker... non-programmers, beware!_ You might wish to get a
look at *Note 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 sounds 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 _that_
     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 `ppunpack' to depack
     PowerPacked modules. Also, tracker doesn't yet know how to play
     MED, S3M, or xm modules.

Tracker barfs on some modules
     Try `-tolerant'. 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.


File: tracker.info,  Node: Architecture dependent problems,  Next: Aix,  Prev: Generic problems,  Up: Installation

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

* Menu:

* Aix::
* Amiga::
* DECstation::
* HP/UX::
* Linux/FreeBSD::
* MM1/OS9::
* NAS::
* NextStep::
* OS/2::
* Silicon Graphics::
* Sparc::

* Other Architectures: Porting tracker.


File: tracker.info,  Node: Aix,  Next: Amiga,  Prev: Architecture dependent problems,  Up: Architecture dependent problems

Aix
---

   The Aix port is slightly outdated and won't run with most recent
versions of Aix. There is nothing I can do about it until somebody
sends me an up-to-date version as I don't have access to Aix machines.


File: tracker.info,  Node: Amiga,  Next: DECstation,  Prev: Aix,  Up: Architecture dependent problems

Amiga
-----

   There is currently one Amiga version running under AmigaDos.  An
adaptation of the *Note 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.
        *    plays lha modules

        *    transpose modules

        *    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 `CON:.../AUTO/WAIT' 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.


File: tracker.info,  Node: DECstation,  Next: HP/UX,  Prev: Amiga,  Up: 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 `AudioFile'. It is a public domain audio
package available from DEC `crl.dec.com' aka 192.58.206.2,
`/pub/DEC/AF'.  the software will run on a number of platforms:
Sun/NeXT/SGI/DEC.  The `AF_audio.c' 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:
`AUDIOFILE'
     the name of the audio server to connect to for mono playback. And
     for the Left Channel in stereo playback. eg. `"machine:0"'

`AUDIORIGHT'
     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!


File: tracker.info,  Node: HP/UX,  Next: Linux/FreeBSD,  Prev: DECstation,  Up: Architecture dependent problems

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

   There are currently three ports (actually four if you count *Note
NextStep::):

   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, *note
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, *Note Credits::.

   _NOTE: this is still undergoing development, and will probably be
enhanced, as some parts don't work very well._

   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
     `boensen.mod')

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

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

     *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.* 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.


File: tracker.info,  Node: Linux/FreeBSD,  Next: MM1/OS9,  Prev: HP/UX,  Up: 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, `dsp_samplesize' constant in `Arch/Pcux/audio.c').  It
should be possible to analyze that automatically with the recent
drivers versions.  Also, you might need to fiddle with `UNSIGNED8' and
stuff (I hope not).  In any case, do not try replacing `/dev/dsp' with
`/dev/audio'...  `/dev/audio' 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 _both_ resolution _and_ 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 (*note Credits::).


File: tracker.info,  Node: MM1/OS9,  Next: NAS,  Prev: Linux/FreeBSD,  Up: 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 `-frequency'.

   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 `flush_buffer' 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 `_ss_play' and using
two buffers, so that when the first buffer is played, the other is
being filled.


File: tracker.info,  Node: NAS,  Next: NextStep,  Prev: MM1/OS9,  Up: 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 `fork' 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.


File: tracker.info,  Node: NextStep,  Next: OS/2,  Prev: NAS,  Up: Architecture dependent problems

NextStep port
-------------

   There is a known problem: You can't skip patterns forward or
backward in quick succession. It will restart the same pattern. This is
because of the buffering we have to do, while keeping syncronized with
display output. I'll fix it, when I find the time.

   There used to be a problem with big endians/little endians machines.
It should be solved these days. Look around in `Arch/NeXT/audio.c' for
`SNDSwapSoundToHost'.

   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 Grossmann (*note 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:

   * Added support for sgtty ("old" BSD) style terminal settings to
     `Arch/Unix/ui.c'.  Also cleaned this up and made it architecture
     independent.  Verified that it works on Suns, too.

   * Created a new variable `play_ahead' 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).  You can set it's value using the
     port-specific option -play-ahead <n>.  I think the default of 5 is
     a good value and you probably won't need to change it.

   * Added call to `SNDSwapSoundToHost' before actually playing the
     sound, so it should work on NS/intel now.

   * Thanks to recent changes to the `Makefile' it should even work with
     NeXT's native make. If you're having problems with it, use GNU
     make.



File: tracker.info,  Node: OS/2,  Next: Silicon Graphics,  Prev: NextStep,  Up: Architecture dependent problems

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

   There is still an unfixed bug with respect to memory usage that may
lead to crashes.  Everything uses the same drivers as for Linux/FreeBSD
(almost). Ask Bruno Monsuez directly (*note Credits::).


File: tracker.info,  Node: Silicon Graphics,  Next: Sparc,  Prev: OS/2,  Up: 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 _has_ been installed.  Also, the standard SGI `make' is
crippled. *Note Generic problems::.

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

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

   (1) I have not put this in every `config.h' for compatibility with
old K&R compilers


File: tracker.info,  Node: Sparc,  Next: Porting tracker,  Prev: Silicon Graphics,  Up: 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.1.3
and Solaris 2.x.  There are still problems though, thanks to the brain
damaged way Sun is 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 better (at least in tracker's
case).

   If you have Solaris 2.x, use target name `solaris' instead of `sparc'
(thanks to Dave Tiller, *Note Credits::.)  include file names may
change between `sun/audioio.h' and `sys/audio.io.h' 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 speaker or
headphones.

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

   There is some intricate code in `Arch/Sparc/audio.c' to check for
the precise hardware used in your Sparc.

   The `AUDIO_GETDEV' 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 `-static' because this consumes much
less cpu in the critical modules. In fact, these critical modules are
just `resample.o' and `Arch/Sparc/audio.o'. If you feel like it, you
can use your linker separately to link these statically (something like
`ld -Bstatic -onew.o resample.o Arch/Sparc/audio.o') and then link the
whole executable dynamically.

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


File: tracker.info,  Node: Porting tracker,  Next: Performance issues,  Prev: Sparc,  Up: Installation

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

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

   * For me, tabs correspond to three spaces.

   * 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 `$Id$' and `$Log$' entries are filled by RCS. `defs.h'
     includes some standard header files: `config.h', `stdio.h',
     `stdlib.h', `string.h'. It also includes some useful standard
     definitions. You are advised to read it.

   * My C is ANSI, but should be acceptable to K&R compilers. This means
     that prototypes use the form `function P((int param));', where P
     expands to a prototype or a `()' according to `config.h', and that
     actual function declarations should use old type prototype.  You
     don't have to care to much about that as I'm most probably be
     switching to full ANSI soon.

   * 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.

   * Tracker needs a decent address space, not a toy computer like an
     IBM PC.

   * Tracker needs files and pipes, it's real difficult to port to toy
     computers like MacIntoshes.

   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
`#define SPECIAL_SAMPLE_MEMORY' to `config.h' and provide suitable
`alloc_sample' and `free_sample' functions as per `extern.h'.

   If your audio hardware cannot emulate an Amiga directly (*note Amiga
audio hardware::), you will have to use resampling, *Note Resampling
details::.

   Basically, you will build a specific `audio.c' file for your
architecture that holds two important functions:

   `open_audio(freq, stereo)' 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.

   `output_samples(left, right, n)' adds two audio samples to the stream
in progress. Both samples have n bit resolution.

   Other functions in `audio.c' as documented in `extern.h' can mostly
be replaced by suitable stubs.

   This audio architecture will probably change for release 5, in order
to provide for more flexibility, but you shouldn't have to worry too
much about that yet, as I will provide a `compatibility interface'.

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

   Create a directory for your architecture, copy these files there,
update the `Makefile' to add an entry for your architecture. You need to
edit `config.h', since as shipped it doesn't work, and to implement the
base functions as discussed in `audio.c'. Don't forget to use the set
of routines in `common.c'. 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 `Arch/Unix/ui.c'
file together  `#define USE_SGTTY' or `#define USE_TERMIOS' will be
enough.  If you are not under Unix, this might be more difficult.  Also
note `run_in_fg', 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 `PREF_XTERM')
and for color terminals (triggered by `PREF_COLOR').  `PREF_XTERM' is
set by the TERM environment variable in `main.c', `PREF_COLOR' is set
according to the compilation switch `COLOR_IS_DEFAULT'. Note that both
of these settings may be overriden by command line options.

   If your machine uses another color model, you will have to add
suitable definitions to `color.c'. 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 `open.c' extensively if you want
compression.  Try to remove `#define NO_PIPES' from `config.h' and
recompile `open.c' to check whether compression works or not.  You'll
also have to adapt `compression_methods' 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 `stat', `S_ISDIR', `readdir' for the automatic
expansion of directories in `play_list.c' 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 `sync_audio' function(2)

   Basically, `sync_audio' 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 `n' 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 `free' 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.


File: tracker.info,  Node: Usage,  Next: Technical Information,  Prev: Performance issues,  Up: Top

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

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

   Various compression methods are supported through pipes.  There is a
simple-minded configuration file `compression_methods' (check
`Makefile' 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 `compression_methods' 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.
`-stereo/-mono'
     switch between stereo and mono output. Some modules need mono
     output to sound right. Apart from that, on stereo-capable
     machines, mono output usually uses less CPU.

`-mix <percent>'
     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+.

`-frequency <freq>'
     set the audio output 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.

`-oversample <n>'
     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 `resample.c' 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 `resample.c' for details.

`-new/old/both'
     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.

`-picky'
     do not allow for any problems in a module.

`-tolerant'
     allow for many problems that would normally stop a module

`-repeats / -repeats <n>'
     repeat each module n times. With no value (or a 0), repeat the
     module forever.

`-looping'
     make module list loop as a whole.

`-verbose'
     show a sample listing for the module.

`-scroll'
     scroll-display the module being played.

`-color/-bw'
     use with terminals with color-ansi capability (e.g., kterm) to get
     a colorful scroll.

`-speed <n>'
     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.

`-pal/-ntsc'
     PAL or NTSC tempo. Shortcut for the `speed' option.

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

`-transpose <k>'
     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....

`-start n'
     start the module at pattern number n instead of number 0.

`-randomize'
     plays the module list in random order.

`-list file'
     plays the modules listed in the given file (one module name per
     line, spaces are significant).

   The Amiga version uses `ReadArgs' style argument parsing, and doesn't
recognize the precise same options.

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

`-cut 012...abcd'
     suppress samples from the audio output.

`-add 012...abcd'
     add samples to the audio output (exclusive with cut).

`-halve 012...abcd'
     halve these samples volume.

`-double 012...abcd'
     double these samples volume (exclusive with halve).

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

`n'
     go to next song.

`p'
     restart current song/go to previous song.

`>'
     fast forward.

`<'
     rewind.

`S'
     NTSC tempo (60 Hz). *Note Amiga audio hardware:: for the reason
     this exists.

`s'
     PAL tempo (50 Hz).

`q'
`x'
`e'
     quit right away.

`m'
     switch to monaural mode.(1)

`M'
     go back to stereo mode.

`+'
     (Sparc only) increase sampling rate.(2)

`-'
     (Sparc only) decrease sampling rate.

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

   (1) This key is equivalent to `-mix 100', 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


File: tracker.info,  Node: Technical Information,  Next: Tracker memory consumption,  Prev: Usage,  Up: Top

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

   Throughout tracker, I'm trying to establish a trend of well
thought-out 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.

* Menu:

* Tracker memory consumption::
* The Protracker format::
* Amiga audio hardware::
* Resampling details::
* Amiga implementation::


File: tracker.info,  Node: Tracker memory consumption,  Next: The Protracker format,  Prev: Technical Information,  Up: 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 (*note The Protracker format::).

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

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

   * pitch table for 17 finetunes and 120 notes. Weighs in at 4080
     bytes.

   * sample info for all used samples. Each sample info is about 200
     bytes long, including sample name, and 100 bytes of volume scaling
     table.  Only as many sample infos as samples are used, add one
     sample info for an `empty sample'.

   * sample memory for used samples only. Precious chip memory on the
     Amiga.  Since I've seen `The player' from Jaarno Paarnen, I'm
     thinking of adding decompression code for the samples on-the-fly.
     Also, a real resampling mode on the Amiga or a sample cache would
     be cool.

   * 4 bytes per event, 1036 bytes per used pattern (for 4 tracks
     songs).

   * song data structure, approximately 300 bytes.

   * sine table for vibrato and tremolo (*note Base effects::),
     approximately 768 bytes.

   * buffered extendedfile, 15K.

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

   * pattern load buffer, 1K.

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

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

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

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


File: tracker.info,  Node: The Protracker format,  Next: The Protracker file format,  Prev: Tracker memory consumption,  Up: 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@openbsd.org.

* Menu:

* The Protracker file format::
* Decoding pattern information::
* Soundtracker and Protracker tempo::
* Protracker finetunes::
* Sample numbers and note periods::
* Base effects::
* Protracker extended effects::


File: tracker.info,  Node: The Protracker file format,  Next: Decoding pattern information,  Prev: The Protracker format,  Up: 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:
`kawai-k1'). 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.


File: tracker.info,  Node: Decoding pattern information,  Next: Soundtracker and Protracker tempo,  Prev: The Protracker file format,  Up: 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, *note Amiga audio hardware::).  Some modules programmed on PC
have a special signature `6CHN' or `8CHN', 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(1):
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. (2) As a result tracker converts these
pitch values to notes and stores notes internally.  These pitch values
_are_ Amiga-dependent. *Note Amiga audio hardware::, for further
details.

   The effect command has two parts: an effect and parameters. You
should actually decode it as three independent nibbles: 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)

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

   (1) Actually, tracker doesn't use this exact table, but builds a
precise well-tempered scale using powers of 2, see `notes.c'

   (2) It would be easy to add some heuristics to the virtual player to
detect these modules, and build the corresponding well-tempered scale
on the fly. The hardest decisions would be to adjust the table because
of limited precision (values stored as integer arithmetic) and possible
distinct scales for each sample.


File: tracker.info,  Node: Soundtracker and Protracker tempo,  Next: Protracker finetunes,  Prev: Decoding pattern information,  Up: 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 _not_ apply on-going effects (violent
contrast with MED).  1st to t1-1th ticks: apply effects.  then start
again.


File: tracker.info,  Node: Protracker finetunes,  Next: Sample numbers and note periods,  Prev: Soundtracker and Protracker tempo,  Up: 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
_as stored in the table for f=0_, 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 `crystal_rain' for instance). *Note 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.


File: tracker.info,  Node: Sample numbers and note periods,  Next: Base effects,  Prev: Protracker finetunes,  Up: 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: *note Set volume::)

   - its finetune (*note Protracker finetunes::, *note 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 *Note Tone portamento:: and
*Note Tone portamento + Volume slide:: commands.


File: tracker.info,  Node: Base effects,  Next: Arpeggio,  Prev: Sample numbers and note periods,  Up: 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:

* Menu:

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

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

   (1) Note there is no effect 8


File: tracker.info,  Node: Arpeggio,  Next: Portamento up,  Prev: Base effects,  Up: 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 *Note 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


File: tracker.info,  Node: Portamento up,  Next: Portamento down,  Prev: Arpeggio,  Up: 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 _no_ default value to keep: `Portamento up with a
null para' means `don't do anything'.

   Scrolling mode:
     	1 A-4   -5


File: tracker.info,  Node: Portamento down,  Next: Tone portamento,  Prev: Portamento up,  Up: 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 _no_ default value to keep: `Portamento down with
a null para' means `don't do anything'.

   Scrolling mode:
     	1 A-4   +5


File: tracker.info,  Node: Tone portamento,  Next: Vibrato,  Prev: Portamento down,  Up: 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 *Note 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)


File: tracker.info,  Node: Vibrato,  Next: Tone portamento + Volume slide,  Prev: Tone portamento,  Up: 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
   (*note 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.


File: tracker.info,  Node: Tone portamento + Volume slide,  Next: Vibrato + Volume slide,  Prev: Vibrato,  Up: Base effects

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

   Continue the current *Note Tone portamento:: while applying a *Note
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


File: tracker.info,  Node: Vibrato + Volume slide,  Next: Tremolo,  Prev: Tone portamento + Volume slide,  Up: Base effects

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

   Works like *Note Tone portamento + Volume slide::: continue the
current *Note Vibrato:: while applying a *Note Slide volume::.

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


File: tracker.info,  Node: Tremolo,  Next: Set sample offset,  Prev: Vibrato + Volume slide,  Up: Base effects

7 Tremolo
---------

   Just like *Note 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.


File: tracker.info,  Node: Set sample offset,  Next: Slide volume,  Prev: Tremolo,  Up: 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)


File: tracker.info,  Node: Slide volume,  Next: Far jump,  Prev: Set sample offset,  Up: 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 `ghouls and ghosts': if you mix up the test
for phi and plo, you won't hear the flute solo.

   Scrolling mode:
        1 A-4 vol +5
   sample number / note / slide increment


File: tracker.info,  Node: Far jump,  Next: Set volume,  Prev: Slide volume,  Up: 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.

   Scrolling mode:
        1 A-4 ff 50
   sample number / note / new pattern number


File: tracker.info,  Node: Set volume,  Next: Pattern break,  Prev: Far jump,  Up: 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.

   Scrolling mode:
        1 A-4 vol 50
   sample number / note / new volume


File: tracker.info,  Node: Pattern break,  Next: Protracker extended effects,  Prev: Set volume,  Up: 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 !

   Scrolling mode:
        1 A-4 skp 25
   or
     	1 A-4 next
   (if starting at position 0 in next pattern)

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

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


File: tracker.info,  Node: Set tempo,  Next: Amiga audio hardware,  Prev: Invert loop,  Up: 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 _can't_
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...  *Note Soundtracker and Protracker tempo::, for more
details.

   Scrolling mode:
        1 A-4 SPD 7		(for t1 tempo)
     	1 A-4 spd%95	(percentage of normal finespeed)


File: tracker.info,  Node: Protracker extended effects,  Next: Set filter,  Prev: Pattern break,  Up: Base effects

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

   For older soundtrackers, extended command 14 was simply a toggle for
the filter (*note 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.

* Menu:

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

   Note that *Note Glissando control:: and *Note Invert loop:: are
rarely used.

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

   (1) Note there is not effect 14-8


File: tracker.info,  Node: Set filter,  Next: Fine portamento up,  Prev: Protracker extended effects,  Up: Protracker extended effects

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

   Change the state of the Amiga low-pass filter, *Note Amiga audio
hardware::.


File: tracker.info,  Node: Fine portamento up,  Next: Fine portamento down,  Prev: Set filter,  Up: Protracker extended effects

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

   Like *Note 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 *Note Fine portamento
down::.

   Scrolling mode:
        1 A-4 sth-15


File: tracker.info,  Node: Fine portamento down,  Next: Glissando control,  Prev: Fine portamento up,  Up: Protracker extended effects

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

   Like *Note 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 *Note Fine portamento
up::.

   Scrolling mode:
        1 A-4 sth+15


File: tracker.info,  Node: Glissando control,  Next: Set vibrato waveform,  Prev: Fine portamento down,  Up: 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 *Note Tone portamento::s will
round each pitch value to the nearest entire note.

   Scrolling mode:
        1 A-4 gls on
     	1 A-4 gls off


File: tracker.info,  Node: Set vibrato waveform,  Next: Set finetune,  Prev: Glissando control,  Up: 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...)  *Note Vibrato::, for the waveforms used.

   Scrolling mode:
        1 A-4 vb mode
   with `mode' being one of `sine, sqre, ramp' or `SINE, SQRE, RAMP' if
the viboffset should not be reset.


File: tracker.info,  Node: Set finetune,  Next: Loop pattern,  Prev: Set vibrato waveform,  Up: 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 (*note Protracker finetunes::).

   Scrolling mode:
        1 A-4 fine 15
   where the parameter is between 0 and 15.


File: tracker.info,  Node: Loop pattern,  Next: Set tremolo waveform,  Prev: Set finetune,  Up: 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...

   Scrolling mode:
        1 A-4 SETLOOP
   at the beginning,
        1 A-4 LOOP 10
   for looping 10 times.


File: tracker.info,  Node: Set tremolo waveform,  Next: Retrig note,  Prev: Loop pattern,  Up: Protracker extended effects

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

   Like *Note Set vibrato waveform::, except it applies to *Note
Tremolo::.

   Scrolling mode:
        1 A-4 tr mode
   with `mode' being one of `sine, sqre, ramp' or `SINE, SQRE, RAMP' if
the viboffset should not be reset.


File: tracker.info,  Node: Retrig note,  Next: Fine volume slide up,  Prev: Set tremolo waveform,  Up: Protracker extended effects

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

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

   Scrolling mode:
        1 A-4 rtg 3


File: tracker.info,  Node: Fine volume slide up,  Next: Fine volume slide down,  Prev: Retrig note,  Up: Protracker extended effects

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

   Like *Note Slide volume:: up, except it occurs only once on the 0th
tick

   Scrolling mode:
        1 A-4   ++5


File: tracker.info,  Node: Fine volume slide down,  Next: Cut note,  Prev: Fine volume slide up,  Up: Protracker extended effects

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

   Like *Note Slide volume:: down, except it occurs only once on the
0th tick

   Scrolling mode:
        1 A-4   --5


File: tracker.info,  Node: Cut note,  Next: Delay note,  Prev: Fine volume slide down,  Up: Protracker extended effects

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

   Set volume of current note to 0 on para-th tick.  _Note that this
does cut the sound, but the note continues playing_.

   Scrolling mode:
        1 A-4 cut 3


File: tracker.info,  Node: Delay note,  Next: Delay pattern,  Prev: Cut note,  Up: Protracker extended effects

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

   Start note on para-th tick instead of now.

   Scrolling mode:
        1 A-4 late 3


File: tracker.info,  Node: Delay pattern,  Next: Invert loop,  Prev: Delay note,  Up: 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 _don't_ occur once
every speed-th tick (the event change is inhibited).  Delay pattern is
a global effect.

   Scrolling mode:
        1 A-4 DLAY 3


File: tracker.info,  Node: Invert loop,  Next: Set tempo,  Prev: Delay pattern,  Up: Protracker extended effects

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

   See code for that weird effect.

   Scrolling mode:
        1 A-4 inv 3
     	1 A-4 inv off


File: tracker.info,  Node: Amiga audio hardware,  Next: Resampling details,  Prev: Set tempo,  Up: Technical Information

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

   Since part of the behavior of soundtracker-like programs depends
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 `VBLANK'
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


File: tracker.info,  Node: Resampling details,  Next: Amiga implementation,  Prev: Amiga audio hardware,  Up: 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 `resample.c' (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 `DO_NOTHING'/`PLAY'/`REPLAY' does. Each pitch
     value gives rise to a `step' value (see `notes.c' 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 `st_read.c') 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 occurs in the various
     `Arch/.../audio.c' 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 `Arch/common.c'.

   - 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 `oversample'. That way, we get
     `oversample' 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
     `oversample' 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 `oversample',
     the special `empty' sample and its properties ( `samp->fix_length
     == 0 && samp->rp_start == NULL').

   As a consequence, new sample styles (like 16 bit samples) should be
implemented as new types of commands like `DO_NOTHING', `PLAY', `REPLAY'
(`PLAY16' and `REPLAY16' 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 `for(i = 0; i < number; i++) loop', not initialising
`value[LEFT_SIDE]' and `value[RIGHT_SIDE]' 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 code.

   An important optimization may exist 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 function calls may be slightly slower. In that case, coercing your
linker to use static linking may be a good idea. If you can, link only
`Arch/machine/audio.c' and `resample.c' 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 can be improved.
Recently, I've added some optimization to `Arch/common.c'.  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 `(primary+secondary)/2'
and `(primary-secondary)/2' 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 `-over 2 -freq 44' and not!

   There is a switch in `Arch/common.c' (`NEW_OUTPUT_SAMPLES_AWARE')
used for compatibility. In older implementations of tracker, the
resample code called `output_samples(left_value, right_value)', where
left and right values were 23 bits signed. The newer version call is
`output_samples(left-value, right_value, width)', with width the number
of bits used. Newer ports should define `NEW_OUTPUT_SAMPLES_AWARE' and
use the code of `Arch/common.c' 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 `output_samples'.  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.


File: tracker.info,  Node: Amiga implementation,  Next: Concept Index,  Prev: Resampling details,  Up: 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 is 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 _without needing any kludge_.

   The old version used the timer `WAIT_EBLANK' 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, waits
for the right time to act on them, performs the sound changes, and
sends the message back to task 1.

   This offers lots of advantages.
   * 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.

   * 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 `scroll'
     works on almost any Amiga and any module unless you _really_ need
     too much processing power for it to work.(1)

   * because of the buffer, we _do_ 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:
   * 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 splits tracker into two distinct
     programs.

   * 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.

   * 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 `ReadEClock()' to get some feedback
     in the necessary buffer.

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

   * volume on a per-instrument basis,

   * volume on a track per track basis,

   * non-linear volume scaling,

   * on-the-fly transposition,

   * 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 hands 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.


File: tracker.info,  Node: aminet,  Next: Finding a specific file,  Prev: Background information,  Up: Top

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 for tracker, the place
where you can find the latest version.

   The following is adapted from aminet's official `readme'.

* Menu:

* Finding a specific file::
* Mirror sites of Aminet::
* Accessing Aminet on the Internet::
* Accessing Aminet without Internet::
* Copyright status and disclaimer::
* Background information::


File: tracker.info,  Node: Finding a specific file,  Next: Mirror sites of Aminet,  Prev: aminet,  Up: 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 `ftp.wustl.edu', `ftp.uni-paderborn.de' or
`ftp.doc.ic.ac.uk'

   Sometimes you are looking for a certain category of file without
knowing a name. You then best go by directory. The directories within
`/pub/aminet/' 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
`TREE'.  A local `INDEX' with descriptions is in each subdirectory,
however it only lists the files that exist on that site, not the ones
available elsewhere on Aminet.


File: tracker.info,  Node: Mirror sites of Aminet,  Next: Accessing Aminet on the Internet,  Prev: Finding a specific file,  Up: 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
`ftp.wustl.edu', `ftp.uni-paderborn.de' and `ftp.doc.ic.ac.uk'  keep
all files.  *Whenever possible, use the mirror that is the closest to
your place.  Most mirrors get updated three times a day.*

     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


File: tracker.info,  Node: Accessing Aminet on the Internet,  Next: Accessing Aminet without Internet,  Prev: Mirror sites of Aminet,  Up: 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 `misc/unix/adt*.c' and compile it on your UNIX box by
     typing `sh adt.c'.

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

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

telnet
     `ftp.doc.ic.ac.uk' 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
     `ftp.wustl.edu'. 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 `finger aminet@ftp.wustl.edu' or `finger aminet@ftp.eunet.ch'

gopher
     Gopher is specially supported by several Aminet sites. Just type
     `gopher <sitename>' or `gopher -p <startpoint> <sitename>'.

            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


File: tracker.info,  Node: Accessing Aminet without Internet,  Next: Copyright status and disclaimer,  Prev: Accessing Aminet on the Internet,  Up: 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
     `docs/misc/CD-Orders.txt'.

   - 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)



File: tracker.info,  Node: Copyright status and disclaimer,  Next: Background information,  Prev: Accessing Aminet without Internet,  Up: 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.


File: tracker.info,  Node: Background information,  Next: aminet,  Prev: Copyright status and disclaimer,  Up: 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 (`ab20.larc.nasa.gov') 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.


File: tracker.info,  Node: Credits,  Next: History,  Prev: Reporting bugs,  Up: Top

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.

*Oleg Bartunov (megera@sai.msu.su)*
     Minor bug report

*Mike Battersby*
     Linux, Makefile design

*Andrew A. Chernov (ache@astral.msk.su)*
     FreeBSD port, various

*Doug Cook (cook@sgi.com)*
     SG Wiz

*Liam Corner*
     original program

*Yannis Delmas-Rigoutsos (Yannis.Delmas@ens.fr)*
     nit-picking

*Matthew Donaldson*
     bug-report

*Roger Espel Llima (espel@ens.fr)*
     bug-report

*Nico Francois (nico.francois@scala.com)*
     permission to use ppdecrunch

*Looc Grenii (Loic.Grenie@ens.fr)*
     bug-report

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

*Markus Gyger (mgyger@itr.ch)*
     hp port

*Steve Haehnichen (shaehnic@ucsd.edu)*
     first PC port

*Stephen Hocking (sysseh@devetir.qld.gov.au)*
     Network audio port

*Joerg-Cyril Hoehle*
     bug-report

*Emil Johansson*
     Protracker semantics

*Reinhard Katzmann*
     Amiga help

*Andrzej Kotanski (kotanski@zeus02.desy.de)*
     MM1 port

*Petri Kuittinen (eye@niksula.cs.hut.fi)*
     SG beta test

*Bo Kullmar (bk@kullmar.se)*
     bug-report

*Thomas R. Lawrence*
     old port to the macintosh

*Andrew Leahy (A.Leahy@st.nepean.uws.edu.au)*
     Dec port

*Kang-Jin Lee (lee@tengu.in-berlin.de)*
     bug-report

*Jim Leonard (trixter@trxhome.mwc.com)*
     useful discussions

*Dev Mazumbar (dev@netcom.com)*
     AudioWare port

*Cyrille Micheneau*
     volunteered some help

*Bruno Monsuez (Bruno.Monsuez@ens.fr)*
     OS/2 port

*Francis Mouthaud (u220@esigetel.fr)*
     much stuff

*Darryl Okahata (darrylo@sr.hp.com)*
     hp 3 port

*Andreas Pahlsson (z94an0pa@isy.liu.se)*
     bug-report

*Pascal Rullier*
     volunteered some help

*Hannu Savolainen (hannu@voxware.pp.fi)*
     Linux port

*Frank M. Siegert (frank@miranda.tue.schwaben.de)*
     NextStep port

*Bjoern Stabell (bjoerns@staff.cs.uit.no)*
     hp port

*Dave Tiller (dtiller@cscsun.rmc.edu)*
     Solaris/sun incompatibilities

*Lukas Wunner*
     bug-report


File: tracker.info,  Node: Concept Index,  Next: Top,  Prev: Amiga implementation,  Up: (dir)

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

* Menu:

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



Tag Table:
Node: Top195
Node: Introduction1599
Ref: Introduction-Footnote-15395
Ref: Introduction-Footnote-25584
Node: Availability5713
Node: Registration7544
Node: Reporting bugs9208
Node: History10041
Node: Installation20723
Node: Configure tracker21135
Node: Generic problems21982
Node: Performance issues25288
Node: Architecture dependent problems27765
Node: Aix28133
Node: Amiga28475
Node: DECstation32234
Node: HP/UX33297
Node: Linux/FreeBSD36657
Node: MM1/OS937832
Node: NAS39103
Node: NextStep39946
Node: OS/241942
Node: Silicon Graphics42278
Ref: Silicon Graphics-Footnote-143203
Node: Sparc43292
Node: Porting tracker45848
Ref: Porting tracker-Footnote-153004
Ref: Porting tracker-Footnote-253059
Node: Usage53150
Ref: Usage-Footnote-158762
Ref: Usage-Footnote-258894
Node: Technical Information59000
Node: Tracker memory consumption59580
Node: The Protracker format62407
Node: The Protracker file format63046
Ref: The Protracker file format-Footnote-164111
Ref: The Protracker file format-Footnote-264240
Ref: The Protracker file format-Footnote-364581
Ref: The Protracker file format-Footnote-464791
Ref: The Protracker file format-Footnote-564969
Ref: The Protracker file format-Footnote-665210
Ref: The Protracker file format-Footnote-765230
Ref: The Protracker file format-Footnote-865451
Ref: The Protracker file format-Footnote-965549
Ref: The Protracker file format-Footnote-1065724
Node: Decoding pattern information65946
Ref: Decoding pattern information-Footnote-167980
Ref: Decoding pattern information-Footnote-268110
Node: Soundtracker and Protracker tempo68429
Node: Protracker finetunes69161
Ref: Protracker finetunes-Footnote-170632
Node: Sample numbers and note periods70724
Node: Base effects71502
Ref: Base effects-Footnote-172828
Node: Arpeggio72862
Node: Portamento up73503
Node: Portamento down73972
Node: Tone portamento74458
Node: Vibrato75454
Node: Tone portamento + Volume slide76845
Node: Vibrato + Volume slide77332
Node: Tremolo77730
Node: Set sample offset78189
Node: Slide volume78654
Node: Far jump79176
Node: Set volume79621
Node: Pattern break79976
Ref: Pattern break-Footnote-180446
Node: Set tempo80501
Node: Protracker extended effects81466
Ref: Protracker extended effects-Footnote-182618
Node: Set filter82656
Node: Fine portamento up82970
Node: Fine portamento down83408
Node: Glissando control83859
Node: Set vibrato waveform84300
Node: Set finetune85034
Node: Loop pattern85426
Node: Set tremolo waveform85902
Node: Retrig note86307
Node: Fine volume slide up86563
Node: Fine volume slide down86871
Node: Cut note87182
Node: Delay note87499
Node: Delay pattern87736
Node: Invert loop88163
Node: Amiga audio hardware88412
Ref: Amiga audio hardware-Footnote-190294
Node: Resampling details90413
Node: Amiga implementation97100
Ref: Amiga implementation-Footnote-1101841
Node: aminet102154
Node: Finding a specific file102808
Node: Mirror sites of Aminet104285
Node: Accessing Aminet on the Internet106586
Node: Accessing Aminet without Internet108775
Node: Copyright status and disclaimer118470
Node: Background information119385
Node: Credits120981
Node: Concept Index123306

End Tag Table
