Shortening loop can cause deck to go out of sync.

[enry]

build r3818 Ubuntu 12.04

Please consider the next steps:

- 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;

Result: new Loop starts at the same position the original Loop began; this makes the sound jump to original start position, and creates problems during mixes, especially if new length button is not exactly pressed on a beat occurrence, because decks will go out of sync. Please note that behavior is correct if the new shorter Loop is enabled before k th beats have been played, because in this case the new Loop end position has not been reached and no jumps occur.

In cases where the problem occurs, new Loop could start on the first beat after the position corresponding to the button event enabling the new Loop, if quantisation is enabled, or on the position corresponding to button event otherwise.

The important thing, in my opinion, is to avoid anyway position jumps.

[rob (another-rob)]

I can confirm this behaviour. But the way I work with loops, I'd rather have new loops stick to starting on the currently active loop_in point than at the current button position (just my opinion), and I can see some issues with the approach you're suggesting.

For example, I use a knob on some of my controller mappings to activate a dynamic length loop - turning the knob cycles through the various beatloop lengths, growing or shrinking the loop. I want position jumps when I'm doing this, and I need the loop_in point to stick as I'm cycling through lengths.

But I agree that as a general principle it's a good idea to give users an ability to avoid position jumps... Maybe the "avoid position jumps when quantize is active" approach you suggest might work. But I think that scripts should be able to override that, to deal with situations like my beatloop knob script, where position jumps are desirable.

Another option might be to stick the new loop to the currently active loop_out position if starting at the loop_in point would cause a jump. But would might cause unexpected behaviour where the user was not paying attention to the playposition within the loop, and this wouldn't work for my beatloop knob scripts either, since the behaviour would be unpredictable.

I wonder if it makes sense to add a parameter to beatloop_x_activate that would give controller scripts three options - either respect the currently active loop_in position, respect the currently active loop_out position, or start the new loop at the current play position. Or maybe different controls for each of these options might be the easier way to go until the scripting engine is overhauled. I've thought for a while that being able to specify sticking to the loop_out point rather than loop_in might allow for some interesting effects.

Here's a vaguely related looping bug report that whoever winds up working on this might want to take a look at at the same time:
https://bugs.launchpad.net/mixxx/+bug/1159243

[RJ Skerry-Ryan (rryan)]

Agree this is a problem and it's an open question as to what the best behavior is. As Rob mentions in the end it will need to be configurable by scripts because the beatloop-knob use case intends for jumps to happen.

[RJ Skerry-Ryan (rryan)]

Note, I don't think this is solved in Mixxx 1.12.0 because looping timeline projection is done in ReadAheadManager and not with the EngineBuffer seek code so quantize is not used to align the jump.

[RJ Skerry-Ryan (rryan)]

Alternate solution: queue up the loop change until the player position is out of "desync" territory.

This would work for short lengths (i.e. if it's a 1/4 loop and you hit loop-halve, wait 1/8th of a beat until it is back in the first half of the loop then shorten the loop) but this would be very weird in e.g. a 32-beat loop waiting 16 beats for the position to get out of the 2nd half of the loop.

So I'm not in favor of that solution.

[RJ Skerry-Ryan (rryan)]

I think quantize mode -> make the jump sync aligned fits best with the user's mental model since quantize already controls all other instances of this.

[Owen Williams (ywwg)]

The deck should seek in a mod-like fashion: If I'm on beat 29 of a 32 beat loop and I loop-halve, the playback should jump to beat 13 of the new 16 beat loop (29 - 16 = 13). ie, imagine that the 32 beat loop was actually two copies of the 16 beat loop. That will maintain musical correctness as best as possible and works for any length.

[RJ Skerry-Ryan (rryan)]

Yea, that's what I'm thinking for quantize on. Did you mean it should do that even without quantize?

[Owen Williams (ywwg)]

Correct. I don't think quantize should make a difference when it comes to loop halving.

[RJ Skerry-Ryan (rryan)]

There may not be a beatgrid in the loop halving case.

[RJ Skerry-Ryan (rryan)]

but I see what you're saying. hmm.

[RJ Skerry-Ryan (rryan)]

Rob's point is that this would potentially make a beatgrid length selector knob act weird if it were the default behavior.

[Owen Williams (ywwg)]

Loop in point should definitely be constant. Lack of beatgrid doesn't matter, a sample count would still work just fine.

We could also have loop_halve_end if someone wants to keep the out point the same, which I could see being useful for timing THE DROP.

There will be jumps, but if the jumps are musically correct they don't sound too bad.

[Owen Williams (ywwg)]

Fixed in https://github.com/mixxxdj/mixxx/pull/202

[Raf Van De Meirssche (rafvdm)]

I read Fix Commited on March 24, 2014.

But I still encounter this issue in build 1.12 r5481.
Both on Ubuntu and Windows 7.

Does this need reopening?

[jus (jus)]

The fix was committed to master branch, not 1.12 branch.
You wont see it until you test the master builds from http://downloads.mixxx.org/builds/master/

[jus (jus)]

Boof, sorry.
I was wrong, we did not even cut a 1.12 branch from master in March 2014.

[Raf Van De Meirssche (rafvdm)]

I feel totally lost .... Don't understand the least bit of it.
:-(

[Raf Van De Meirssche (rafvdm)]

The concept of a "branch" was explained to me today,
but still I feel confused.

Whether this is committed to master branch or not,
shouldn't it be fixed in the 1.12 branch anyhow?

[Daniel Schürmann (daschuer)]

According to this bug, the original issue should be fixed in 1.12 beta.

Since you still experience an related issue. I think it is best to file a new bug, including a step by step instruction what happens and what should happen instead.
Pleas add also the git revision of the build you use for testing and a written reference to this bug

And yes, that is what a 1.12 beta version is for: finding and hopefully fixing bugs prior final release.
So we should try to fix it in the 1.12 branch.

Thank you!

[Raf Van De Meirssche (rafvdm)]

Continued in https://bugs.launchpad.net/mixxx/+bug/1501822

[Swiftb0y (swiftb0y)]

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