libopenmpt features

Started by sunshine, May 27, 2020, 18:35:09

Previous topic - Next topic

sunshine

Hello,
The following features in libopenmpt would be very nice. Could these features be implemented?

  • Amiga resampling would be very nice as like in Open MPT.
  • When I play a very long sample with only one note in a mod file, then I seek the song, OpenMPT plays that sample from the scrubbed position correctly, but libopenmpt plays nothing.
  • When a song is played, total passed time is provided by the library, but current time position is not provided. If I obtain estimated time by song position, it may not be correct always. A solution for this would be very nice.

manx

Quote from: sunshine on May 27, 2020, 18:35:09

  • Amiga resampling would be very nice as like in Open MPT.
Set ctl render.resampler.emulate_amiga to 1. See https://lib.openmpt.org/doc/classopenmpt_1_1module.html#aef49052263ab2e28428b31feba2e88eb and https://lib.openmpt.org/doc/classopenmpt_1_1module.html#ac7e5f7acefe6fb12e73d78883f4c452e.

Quote from: sunshine on May 27, 2020, 18:35:09

  • When I play a very long sample with only one note in a mod file, then I seek the song, OpenMPT plays that sample from the scrubbed position correctly, but libopenmpt plays nothing.

Set ctl seek.sync_samples to 1. See https://lib.openmpt.org/doc/classopenmpt_1_1module.html#aef49052263ab2e28428b31feba2e88eb and https://lib.openmpt.org/doc/classopenmpt_1_1module.html#ac7e5f7acefe6fb12e73d78883f4c452e.

Quote from: sunshine on May 27, 2020, 18:35:09

  • When a song is played, total passed time is provided by the library, but current time position is not provided. If I obtain estimated time by song position, it may not be correct always. A solution for this would be very nice.
Can you elaborate what exactly is missing here?!


Saga Musix

From my understanding of question 3, module::get_position_seconds() returns exactly what you want. This is always accurate, not an estimate.

Regarding question 1, keep in mind that in addition to the ctl manx mentioned there is also render.resampler.emulate_amiga_type to set the Amiga model (in libopenmpt 0.5, libopenmpt 0.4 does not support this).
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

sunshine

#3
Thanks for the information manx and Saga Musix. I can now support Amiga resampling on ModPlug Player, and I can add "sync samples" option to the preferences.

For question 3, I obtain time using get_position_seconds(), but when I loop a song, the time always increases. Can we find a solution to this? I want to add an option to ModPlug Player to get song seconds instead of total passed seconds.

I hold each row's time information of the module in an object, and when the song is played, I update rows' seconds for the first time. When time scrubber is scrubbed on the player, I get time information using get_position_seconds. When time information is not -1 (initial value) on my object, I get time information from my matching row object. This is a workaround solution, but it would be very nice to obtain the song seconds from libopenmpt directly.

Saga Musix

No, there is no way to obtain the information that way, the play position is seconds is always increasing monotonically, and there is no plan to change that. What you could do is implement time display independently from the seek bar, and base the seek bar on order positions, so it will visibly jump back to another order once the song loops, but the time display itself keeps increasing. This is how XMPlay handles module playback.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

sunshine

I get time information using a timer independently from the scrubber, but in my solution I update my own row objects' time fields when song is played or scrubbed. My non-optimized method is below (since it is a temporary solution, I haven't optimized it).

I want to support both monotonically increasing time and song position time by providing a preferences window choice. Can libopenmpt support this by providing with an option? Even if it can be buggy at the beginning, it would be better to have it on libopenmpt, because it will be better in time.

TimeInfo ModulePlayer::getTimeInfo(){
    TimeInfo timeInfo;
    timeInfo.globalRowIndex = 0;
    if(mod != nullptr) {
        int order = mod->get_current_order();
        int row = mod->get_current_row();
        Row &r = rowsByOrders[order][row];
        if(r.time == -1) {
            r.time = mod->get_position_seconds();
        }
        timeInfo.seconds = r.time;
        timeInfo.globalRowIndex = r.rowGlobalIndex;
    }
    return timeInfo;
}

sunshine

#6
By the way, seek bar is based on order and row positions.

manx

Libopenmpt will very likely never support that kind of "song position" that you envision. The reason is pretty simple: It actually does not make a lot of sense. The position in the song when it is looping is actually the time passed since the start of playing, precisely because it is looping and not playing the row in question for the first time.

Your algorithm is not even well-defined for simple pattern loops. There is no 1:1 mapping even between order+row and time, even without module looping, because of pattern loops.

manx

Currently planned features in this area are probably https://bugs.openmpt.org/view.php?id=1146 and https://bugs.openmpt.org/view.php?id=1017, but both will tkae considerable amount of development time to implement, so do not expect them to happen very soon.

sunshine

I know, looping is very complex and it is impossible to see a 1:1 matching row/time information, but I just wanted to match each order's each row to a time seconds. When the song is played for the first time, these time informations are filled, and when the song loops, jumps to some places, time also jumps. I don't want to support this buggy feature as default, but I want to provide it with an option. When the features planned you mentioned are implemented, will there be such a feature?

sunshine

Since I get time info independently from playing, some rows' time info are not updated. I am planning to use the algorithm I pasted here by dividing it into two pieces, and filling part will be run by read method.

I couldn't understand completely the features you mentioned, but if it will be implemented in the future, I want to use it so much. If it will not be implemented, I may try to provide this feature as I mentioned. I may remove it if it is found too bad. I will not provide it as a default feature.

Thanks again for the information manx.

sunshine

By the way, when I tried to fill time info for rows, I noticed that it will not possible to fill all the rows' time info because each row may not match to each read call. If we find a solution or workaround for this, showing position time would be very nice even if it would be buggy. Anyway, I am removing this feature completely.

manx

Quote from: sunshine on May 27, 2020, 21:27:28
By the way, when I tried to fill time info for rows, I noticed that it will not possible to fill all the rows' time info because each row may not match to each read call.

This is what https://bugs.openmpt.org/view.php?id=1017 is all about.

sunshine

Thanks for the information manx.