
Support for playing mod files is primitive.

Playing files with lots of notes, reverb, and chorus depth when
Linux is busy may cause mp/xmp to report "<x> seconds behind" and
hang.

xmp does not work correctly when the system is supplied with
32 megabytes of ram (I am told by Istvan Bernath).

Spurious notes are played at the very ends of some songs.

mp/xmp do not exit promptly at the ends of some songs.

I haven't tested recently mp's facility for recording new tracks.
It probably doesn't work any more.

mp/xmp may turn up their nose at a file, reporting "midifile error:
expecting MTrk", when there isn't anything fundamentally wrong with
the file.  One can fix it by disassembling with "midt fname >fname.mt",
then reassembling with "tm fname".

Sometimes xmp stops updating its display and remains inactive until
the mouse pointer is moved into one of its windows.  I think it's
a bug in XView.  (This rarely happens with Xview 3.2.)

The xmp file menu is not sorted, and the main menu is not revised
to reflect changes in the directory whose contents it is displaying.
Submenus for directories with a large number of files take a long
time to construct.

Occasionally, notes to an external synth are not properly turned off.
(Possibly note-on events are missed also, but this is harder to hear.)
Also, sometimes they are delayed.  It's my suspicion that this is a
problem with the PAS16 (which is what I have).

Some voices defined in the fm voice libraries are not pleasant sounding,
and many of them are not authentic at all.  (I don't even know what
a "mute cuica" is, for example, except that it's a thing you scrape the
the inside of, and it's one of the general midi percussion voices.)
I hope that someone with a good ear and a lot of patience will improve
these patches.

Midi controller messages are all passed right along to an external
synthesizer.  One can only hope they are not misinterpreted.  Some
controller messages are not interpreted for sound cards -- phaser
depth, e.g. (I don't know what it is).  Pitch bend sensitivity messages
are not necessarily interpreted in the standard way (whatever that
is).

In recording new tracks with mp -r, tempo changes in the file being
played are not correctly taken account of in the track being
recorded.  A constant tempo equal to the last tempo specified in the
midi file is assumed, or else the default 500000, if no tempo was
given.  For "ad -r", the midi tempo is always the default.

Keeping the number of simultaneously sounding notes sent to the
external synth <= XPOLYPHONY or the gus <= WPOLYPHONY is done only
by mp, not ad.  Counting the number of simultaneously sounding notes
is only done on a track-by-track basis, so it doesn't work well for
multitrack midi files.

Ad does not do drum rolls (however the roll notes are present in an
adagio file created with mp -a).

