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

Mixxx ocasionally forgets length of saved loop, making them not be editable #14359

Open
SamWhited opened this issue Feb 17, 2025 · 25 comments
Open
Labels

Comments

@SamWhited
Copy link

SamWhited commented Feb 17, 2025

Bug Description

Frequently if I have a loop saved to a cue, for example the 64 beat loop in the screenshot below, Mixxx will forget the loop length. Sometimes I make the loop, save it to a cue, and then while editing the loop color or label I will see it change to "1/32", other times I'll just load Mixxx up and all of the loops in a song will say "1/32" and not remember their original length (though I suppose it's possible they were doing this while I was editing and I didn't notice and it's not delayed). In the waveform overview the length is still correct, and it still loops at the correct place, it just can't detect the length. I have seen no obvious pattern for when this does or does not happen, it's a regular but sporadic problem, but I believe that I have only seen it on tracks with a variable BPM (though I'm not 100% sure about this).

The number being wrong isn't really a huge problem, more just an annoyance, but when this happens the loop is also no longer editable, so eg. if I want to nudge a loop to the right a few beats or change the loop length live during a dance it's no longer possible. I have to go back and delete all the loops and re-set them up to make sure they show the correct length and can be edited during the dance.

A screenshot of a deck in Mixxx with a song loaded. There are lots of saved loops, and the first one is selected. The loop button is highlighted, but the loop length says 1/32 though in the waveform overview you can see that it is much longer than this.

Version

2.5, 2.6 (fef7062)

OS

Arch, Linux 6.13.2-arch1-1

EDIT: I should also say that all of these loops were created by setting the loop length field to 64 and hitting the loop button, not using the "start/end" buttons.

EDIT 2: It appears that I can force this to happen by moving the beat grid, then the loops all forget their length. However, I haven't been doing that every time it happens so it's not necessarily the root cause.

EDIT 3: I should also say that all my tracks are OGG/Opus files. Unsure if that matters.

@SamWhited SamWhited added the bug label Feb 17, 2025
@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

In the waveform overview the length is still correct

So the loopsize has been recalled correctly.

You need to activate a loopcue to make the loopsize spinbpox reflect its length.
You can activate two ways:

  • track is playing: click loopcue
  • not playing: click loopcue, click Reloop

Then you can move or adjust the saved loop.

Else (not playing, Reloop not pressed) Mixxx will only adjust/move the temporary loop it created from the saved loop.

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

The loop cue is activated, when I do so it says "1/32" in the length box and the loop cannot be moved as described in the original post.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

Could you please make a short screencast?
Load a track, demonstrate the buggy behaviour.

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

What would you like included that the screenshot doesn't show? I'm not sure how to make a screencast off the top of my head in an easy way and it seems like a bit of a timesink/extreme for some debugging, especially if I have to make several because I'm missing something. Apologies if it's obvious what you need, but I promise I know how the loop feature works and that the loop cue is actually selected and it's not just the temporary loop over the top of it, which I'm well aware of.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

In my experience, checking screencast reveals much faster what exactly one does and where expectations might be wrong / where/when the bug occurs, compared to trying to describe it with all the back and forth verifying which steps were done when etc. etc.
(which is a timesink for me)

I use peek to make quick videos (gifs) of a screen region, but there are other minimal recorders, e.g. vokoscreen/vokoscreeNG.

@SamWhited
Copy link
Author

Do you have somewhere I could upload a recording? GitHub says that video file types are not allowed if I try to drag it onto the issue. It's 12.5 MB, and I couldn't get the cursor to be visible or find an option for it, but hopefully it's obvious where I'm clicking.

@SamWhited
Copy link
Author

Actually, I use Disroot sometimes and I just found out they have a file transfer thing, I had no idea!

Here's the file, it has a 30 day expiration:

https://upload.disroot.org/r/gwBb6pZg#Yodhl/oBJWlQ/6OlqN1T+9w/qU0ehfW/wAK0aRON7P8=

When the loops are being highlighted I'm just clicking the "1" or "2" button. When the beat grid adjusts I was clicking the "line up with cursor" button on the right hand side, and when it adjusts again back to how it was before I was clicking "Adjust variable BPM" in the context menu.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

12.5 MB are a lot...
With peek and GIF I can usually record hal a minute and it's still less than 1 MB

Record only the deck region, record as GIF?
If it's still to large, try to reduce the frame rate.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

..will check the video

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

Here's another one with peek. All the same things happening except you can see the mouse and it's smaller (you can't see it when it goes off-screen to hit the beat grid adjust button, and the menu for re-analyzing got clipped, but hopefully it's clearer and it won't have an expiration date in case this is needed later):

Peek.2025-02-17.09-38.webm

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

Cool, thanks!
Very strange. I tried to reproduce with two saved loops, even with overlap, and it worked as expected. No reset to 1/32 or whatever.

Did you have a controller script running while recording?
If yes, does it handle loops except activate? Maybe some callback for hotcue status or something?
Did you already run from the command line with --developer arg and check if anything related was printed?

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

FWIW I tested with a mp3.

@SamWhited
Copy link
Author

No controllers were activated when I recorded this video. For debugging purposes, the file I was using is here (probably fair use? I dunno, I knew this band, they won't care):

https://upload.disroot.org/r/Mab9EsXx#ixSh4sZrhYAHrW4iCXFp49/DG8I0H5zugWie2I1PkNs=

I tried a few times to get log messages, but there was so much warning noise I could never figure out what was happening. I'll try again and see if I can pause scroll right before I do it or something.

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

I see:

debug [AnalyzerThread 0 #1] Beat calculation skips analyzing because the track has a BPM computed by a previous Mixxx version and user preferences indicate we should not change it.

right after I load the file, which is odd because this is the first version of Mixxx I've ever used (this is 2.5, I did try on 2.6 and copy/pasted the .mixxx directory back and forth so nothing should have changed, but maybe 2.6 stored something in the file that caused this warning? I suppose it doesn't matter because this was happening on 2.5 before I tried 2.6, so maybe it's not related)

Otherwise nothing stands out to me (there's a lot of junk about a serato beat marker, but it all appears right after a file I didn't even touch, maybe it was just focused in the UI or something when I went to load the file in question, no idea):

log.txt

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

I just tried with that track and it works as expected:

  • activate while playing: can move & resize ✔
  • while stopped: activate, click Reloop (not "Loop activate"!)
    loopsize adopted correctly, can move & resize ✔

Not sure what's going on.

If, while stopped, you click and hold a hotcue button it should activate the loop and keep playing until you release.
At which point does it reset the loopsize display to 1/32?

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

None of the things you describe cause the problem for me either. The only way I've found to reliably recreate it is to move the beat grid, were you able to try that? (it does happen at other times too I believe, but not consistently)

Holding the hot cue never causes the loopsize display to change, things work as expected and the loop plays through and restarts at the end, then the play position resets when I let go. If I adjust the beat grid and then try to hold the hot cue button, the display changes to 1/32 as soon as I hit the button (but the loop does continue to work as expected and the play position resets as expected when I release).

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

move the beat grid

Oh I overlooked that. Will try again.

@SamWhited
Copy link
Author

SamWhited commented Feb 17, 2025

Just had it happen again without moving the beat grid, and on a FLAC file this time. I can tentatively reproduce it. In this case the track is also variable BPM. I set the loop size to 64 and press the loop button to create the loop. Then I press an empty cue to save it. Then I change the loop size to "61" and hit enter. The cued loop adjusts, as expected, and everything appears fine. however if I then click another loop or something to deselect the one I was just making, and then click on the one I was working on again to select it, the loop size changes to 1/32 and the symptoms are happening.

EDIT: tried it again on a different track, same result. This one was not variable BPM. Went back to the original track and every loop I had setup was 1/32 and wasn't working, whereas before I thought it was only the one I was actively working on that had broken.

Nothing interesting standing out in the logs.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

Uff.. thanks for the info!
So it's related to beat markers I guess?
Do you always analyse with variable BPM?

The call hierarchy is
CueControl::hotcueActivate
-> CueControl::setCurrentSavedLoopControlAndActivate
-> EngineControl::setLoop
-> EngineBuffer->setLoop
-> LoopingControl::setLoop
----> m_pCOBeatLoopSize->setAndConfirm(findBeatloopSizeForLoop(startPosition, endPosition));
startPosition, endPosition are still okay as the overview shows, so it looks like the bug is in the Beats map:
1/32 is the first beatsize that is tested in LoopingControl::findBeatloopSizeForLoop

Hope this is a starting point for anyone more familiar with the beats.

@SamWhited
Copy link
Author

Do you always analyse with variable BPM?

Not always, but most of these songs have slow bits in the middle or something so it's helpful. See my edit above though (which I just realized you'd probably never see if you use GitHub's emails only, oops, I'll just post again in future), I tried it again with a regular song with no BPM and it still happens.

@ronso0
Copy link
Member

ronso0 commented Feb 17, 2025

regular song with no BPM and it still happens

with literally no BPM it would use seconds instead of beats btw.

@SamWhited
Copy link
Author

Sorry, that is to say with a non-variable BPM, not "no" BPM, I don't even know what that would mean.

@ronso0
Copy link
Member

ronso0 commented Feb 18, 2025

I don't even know what that would mean

Load a track, it's being analysed. Set a loop. Open track menu -> Clear -> BPM
Et voilà, I get 1/32 for a previously 4-beat loop.
Reanalyzed it and it was back to 4 beats.

So it's definitely related to beats.

@SamWhited
Copy link
Author

I'm not sure if it's the exact same issue, but I just noticed that the options to eg. halve the BPM in the context menu also don't work sometimes (unclear if it's only when this is happening, it was a problem on the track I was trying to fix). If I re-analyze the track, they seem to work again and I can get the incorrect BPM fixed.

@SamWhited
Copy link
Author

Quick update that may or may not help someone track this down: on another track where the BPM is actually pretty consistent, but it misdetects where the beat is unless I use the variable BPM option if I set a loop for 64 beats everything is fine, but if I set it to 96 beats (the actual length of a phrase in this song), the moment I hit the "cue" button to assign the loop to it it switches from 96 to 3/2. So I don't actually have to adjust the beatgrid to make this happen, it depends on the selected loop length too.

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

2 participants