When adding support for file I/O inside libopenmpt anyway, we can also extend the API to to specify a filename directly instead of having the API user do the file loading. The single reason for not supporting that right now, is the lack of all direct file I/O inside libopenmpt.

A ctl for the existing functions might also be useful though. Not sure about that yet.

Another possibility might be to have libopenmpt provide the list of external filenames to the application and have the application issue an explicit load_instrument or load_sample call after loading the module had already been loaded by libopenmpt.

A variant of that approach would involve callbacks to the application while loading. However, that approach will be very difficult to implement in foreign language bindings.

Another possibility might be to have libopenmpt provide the list of external filenames to the application and have the application issue an explicit load_instrument or load_sample call after loading the module had already been loaded by libopenmpt.

This might not be feasible with all supported module formats, because sometimes patch-ups are done after loading the external file, but before giving control back to the application. For example in the ITP format, we first load an instrument file and then may override some of the instrument properties if "Embed instruments' header" is used. We would have to be able to do these patch-ups after loading the file, which would complicate the code in many ways. I do not like that idea at all.

From an implementation point-of-view, being able to use C++17 std::filesystem would simplify path traversal and related security issues a lot.

Another possibility might be to have libopenmpt provide the list of external filenames to the application and have the application issue an explicit load_instrument or load_sample call after loading the module had already been loaded by libopenmpt.

This might not be feasible with all supported module formats, because sometimes patch-ups are done after loading the external file, but before giving control back to the application. For example in the ITP format, we first load an instrument file and then may override some of the instrument properties if "Embed instruments' header" is used. We would have to be able to do these patch-ups after loading the file, which would complicate the code in many ways. I do not like that idea at all.

OK, I had kind of expected such complications, thus this possibility is not on the table any more.

We probably want at least 2 levels of external file loading:

1. files in the same directory as the module or in subdirectories below it
2. files in directories above the module or absolute paths

With option 1 being the safer subset of option 2.

Option 1 is also the more often seen and more useful variant. Option 2 is more likely to occur with unfinished / unreleased modules on an artist's computer.

For platforms like Emscripten, Startrekker (and possibly TFMX in the future) support might be the most interesting case (for example for listening to Startrekker files on ModLand online).

It's also the most peculiar case because we won't know in advance if the external instrument file will be present or not, and which file extension it will have. For a Startrekker module called foo.mod, the external instrument file could be named foo.mod.nt, foo.mod.NT, foo.mod.as or foo.mod.AS (ignoring mixed-case file extensions). It is also perfectly valid for this external instrument file to be missing in case no synthesized instruments are used. Emscripten can provide a virtual file system but as far as I understand, it won't help us when playing modules from an external source. Hence, a callback might be the most convenient way to handle this situation for Emscripten, even though it might send up to four bogus HTTP requests when loading a Startrekker module. Like in most other languages, Emscripten can use C callback functions.

This topic has been brought up again because emoon's new HippoPlayer would have to support this in its own plugin API, and one if its default plugins uses libopenmpt.
The callback function approach would have two benefits for us:

• It works with virtual file systems (e.g. when playing modules in zip files, or over the internet as in the emscripten example)
• Any path traversal logic would have to be done by the library user. Security would be their business, not ours.

In addition, any programming language that can interface in C should be able to use C callbacks (otherwise e.g. using the WinAPI would be more or less impossible).

The C callback function signature could look like this: bool LoadFile(const char *filename, void **data, size_t *size)

The callback function approach would have two benefits for us:

We alone would have to duplicate the security-conscious directory handling code at least twice in this case: once for openmpt123 and once for xmp-openmpt. We would not gain any ease of implementation either. Also, in the common use case of loading the files from a local file-system, this would unnecessarily complicate client code. APIs should be easy to use correctly and difficult to use incorrectly. Providing only a callback interface and offloading the responsibility to client code in this aspect would violate this API design principle.
However, I do think such a callback function could be useful in addition to libopenmpt's internal handling, in particular for players which can load from some kind of virtual internal file system. I do not think it should be the only option, and I do not think it should be the default option to handle this though.

I'd rather defer this feature yet again, because there are realistic chances that we could depend on std::filesystem for libopenmpt 0.6.