Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rxy + ghost note inaccuracies #22

Open
Artefact2 opened this issue Apr 19, 2021 · 5 comments
Open

Rxy + ghost note inaccuracies #22

Artefact2 opened this issue Apr 19, 2021 · 5 comments
Labels

Comments

@Artefact2
Copy link
Owner

Just to log it, there's another bug in Rxy which I'm not planning to fix for now. If a row contains no note but an instrument with the Rxy effect, what happens is that on tick 0, the ghost note of the previous instrument plays (as per standard behavior with rows that contain instruments without notes), but on the first retrigger the instrument is changed to the new one. So actually the instrument changes mid-row.

This looks harder to implement because the logic to change instruments is not part of xm_trigger_note, but I haven't investigated into it. If you want, I can open an issue to log this.

Originally posted by @rasky in #20 (comment)

@Artefact2 Artefact2 added the bug label Apr 19, 2021
@bryc
Copy link

bryc commented Apr 19, 2021

Here is the test case which I think highlights what @rasky is talking about: RxxTest.zip.

Here's some audio comparisons. This is a diff of FT2Clone (Dark) and LibXM (Light):

image

Here's the full comparison image, which highlights that MilkyTracker and OpenMPT fail this as well:

image

The test case is is actually just parts taken from look & zalza - little computer boy.

rasky added a commit to rasky/libxm that referenced this issue Apr 20, 2021
Nobody was resetting autovibrato_note_offset after instrument change.
The fact that xm_autovibrato doesn't update it each tick is not
sufficient: all future xm_update_frequency() in this channel will still
take into account the current autovibrato offset.

Instead of trying to reset autovibrato_note_offset when the instrument
does change (considering that we might even have to rework instrument
changing logic -- see Artefact2#22), I made xm_autovibrato reset it when it is
not needed anymore. This keeps the logic updating
autovibrato_note_offset all in the same function.

Co-developed with @bryc who also prepared the testcase.
@Artefact2
Copy link
Owner Author

Hi @jmorel33, the licensing is not clear on your modified file so I can't merge any changes back in libxm (which is WTFPLv2) as is.

Stereo samples are not standard (and in my experience not a widely used feature) so I think it's out of scope for libxm (unless you have good examples of XMs with stereo samples).

If you could submit playback fixes as patches or pull requests (ideally with a test case), that would be much better licensing-wise. Thanks!

@bryc
Copy link

bryc commented Sep 19, 2021

Yep concerning Stereo, XM tracker artists back in the 90s were really allergic to stereo samples probably to save space. So a lot of people fanned out of the XM community to do IT mod files instead for all the other features.

FT2 and IT never officially supported stereo samples at all, so I'd hold back on writing that memoir. It was the Modplug Tracker (now OpenMPT) that added stereo support to XM, IT.

@jmorel33
Copy link

jmorel33 commented Sep 19, 2021

cheers. And good luck.

@sbechet
Copy link

sbechet commented Apr 6, 2024

Maybe this can help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants