How to add support for new module formats
=========================================

This document describes the basics of writing a new module loader and related
work that has to be done. We will not discuss in detail how to write the loader,
have a look at existing loaders to get an idea how they work in general.

General hints
-------------
* We strive for quality over quantity. The goal is not to support as many module
  formats as possible, but to support them as well as possible. 
* Write defensive code. Guard against out-of-bound values, division by zero and
  similar stuff. libopenmpt is constantly fuzz-tested to catch any crashes, but
  of course we want our code to be reliable from the start.
* Every format should have its own `MODTYPE` flag, unless it can be reasonably
  represented as a subset of another format (like Ice Tracker ICE files being
  a subset of ProTracker MOD).
* When reading binary structs from the file, use our data types with defined
  endianness, which can be found in `common/Endianness.h`:
  * Big-Endian: (u)int8/16/32/64be, float32be, float64be
  * Little-Endian: (u)int8/16/32/64le, float32le, float64le

  Entire structs containing integers with defined endianness can be read in one
  go if they are tagged with `MPT_BINARY_STRUCT` (see existing loaders for an
  example).
* `m_nChannels` **MUST NOT** be changed after a pattern has been created, as
  existing patterns will be interpreted incorrectly. For module formats that
  support per-pattern channel amounts, the maximum number of channels must be
  determined beforehand.
* Strings can be safely handled using:
  * `FileReader::ReadString` and friends for reading them directly from a file
  * `mpt::String::ReadBuf` for reading them from a struct or char array

  These functions take care of string padding (zero / space padding) and will
  avoid reading past the end of the string if there is no terminating null
  character.
* Do not use non-const static variables in your loader. Loaders need to be
  thread-safe for libopenmpt.
* `FileReader` instances may be used to treat a portion of another file as its
  own independent file (through `FileReader::ReadChunk`). This can be useful
  with "embedded files" such as WAV or Ogg samples. Container formats are
  another good example for this usage.
* Samples *either* use middle-C frequency *or* finetune + transpose. For the few
  weird formats that use both, it may make sense to translate everything into
  middle-C frequency.
* Add the new `MODTYPE` to `CSoundFile::UseFinetuneAndTranspose` if applicable,
  and see if any effect handlers in `soundlib/Snd_fx.cpp` need to know the new
  `MODTYPE`.
* Do not rely on hard-coded magic numbers. For example, when comparing if an
  index is valid for a given array, do not hard-code the array size but rather
  use `std::size` (or `mpt::array_size` in contexts where `std::size` is not
  usable) or, for ensuring that char arrays are null-terminated,
  `mpt::String::SetNullTerminator`. Similarly, do not assume any specific
  quantities for OpenMPT's constants like MAX_SAMPLES, MAX_PATTERN_ROWS, etc.
  These may change at any time.
* Pay attention to off-by-one errors when comparing against MAX_SAMPLES and
  MAX_INSTRUMENTS, since sample and instrument numbers are 1-based. 
* Placement of the loader function in `CSoundFile::Create` depends on various
  factors. In general, module formats that have very bad magic numbers (and thus
  might cause other formats to get mis-interpreted) should be placed at the
  bottom of the list. Two notable examples are 669 files, where the first two
  bytes of the file are "if" (which may e.g. cause a song title starting with
  "if ..." in various other formats to be interpreted as a 669 module), and of
  course Ultimate SoundTracker modules, which have no magic bytes at all.
* Avoid use of functions tagged with MPT_DEPRECATED.

Probing
-------
libopenmpt provides fast probing functions that can be used by library users
to quickly check if a file is most likely playable with libopenmpt, even if only
a fraction of the file is available (e.g. when streaming from the internet).

In order to satisfy these requirements, probing functions should do as little
work as possible (e.g. only parse the header of the file), but as much as
required to tell with some certainty that the file is really of a certain mod
format. However, probing functions should not rely on having access to more than
the first `CSoundFile::ProbeRecommendedSize` bytes of the file.

* Probing functions **must not** allocate any memory on the heap.
* Probing functions **must not** return ProbeFailure or ProbeWantMoreData for
  any file that would normally be accepted by the loader. In particular, this
  means that any header checks must not be any more aggressive than they would
  be in the real loader (hence it is a good idea to not copy-paste this code but
  rather put it in a separate function), and the minimum additional size passed
  to `CSoundFile::ProbeAdditionalSize` must not be higher than the biggest size
  that would cause a hard failure (i.e. returning `false`) in the module loader.
* Probing functions **may** return ProbeSuccess for files that would be rejected
  by a loader after a more thorough inspection. For example, probing functions
  do not need to verify that all required chunks of an IFF-like file format are
  actually present, if the header makes it obvious enough that the file is
  highly likely to be a module.

Adding loader to the build systems and various other locations
--------------------------------------------------------------
Apart from writing the module loader itself, there are a couple of other places
that need to be updated:
* Add loader file to `build/android_ndk/Android.mk`.
* Add loader file to `build/autotools/Makefile.am`.
* Run `build/regenerate_vs_projects.sh` / `build/regenerate_vs_projects.cmd`
  (depending on your platform)
* Add file extension to `installer/filetypes.iss` (in four places).
* Add file extension to `CTrackApp::OpenModulesDialog` in `mptrack/Mptrack.cpp`.
* Add format information to `soundlib/Tables.cpp`.
