libopenmpt emscripten port

[RyanBram]

Why don't you use an actual javascript MIDI player rather than libopenmpt, which would be much more suitable for what you are trying to do, and most likely smaller as well? I know there are some MIDI players written in JavaScript, so you should definitely check them out.

I have some reason for not doing that:

1. Inconsistency of sound. I don't find any javascript that able to play sf2 format. Most MIDI Player js rely on underlying operating system sound banks which make my game sounds different in each platform (especially Android)

2. Bigger distribution size. Although if I found one, the combination of the MIDI Player js + sf2 + MIDI music files will be much bigger than combination of libopenmpt + mo3 music files which are almost as small as MIDI files

3. Harder to improve sound quality. In MIDI, quality of sounds depend on shared sound bank, while in MO3, I can "patch" the sample with higher quality in relative easier way. As someone who come from MIDI world, it may takes several more years for me to be able to create Module from stratch, therefore the current method for creating music is by creating in piano roll first, converting to MPTM, then replacing the sound banks with the higher quality and many other improvent in OpenMPT.

Anyway many thanks for the solutions.

[Saga Musix]

1. Inconsistency of sound. I don't find any javascript that able to play sf2 format. Most MIDI Player js rely on underlying operating system sound banks which make my game sounds different in each platform (especially Android)

There is no underlying operating system a javascript MIDI player can be borrowing its samples from. You must have been looking for something different.
A 1-second Google search brought up this, which plays soundfonts but leaves the MIDI file decoding up to the user: https://www.npmjs.com/package/soundfont-player
I am sure someone built a full MIDI player based on it, or on some other source.

2. Bigger distribution size. Although if I found one, the combination of the MIDI Player js + sf2 + MIDI music files will be much bigger than combination of libopenmpt + mo3 music files which are almost as small as MIDI files

That is wrong. If you spend the time removing unused samples from module files, you can just as well spend the time removing unused instrument from your SF2 file. In fact, if several MIDI files use the same instruments, the soundfont approach is smaller. There are also ways to compress sf2 or sfz soundfonts.

3. Harder to improve sound quality. In MIDI, quality of sounds depend on shared sound bank, while in MO3, I can "patch" the sample with higher quality in relative easier way.

Soundfont editors are a thing.

[manx]

Staying on the original topic here, the only thing that can be reasonably removed and actually gain something is MO3 support because we can skip the Ogg Vorbis and MP3 decoders in that case. I'm not sure how much is saved, but my guess would be some about 100kB.
However, that's not useful in your case because you want MO3 support.
There are also other module playback libraries that work when compiled with emscripten. The most popular example being libxmp. However, libxmp does not support MO3 either.
libxmp is smaller than libopenmpt though. There are various reasons for that (a big contributing factor is the fact that libopenmpt is written in C++ while libxmp is written n C, which requires the whole C++ standard library to be included in the emscripten build). In any case, neither this nor any other contributing factor are likely (or possible at all) to change in libopenmpt.

[Saga Musix]

Staying on the original topic here, the only thing that can be reasonably removed and actually gain something is MO3 support because we can skip the Ogg Vorbis and MP3 decoders in that case. I'm not sure how much is saved, but my guess would be some about 100kB.

Even less if we're talking about the compressed version - if I recall correctly, adding the MP3 / Vorbis decoders was about 50kB of overhead or so in the gzipped version.

[RyanBram]

Many thanks for the solutions Manx and Saga.
No matter what the reasons, I have my own personal interest for creating game with tracker music. Maybe it is just because I don't really like separation of notes with its sounds. And the 1-second Google from Saga doesn't bring me to sf2 player, because the js player actually needs an sf2 to be extracted with ruby based script extractor to become many parts of mp3 files.
At the end, with your answers, I think it is better to stay with libopenmpt instead of using another library, such as libxmp.

Out of curiosity, I read in previous topic that emscripten is categorized as supported platform. Does it mean that there is a plan someday to distribute libopenmpt.js s precompiled binary alongside openmpt123.exe, xmp-openmpt.dll, and in_openmpt.dll?

Sorry for any inconvenience.

[manx]

Out of curiosity, I read in previous topic that emscripten is categorized as supported platform. Does it mean that there is a plan someday to distribute libopenmpt.js s precompiled binary alongside openmpt123.exe, xmp-openmpt.dll, and in_openmpt.dll?

This will probably happen in the near future (some weeks), yes. But that version will not have MP3 support, and thereby no MO3 support, due to legal reasons. We could maybe include a Vorbis-only MO3 decoder though, but AFAIK this will be a bit more work.

[manx]

Out of curiosity, I read in previous topic that emscripten is categorized as supported platform. Does it mean that there is a plan someday to distribute libopenmpt.js s precompiled binary alongside openmpt123.exe, xmp-openmpt.dll, and in_openmpt.dll?

https://buildbot.openmpt.org/builds/auto/libopenmpt-bin.js/
I think, Vorbis-only MO3 should work.

[RyanBram]

Hi, Manx.

Thanks for the great news.
I have tested the precompiled libopenmpt.js by buildbot. The result is most of OpenMPT supported format are work out of the box, the only exception are vorbis encoded MO3 and lossless MO3.
I tested by replacing libopenmpt.js in Chiptune2.js github master with one from buildbot.

[Saga Musix]

I think, Vorbis-only MO3 should work.

MPT_ENABLE_MO3_BUILTIN (and MPT_WITH_STBVORBIS) is not defined by default, so currently no MO3 support gets compiled at all.

[manx]

I think, Vorbis-only MO3 should work.

MPT_ENABLE_MO3_BUILTIN (and MPT_WITH_STBVORBIS) is not defined by default, so currently no MO3 support gets compiled at all.

As far as I can see, MPT_WITH_STBVORBIS is enabled by default, but MPT_ENABLE_MO3_BUILTIN is not, because no MP3 decoder is enabled.
I don't know if we actually want to change or support that. It would result in systems having no MP3 decoder and no Un4seen unmo3 actually getting MO3 support via the internal MO3 decoder, but it will only be able to successfully decode some MO3 files. Other files would get loader warnings of course, but I would prefer to not even try the internal decoder unless it can decode all the possible sample formats. The testing matrix is already complicated enough in that area.

[Saga Musix]

Right, I remember that we briefly discussed this and I agree that the default should be either full or no support. If someone wants partial MO3 support, they should compile their own version.

[manx]

I should tune the build system to not include stb_vorbis in Emscripten builds by default though, as it's totally useless.

[RyanBram]

... But that version will not have MP3 support, and thereby no MO3 support, due to legal reasons. ...

Hi.
MP3 patent has expired now. Is it possible for OpenMPT developers to re-consider the inclusion of complete MO3 support in emscripten version of libopenmpt?

Thanks.

News:
https://www.theregister.co.uk/2017/05/16/mp3_dies_nobody_noticed/

[manx]

... But that version will not have MP3 support, and thereby no MO3 support, due to legal reasons. ...

MP3 patent has expired now. Is it possible for OpenMPT developers to re-consider the inclusion of complete MO3 support in emscripten version of libopenmpt?

libopenmpt has had MP3 support when built with emscripten for quite a while now. It is not enabled by default though.

We generally support both libmpg123 and minimp3 for MP3 sample support, but only minimp3 is tested with emscripten and has support in the Makefile build system. For simplicity and ease of use reasons, we statically link everything into a single library with emscripten. minimp3 (and also libmpg123) are LGPL licensed, which means, in the case of static linking, the whole resulting compiled binary (and thus also the used source code) would also be subject to LGPL licensing. As libopenmpt is BSD3 licensed, we do not want to have a default build configuration effectively change the license to LGPL, which is why we do not enable MP3 sample support for emscripten by default.

If you do not mind the license implications, you can just use make CONFIG=emscripten USE_MINIMP3=1 (works for both, libopenmpt 0.2 and libopenmpt 0.3). For libopenmpt 0.2 you have to download minimp3 yourself and put it into include/minimp3/ (I am considering actually shipping it in the next 0.2 release), for libopempt 0.3 it is already included.

libopenmpt 0.3 also has MO3 support enabled even without having MP3 sample support enabled (will just not load the MP3 encoded samples in this case, Vorbis encoded sample or uncompressed sample will work just fine). libopenmpt 0.2 automatically disables also Vorbis support (and I think also MO3 support completely, but I do not remember exactly (I can look it up if desired)), if not MP3 support is enabled.