View Issue Details

IDProjectCategoryView StatusLast Update
0001017OpenMPT[All Projects] libopenmptpublic2017-08-27 18:27
ReporterSaga MusixAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version 
Target Versionlibopenmpt 0.5 (goals)Fixed in Version 
Summary0001017: libopenmpt: Provide access to next play position
Description

PoroCYon asked on IRC if it's possible to retrieve the next play position (row/pattern). We already have this information, but it is currently not exposed.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

manx

manx

2017-08-27 06:38

administrator   ~0003194

Uhm, what would be the use case here?

I'd rather see this aspect to be factored into the already planned tick-boundary accurate playback.

Saga Musix

Saga Musix

2017-08-27 14:34

administrator   ~0003195

I can see use cases like OpenMPT's smooth pattern scrolling - depending on the next play position, you may have to scroll either up or down.

Saga Musix

Saga Musix

2017-08-27 18:07

administrator   ~0003196

Another use case is any general monitoring of pattern transitions. Let's say you want to do a transition to a different pattern once the current pattern has finished playing. Since the pattern may end on any row due to pattern break commands, it may not be known what is going to be the last row of the current pattern. If you want to solve this using tick-boundary rendering, you will have to throw away rendered audio for at least one tick, which I think would generally make control flow more complicated (and of course increase the required processing time).

manx

manx

2017-08-27 18:27

administrator   ~0003197

Another use case is any general monitoring of pattern transitions. Let's say you want to do a transition to a different pattern once the current pattern has finished playing. Since the pattern may end on any row due to pattern break commands, it may not be known what is going to be the last row of the current pattern.

In that case, the required API would be more narrow than what is required to solve this issue. It would only be necessary to query the next play position after a tick has been rendered completely. And I would be very much OK with an API only implementing exactly that (once we have tick-boundary rendering).

I am very hesitant to add an API like the one described in this issue as it (on the API level) requires predicting the future. After all, semantically, the next play position does not actually need to be known until after the current tick has been rendered completely. It may be possible to implement that unambiguously for the currently known and supported formats, but if some other format or tracker quirk shows up that makes the next play position depending on anything mixer-related (sample loops or whatever), this API would not be supportable without adding another buffering or prediction layer inside libopenmpt.

I do not think it makes much sense to try to handle any of the use cases described here while not thinking about tick-boundary rendering at the same time.

Issue History

Date Modified Username Field Change
2017-08-26 21:27 Saga Musix New Issue
2017-08-27 06:38 manx Note Added: 0003194
2017-08-27 09:27 manx Target Version => libopenmpt 0.5 (goals)
2017-08-27 14:34 Saga Musix Note Added: 0003195
2017-08-27 18:07 Saga Musix Note Added: 0003196
2017-08-27 18:27 manx Note Added: 0003197