Relevant IRC chat log:

dansalvato

10:41:42

Hello, I have a quick question about libopenmpt and whether it's suitable for my use case. I'm looking to play a module, not to render the audio, but to capture the state of each channel on every tick. That is, on each tick, the current sample being played, position in the sample, its current pitch/rate, current volume, etc. Does the API expose this information? I don't immediately see anything in the docs for it.

@Saga_Musix 

10:42:58 

This information is unfortunately not directly available from the API.

If you have a proposal what kind of information you need, you can post it on our issue tracker though, and we can see if a suitable API could be introduced.

other people have probably achieved similar information retrieval by directly hacking the source, but having something like that as an official API could be useful.

dansalvato 

10:49:08 

Got it, I appreciate the suggestion. I'm currently using an XM library that does this and was hoping to extend support to MPT and other module formats. I'll bring it up on the issue tracker for consideration.

@Saga_Musix 

10:50:23 

one challenge that an XM library doesn't have but OpenMPT faces due to supporting more advanced format is that there is not always a 1:1 mapping between pattern and mixer channels

for example you have New Note Actions in the IT format, which allow to keep playing a note when a new note is triggered on the same channel. these background channels would need to be exposed to the API as well, in a way that isn't bound to OpenMPT implementation details of background channels.

dansalvato 

10:51:39 

That's true, I hadn't considered that there are tracker formats which are playing multiple samples at the same time on a single channel

dansalvato 

11:04:41 

There's a new-ish Amiga playback format called LSP that is effectively a list of pre-baked commands to set sample, volume, and pitch for each channel on a per-tick basis (for minimum CPU overhead). The idea is to take a typical module and bake each tick's playback state into the LSP bytestream. So theoretically, you can convert any 4-channel module into LSP to be used in Amiga demos, games, etc., discarding some info like pan. It was designed with MOD in mind, but I have a working XM-to-LSP compiler, and it would be fairly straightforward to add support for any other module format which exposes that per-tick information in a library.

@manx 

11:08:48 

While we intend to sometime provide tick-level access to the playback state, we have no intention to provide tick-level access to the parsed file format. The latter is strictly out-of-scope, because we do not want to be a format loading/parsing library and/or a library suitable for implementing a tracker on top of it.

@manx 

11:10:50 

OpenMPT and libopenmpt (to a lesser extent, but still) convert all loaded formats into an internal format. This inevitably causes some format-specific information to be lost, making it infeasible to provide absolutely accurate format-specific data.

@manx 

11:12:31 

What we (roughly so far) intend to provide, would be some form of API that exposes individual steps of the playback logic, such that client code can drive it from the outside. https://bugs.openmpt.org/view.php?id=1017 has some discussion on that.

dansalvato 

11:17:52 

Makes sense, and in this case I'm not actually looking for any format-specific data, just raw playback state such as current sample, sample position, volume, and pitch/samplerate. I can see that being generally useful for others like myself who are doing data processing on modules, and it plays into the strengths of OpenMPT that you've done the heavy lifting to parse many tracker formats into that common representation.

dansalvato 

11:25:39 

For example, the OpenMPT software has the automatic sample trimmer, which I'm sure is made possible by keeping track of the lower and upper bounds of each sample that actually receives playback. It's a feature I've seen in other "module optimizer" software, which would use some module playback library that provides per-tick information on sample state. It's one of various things that could be done better and with wider support if libopenmpt were to expose some of that state.

@manx 

11:27:55 

I am not sure we want to go that deep into exposing mixer state, though. The sample position would be quantized to the time points where a tick happens, and would not be usable for this. This is precisely the "implementing a tracker on top of libopenmpt" that we rather do not want to go into.

dansalvato 

11:40:46 

That's understandable. With my current lack of knowledge on OpenMPT's internals, I doubt I can offer any more meaningful feedback. But I'll take the suggestion of Saga_Musix and open an issue in the issue tracker to continue discussion and give myself a bit of time to do some research. I'm thinking/hoping that libopenmpt could expose some useful info for data processing without (as you put it) going full-on tracker.

@manx 

11:44:12 

feel free to also just copy-paste this chat log for reference into the issue

chat logs get lost and forgotten, issues in the issue tracker not so much :)

dansalvato 

11:52:25 

Actually, the main problem with those current "module optimizers" is exactly what you mention, with sample position being quantized to the tick points. It requires them to guess and/or give the sample some arbitrary padding to account for the quantization. So maybe as you suggest, libopenmpt would have no need/desire to work like a tracker and expose ticks, but rather can just be queried for state at a given timestamp. That's not only more flexible, but possibly more in line with the purpose of libopenmpt, in that it's providing information about what's going on during playback.