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

AudioFileProcessor: Wrong loopback point when reversing sample #6708

Closed
messmerd opened this issue May 15, 2023 · 1 comment · Fixed by #6958
Closed

AudioFileProcessor: Wrong loopback point when reversing sample #6708

messmerd opened this issue May 15, 2023 · 1 comment · Fixed by #6958
Labels

Comments

@messmerd
Copy link
Member

Bug Summary

The loopback point in the AudioFileProcessor (AFP) instrument can be set to the wrong value when reversing a sample.

Steps to reproduce

  • Create a new project
  • Add an AFP instrument to the Song-Editor
  • Open any audio file in the AFP instrument
  • Set the AFP start point to 0.3 (this also sets the loopback point to 0.3)
  • Set the AFP loopback point to 0.2 (this also sets the start point to 0.2)
  • Notice that both the start point and loopback point should be 0.2 now
  • Click the reverse sample button
  • Click the reverse sample button again

Expected behavior

After clicking the reverse sample button twice, both the start point and loopback point should be back to 0.2 like they were originally.

Actual behavior

The start point is 0.2, but the loopback point is 0.4.

Additionally, if the loopback point is then set to any value between 0.2 and 0.4, clicking the reverse sample button twice will set it back to 0.4 regardless of what value it was previously.

Affected LMMS versions

master, 1.3.0-alpha, 1.2.2, ...

@messmerd messmerd added the bug label May 15, 2023
@michaelgregorius
Copy link
Contributor

This seems to be caused by some "chaotic" updates via signals when the points (start, loop, end) change. This can be observed by setting a break point in AudioFileProcessor::pointChanged which is triggered by different updates of the points.

If I understand correctly the new points would need to be computed as follows:

newStart = 1. - end;
loop = 1. - loop;
newEnd = 1. - start

One solution might be to turn off signals during the update, perform the calculation, update the values and then emit one signal at the end.

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

Successfully merging a pull request may close this issue.

2 participants