More interesting metadata would be retrieval of the time signature (rows per beat / rows per measure) - either the current time signature (least versatile), retrieve time signature by pattern ID, or some function to check if a given row is the start of beat or measure (most versatile, also supports more than one time signature per pattern, in case we ever need that).

This can be used for syncing or pattern drawing purposes.

It would probably make sense to have separate metadata APIs for numeric metadata, such as the aforementioned rows per beat stuff (unless we want to put that in its own API function, of course). For samples and instruments, this would also make sense. It would certainly be better than just having string-based metadata APIs where the user basically has to convert the string back to a float (or int) on every invocation.

I would like to get all the info from a sample/instrument. Name, size, loop start, sample data etc. Just return a vector with with the sample/class/structs. Take a look how libxmp did it.

Just want to add that this is something I want as well and including the sample data.

Including sample data would not really be "metadata" any more. It would be a useful feature nonetheless. But, when we include sample data, we could as well include pattern data. At that point, the issue would be somewhat equivalent to "diffing modules" (see https://bugs.openmpt.org/view.php?id=1493). It's kind of tricky where to draw the line here.

Right that makes sense. In my case I have have two use-cases for this:

1. Module "diffing" In my case it's to find duplicates in the modland ftp. I already calculates a hash for the pattern data in order to compare if it's the same. Having the sample data would allow me to do it on samples as well.
2. For my music player I'm thinking of potentially show samples (that are being played) as a visualizer and having the sample data would make it a bit more interesting.

I think there is quite a big difference between sample data and pattern data here. Sample data has a well-defined format - PCM - that is extremely unlikely to ever change, and thus can be easily exposed to library users. The raw pattern data has no fixed, well-defined format and may change at any point in time, and there are already limited retrieval options for that anyway. I'd rather treat those two as a completely independent things and not make the implementation of one depend on the other, and in particular I don't think that exposing sample data has to wait for module diffing to be implemented.

I think the current way of retrieving pattern data is good enough and I agree that these two shouldn't depend on each other. I also think it makes sense to expose sample data before diffing as it allows libopenmpt users (such as me) to just build "diffing" or whatever on top.

This'd be a very nice thing to have! It'd let us keep a general timeline of historical music for preservation purposes (including even the stats on the most popular samples :) and one's own library, too.

For OpenMPT like pattern view i miss openmpt_module_get_sample_default_volume.