Shortening loop can cause deck to go out of sync (Reprise)

Bug #1501822 reported by Raf Van De Meirssche
2
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Low
Owen Williams

Bug Description

mixxx-1.12.0-beta1-1.12-git5554-release-x64.exe
Acer Aspire 7750
CPU: Intel(R) Core(TM) i5-2410M 2.30GHz
Memory: 4GB RAM
OS: Windows 7 64bit

This follows https://bugs.launchpad.net/mixxx/+bug/1171102 (Shortening loop can cause deck to go out of sync).
The old was reported as fixed, however in release 5554 this still does not function correctly.

Daniel has asked me to file this as a new bug.

What is happening?

As mentioned in the original bug:
"- Enable n beats Loop on a playing deck;
- After k beats have been played, enable a new k beat Loop length, where k < n, for example 8 beats -> 4 beats;"

More clearly:
Imagine a 16 beat loop playing.
Let's say you shorten the loop to 4 beats.

Now 2 things can happen:
1. You shorten the loop in the first 4 beats... All goes well, you're already in the new loop, your new loop continues smoothly.
2. You shorten the loop in the last 12 beats... Because the new loop will be set to the first 4 beats, you actually are now outside the new loop. Instead of continuing playback to some point where the new loop can be taken up smoothly, music instantly jumps to the beginning of the new loop and therefor goes out of beat. Unless of course if you are lucky to do this exactly on beat 8.

So ... in short ...
If you have an n-beat loop and you shorten it to x-beats ...
If you do it while you are already positioned in the new x-beat loop, the new loop smoothly takes over.
If you are passed the new x-beat loop, you instantly jump out of beat to the beginning of the new loop.

If still not clear, please let me know.

Now ... There may be a big discussion whether the smaller loop has to start in the beginning of the old loop, its end, simply where you hit the button or by using some lovely but complex algorythm.
I don't really care where it goes, but I do care if it does not remain on the beat.

Revision history for this message
Owen Williams (ywwg) wrote :

In mixxx, pressing a new loop size creates a new loop at the current position, it doesn't alter an existing loop. If you use the +/- buttons, you'll get the behavior you want.

But it does seem reasonable that if looping is on, and a loop size is selected, the existing loop in point should be kept and a new out point should be created. Since we already have good warping code, this should be easy to fix.

Changed in mixxx:
assignee: nobody → Owen Williams (ywwg)
milestone: none → 1.12.0
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Owen Williams (ywwg) wrote :

ah, the in point is being kept but the playposition isn't seeking correctly.

Revision history for this message
Owen Williams (ywwg) wrote :
Changed in mixxx:
status: Confirmed → Fix Committed
Revision history for this message
Raf Van De Meirssche (rafvdm) wrote :

mixxx-1.12.0-beta1-1.12-git5557-release-x64.exe

There is much, much, much improvement.
But I somehow have the impression it still fails when you drop down extremingly, i.e. from 8 beats to 1.

I'll consider this fixed "until proven otherwise". :-)

Thank you!

RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8241

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.