activating hotcue loop sometimes jumps to cue instead of toggling loop #11003
Labels
Comments
|
(yes, the track is playing back in this case -- this happened to me during a live set and just now when I was practicing) |
|
looking at my database I have some interesting entries for the track that messed up: Note that there are two hotcues at the same position, cue index 3 and index -1, and the only difference is the color. not sure if that makes a difference here or not. oh duh, loop with index -1 is the regular saved loop |
|
I can't find any obvious code path that would cause a seek forward to a hotcue loop. It looks like it should only happen if the cue type is wrong for some reason. |
|
I can reproduce this but I have no idea what the hell is going on, which makes me suspect bad memory access. I put debugs/breaks wherever we seek, and no seek is called. The only thing I see in debug printing is that the call that makes the play position jump ahead, iBufferSize is double what it usually is, 470 instead of 235ish: when the read comes in for 470 instead of 235, we jump way ahead in the track (update: not bad memory access) |
|
ah, I was mistaken, ibuffersize doesn't change, it's the number of frames read |
|
As best I can tell, the scaler needs to read more than one entry from the readahead log, and the second item in the log is from inside the new loop. So perhaps during the creation of the new loop, the log is hinted about the new position. The scaler for some reason wants extra samples, but the log doesn't have them and so we jump ahead in the log, causing a seek (update: no, it's not a readahead bug) |
|
this feels like a race condition problem where the gui action of the loop enabling conflicts with the engine callback thread that's using the loop |
|
I think what's going on is the reader is getting hinted for the new loop values while it's also processing the current samples, so then when the engine buffer scales its samples, it picks up the hint for the new loop position |
|
I think the right fix would be to have loop activation be cued like seeks are |
|
Here's a race point: if we are processing samples and the loop data changes in the middle of it, it pollutes the readahead call https://github.com/mixxxdj/mixxx/blob/main/src/engine/readaheadmanager.cpp#L52 (update: nope, not the problem) |
|
hmmm now I'm not sure it's a race, but that the loopinfo gets messed up along the way? At creation time the loop seek mode is None, but by the time it's processed it's Changed (update: I think this one is right??!) |
|
|
so my new wonderful theory is that the change of the beatloop spinbox value triggers the creation of a "new" enabled loop. I am all over the place on this lol |
ywwg
added a commit
to ywwg/mixxx
that referenced
this issue
Oct 25, 2022
This works around mixxxdj#11003 in which the adjustment of the spinbox creates a new loop, causing a sudden unexpected seek
ywwg
added a commit
to ywwg/mixxx
that referenced
this issue
Oct 25, 2022
This works around mixxxdj#11003 in which the adjustment of the spinbox creates a new loop, causing a sudden unexpected seek
|
if someone can remind me of the correct way to make a change to a CO without causing it to emit a valuechanged signal, that would help. We'd like to be able to change the spinbox value without having it be interpretted as a request to make a new loop |
|
I also see these assertion failures: |
|
I think this happens for the same reason, a "new" loop is created that's a little different from the saved one |
|
I cannot reproduce the issue with the latest main on Ubuntu Focal. Is It skin related or do you trigger the bug with a controller? |
|
I think this is closed by #11006 please reopen or file a new bug if there is a remaining issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Description
Sometimes I'll press a hotcue button corresponding to a hotcue loop (before the playhead gets there) and instead of toggling the loop activation, the playhead will jump to the hotcue. I can't reproduce this consistently.
Version
head
OS
Ubuntu 22.04
NOTE: I have about 10 wrong theories about this bug, and even now I'm not sure I have the right root cause. So please don't read too hard.
The text was updated successfully, but these errors were encountered: