OpenMPT released

Yep, OpenMPT 1.29 also didn't quite make it for Easter - some major features have been worked on in the previous months (improved MED and SFZ support among others), so we would like to give the release a bit more time and ensure it has the usual quality. However, some of the changes that have been done since Christmas have now been wrapped up in an OpenMPT 1.28 update:

  • When changing from modern tempo mode to classic or alternative tempo mode, the initial song tempo is now retained better.
  • Do not modify existing Parameter Control Events incorrectly when interpolating normal (volume) commands or notes.
  • Volume column tone portamento commands did not update portamento effect memory when seeking. XM volume column portamento quirks are now handled better when seeking.
  • When OPL instruments were set up as external samples, changing their parameters didn't mark them as modified.
  • IT: Vibrato was too fast in Old Effects mode since OpenMPT 1.27.
  • DMF: Some files had a wrong tempo since OpenMPT
  • Fixed potential crash when trying to save a file to a drive that no longer exists.

For a complete list of changes, have a look at the release notes and the full version history.

libopenmpt has also been updated.


Erik Kjellberg says:

Does anybody know if there are some skins or alternative gui that can make OpenMPT look more more like a regular daw in terms of "non-ugliness"? The software seems incredibly powerful but for new users in 2020 to wish to spend time enough to get to know the impressive power under the hood i imagine that they first must try it. Just looking at screenshots is not exactly making people go wild if they are using any other modern (or even oldschool) music production tool.

Kind regards,

Saga Musix says:

No, there is no easy way apart from Windows skinning tools that skin all your programs at the same time. OpenMPT's standard UI is one of its strongest points that allow it to be used by blind and otherwise disabled users, and being very lean on resources.

Bilbo says:

This was made as a modern 21st century all-in-one solution to emulate the old trackers built on the Amiga mods, which could only handle up to 4 channels at a time, and some only one voice active at a time (monophonic, not polyphonic).
It does exactly what it set out to do; exceedingly well. It's a fantastic port, and not really even an emulator. It has everything those tracker people would want, plus a ton of modern conveniences and advancements the old tracker programs could never dream of.
Maybe try Reaper (free), or spend some money and get ProTools, Logic, FL Studio, Ableton, etc.

Jordi de Jong says:

I actually love the interface. So nice to work with. However it would be nice to be able to colorcode tracks and patterns to be able to see what section is playing where. I know everything can be labeled, but coloring would be such a nice addition. I'll make a request on the forum.

Saga Musix says:

I have some unfinished code lying around for that (track colors at the top of the pattern editor, similar to Renoise), it's too late to get it into OpenMPT 1.29 but I think there is a possibility to make it work for OpenMPT 1.30.

Richard Craig says:

Nooooo never change it! I've been using OpenMPT since 1998, lol! Its consistency is why I've never moved to any other software in over 20 years!

Saga Musix says:

Don't worry. When / if OpenMPT gets a facelift (most likely happening when / if we switch to Qt for a cross-platform UI), it will be as gentle as possible for existing users, while hopefully also adding the possibility of custom skins for those who want it. But for the rest, OpenMPT will keep its native look.

Albet V says:

how possible is adding Brr samples directly to the sample section? i know i can always convert those, but the size from brr and wav is considerable! so any future update that might have BRR samples support?

Saga Musix says:

From my understanding, BRR files are just raw, header-less dumps of samples making use of SNES hardware compression, so directly importing them is difficult. You could always store the converted samples as FLAC, which is a lot smaller than WAV and most likely also smaller than the BRR equivalent.

Kinko says:

Some of us use a tool called SNESMod that converts .it files from OpenMPT into hardware playable music files for the SNES. Adding BRR support would just help streamline the process a little better for us.

Saga Musix says:

I've never heard that SNESMod would require samples in BRR format. Wasn't the important thing about the samples simply that loop start/end have to be multiples of 16 or something like that? Why would the target SNES compression format be relevant to the source file?

Anyway, as said, it's difficult to support the format as it's raw and header-less. OpenMPT cannot possibly know if a file really contains BRR-compressed data. If you want to work with BRR files, you will need some intermediate script which first contains them into some usable format that can be easily detected (WAV/FLAC for example).

Exodust says:

If you want a way to detect BRR samples, I suggest two things:

  • If the file's size is not 9n or 9n+2, you can instantly reject the sample. You can either require the 2-byte AddmusicM header (loop start offset in # of samples), or set it to 0 if absent.
  • If you check all 9-byte blocks and find that any block other than the last one has the LSB of the first byte set (or the last block's isn't set), you can reject the sample.

And no, SNESMod doesn't require samples in BRR format; it only outputs them such. And yes, the multiples-of-16-for-loops thing is tricky, but that can be automatically taken care of too (the C700 VST does this particularly well, though it has other issues).

nyanpasu64 says:

> You can either require the 2-byte AddmusicM header (loop start offset in # of samples), or set it to 0 if absent.

I think it's # of bytes, not samples.

Exodust says:

Whoops, you're right, thanks for catching that brainfart!

Saga Musix says:

Thanks for the information. It seems like with some very strict block validation and file size checks, it can be reasonably asserted whether a file is a BRR file or not. I think we can have BRR support in 1.30 (and maybe even the next 1.29 update).

Exodust says:

Happy to hear that!

I just thought of another addition to the validation to pin it down even more. If any of the 9-byte data blocks has the second bit of the first byte set and the file has no 2-byte header, you can't use the file, as the sample loops, but doesn't provide a loop offset. That, or you can imply that the offset is 0, but I would personally recommend against that.

Saga Musix says:

From my understanding from the BRRtools source code, it can write the loop flag but does not write the loop header, so that seems like a dangerous choice to make.

Anyway, BRR support has landed in trunk and will be available starting from OpenMPT If there are still any issues, please put them on the issue tracker, not in this comments section.