Check your sound device setup. A common problem are ASIO drivers that cannot share the audio interface, such as ASIO4All. If you use ASIO4All (or a WASAPI / WDM-KS driver in exclusive mode) and have another application running that makes use of that sound device (such as a web browser, instant messenger, media player, ...), OpenMPT will not emit any sound. In that case, switch to another sound driver in OpenMPT’s settings.

Vice versa, it is also possible that another program occupies the sound device in exclusive mode, for example using an exclusive WASAPI driver. In that case, this program restricts other applications from accessing the sound device.

Verify that no other application is accessing the MIDI port. Standard MIDI drivers only allow one application at a time to access a MIDI port.

Verify that other applications do actually receive incoming MIDI data. More often than not, MIDI devices are not set up properly to send MIDI data to a computer. A light-weight application that can be used for checking is SendSX.

OpenMPT produces clicks at a buffer length that previously worked just fine[edit]

In OpenMPT 1.22 and newer, the sound card options require you to enter the wanted latency, while previously you entered the buffer length of a single buffer. While the two values (latency and buffer length) are identical for ASIO drivers, there is a difference with Wave Out and DirectSound drivers: Previously, three buffers of the specified buffer length were used to render audio, meaning that the actual latency was three times the buffer length — hence, if you previously used a buffer length of 40ms, this equals a latency of 120ms now. The update interval was previously fixed to an eighth of the buffer length and is now freely configurable. It should be as low as possible, but too low values can result in buffer underruns, because the CPU can't keep up with the required short-term render speed.

So, to summarize: No, OpenMPT did not become slower. It just exposes different (more logical) values to the user now, and using the same old values for those new settings will most likely not work. The old values are automatically converted to their new equivalents, though, so there should not be any problems.

Because the theoretical goal of a good resampling filter and the practical low fidelity of many old module samples do not mix very well.

OpenMPT must resample all samples to a common mix sample rate (which is typically 44 or 48 kHz). This resampling step can be done using filters (interpolation) of varying quality. A perfect filter would not add any frequencies to the output signal that were not in the input signal. But such a perfect filter does not exist, and OpenMPT instead offers several filters of varying quality and speed (higher quality filters stress the CPU more than lower quality filters).

If modules were only using high-quality samples that already contain enough high-frequency content, i.e. samples that are being played close at the mix sample rate, you could always just use OpenMPT’s highest-quality resampling filter and everything would sound bright and nice. However, many modules rather use samples that use a much lower sample rate, which means that these samples theoretically do not contain any high-frequency material. But when using a low-quality resampling filter (e.g. linear resampling, as it was used in many trackers in the 1990s), the cheap algorithm cannot prevent ghost frequencies (so-called aliasing) from occurring, so these low-quality samples end up sounding much brighter than they should in theory — this is a wanted effect in many legacy modules. On the other hand, using a high-quality resampling filter will suppress these aliasing frequencies better and the module will in return sound muffled.

This is why older modules and chiptunes typically sound better with “worse” resampling filters, while a high-quality module with good samples will sound better with OpenMPT’s best resampling filters.

In the Pattern Editor, either click the yellow question mark icon or the pattern number in the upper-left corner of the pattern (labelled #0 or similar) to open the Pattern Properties window. Note that this feature is not available for MOD and S3M files, you will have to use pattern break commands in those formats to shorten patterns.

OpenMPT shows the default volume (that is, the volume at which the note is going to be played if it is not explicitely overridden by the user) next to notes as a semi-transparent volume command. Since this command does not actually exist in the pattern, it can also not be deleted. Display of the default volume can be disabled by unchecking the “Show default volume commands” option.

Actually, they do not do anything. They are just separators which you can use to keep your sequence tidy. You can for example add them after every few patterns to visually highlight a group of patterns. If such a pattern is encountered while playing, OpenMPT simply skips over it.

If you have “Follow Song” enabled, but the pattern display scrolls only in coarse steps, you have probably set the update period too high. Try setting this value as low as possible. However, if it is too low, audio output might distort with Wave Out drivers, in which case you have to lower the latency as well. Generally you want both your latency and update interval to be as small as possible, but the lowest possible values always depend on the available drivers and CPU power.

Have a look at our top picks site for various interesting sample sources. The Waveworld and KIArchive collections in particular offer a fairly complete set of samples that covers most types of sounds you will need to get started.

OpenMPT supports loading MP1 / MP2 / MP3 samples using Media Foundation on Windows 7 and newer. On older systems and Wine, you will need the mpg123 library, but due to the patent status of the MPEG technology, this library is not shipped with OpenMPT. Detailed instructions on where to download and how to install the library can be found in the Sample Editor help section.

Some plugins do not like if the plugin host sends varying amounts of audio data to be processed by them. While sequencers usually always send the same amount of data to plugins to process, this is not the case with most trackers, including OpenMPT, Psycle and Renoise (if its static plugin buffer is disabled). If you encounter such a plugin, please notify the plugin authors of the problem so that they can make the plugin compatible with hosts like OpenMPT. Note that the problem in jBridge should have been fixed, so if you still experience it, try upgrading to the latest version.

Yes, OpenMPT comes with its own plugin bridge that can load 32-bit plugins into 64-bit OpenMPT and vice versa. OpenMPT will automatically use this plugin bridge when required, but it can also be enabled manually in the Plugin Manager to sandbox troublesome plugins.

Oops, seems like you downloaded a 64-bit version of OpenMPT without reading the recommendation on which version to use! If you use lots of 32-bit plugins, do not use 64-bit OpenMPT, as it will have to run all your plugins in a bridge process (sandbox), which is much slower than running plugins directly in OpenMPT.

The frequency of the middle-C is fixed to about 8 kHz in the MOD format. OpenMPT tries to compensate for that by transposing notes in the patterns. In some corner cases, this will fail. Also keep in mind that the MOD octave range is limited, so some samples might have to be downsampled before they can be transposed without loss of note information.

Some less compliant module libraries will fail to load perfectly valid XM / IT files. You can try re-saving those files with Fasttracker 2 or Impulse Tracker if necessary, or just avoid using those libraries. Note that libmikmod 3.2 has fixed a bug which would prevent it from loading XM files made with OpenMPT. This will probably never be backported to Winamp’s MikMod-based module plugin, so if you seriously want to listen to modules in Winamp, you should probably try the OpenMPT input plugin for Winamp instead. ;-)

Can you add support for SID / SNDH / AHX / AdLib / other formats?[edit]

As a general rule of thumb, we will not add support for file formats that do not contain pattern data (like SID / SNHD), that require a bytecode interpreter for specific hardware (SID / SNDH), sample synthesis (AHX) or any other kind of chip emulation (SID / SNDH / AdLib). These formats are way too different from how tracked music is handled internally by OpenMPT, and there are already far better solutions out there.

Why is previously usable Feature X unavailable in the latest version of OpenMPT?[edit]

Over the years, various people have added features to the IT and XM format without considering that other trackers or players would not support them.
Having new features is of course a nice thing, but they should not be hacked into existing file formats. That is why they are gradually removed from the IT and XM formats to be exclusively available in the MPTM format. Of course, these features are still available when importing an old IT or XM file made with previous versions of OpenMPT, but you cannot use them in newly created files.

Examples of previously supported features are Tempo Mode, Envelope Release Node, Pitch / Tempo lock, etc..
If you want to access those features, use the MPTM format. You can convert existing songs to this format using the Song Properties dialog.

Some crashes prevent OpenMPT from creating its own memory dump. In that case, there are other ways to create a dump:

On Windows Vista and newer, open the task manager and right-click the crashed instance of mptrack.exe in the process list and select Create Dump File. On 64-bit systems, please do not use the default task manager — launch it from %SystemRoot%\SysWOW64\taskmgr.exe instead! (Source: [1])

On older operating systems, or in case the previous option might not be available, use ProcDump. Find out the PID of the crashed instance of mptrack.exe through tasklist.exe on the command prompt or by using the task manager (the PID column in the process list might be hidden by default), then run procdump PID. Note that you can also run procdump -e PID before the actual crash happened. If ProcDump has the chance of catching the exception, it will automatically write a crash dump then.