View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001017||OpenMPT||[All Projects] libopenmpt||public||2017-08-26 21:27||2018-08-18 12:49|
|Reporter||Saga Musix||Assigned To|
|Target Version||OpenMPT 1.29 / libopenmpt 0.5 (goals)||Fixed in Version|
|Summary||0001017: Tick boundary rendering (was: |
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.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
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.
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.
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).
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.
Related: It might make sense to provide two more functions,
To summarize the additional design suggestions so far:
We also should investigate whether splitting
One challenge here is going to be that, from what I understand, information like
This is precisely the reason why I think we need the explicit
|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||=> OpenMPT 1.29 / 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|
|2018-02-13 15:39||manx||Additional Information Updated||View Revisions|
|2018-02-14 19:48||Saga Musix||Note Added: 0003421|
|2018-02-14 20:04||manx||Note Added: 0003422|
|2018-02-14 20:08||manx||Note Added: 0003423|
|2018-02-14 20:08||manx||Target Version||OpenMPT 1.29 / libopenmpt 0.5 (goals) => libopenmpt 0.4 (goals)|
|2018-02-14 20:13||Saga Musix||Note Added: 0003424|
|2018-02-14 20:23||manx||Note Added: 0003425|
libopenmpt: Provide access to next play position => Tick boundary rendering (was:
|2018-08-18 12:49||Saga Musix||Target Version||libopenmpt 0.4 (goals) => OpenMPT 1.29 / libopenmpt 0.5 (goals)|