Mixxx

Waveform scratch past either end of an enabled loop causes the player to speed out of control

Bug #779179 reported by RJ Skerry-Ryan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
High
RJ Skerry-Ryan
Mixxx 1.10.0

Bug Description

If you set a loop and then use the waveform to scratch past either end of it, the player will go crazy trying to reach the position beyond the loop but since the loop always pushes it back to the opposite end, it can never reach it.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: none → 1.10.0
status: New → Confirmed
importance: Undecided → Medium
shanxS (shanx-shashank)
Changed in mixxx:
assignee: nobody → shanxS (shanx-shashank)
Revision history for this message
shanxS (shanx-shashank) wrote :

This patch is against trunk and should resolve the issue.
shanx

RJ Skerry-Ryan (rryan)
Changed in mixxx:
importance: Medium → High
Revision history for this message
shanxS (shanx-shashank) wrote :

Is something wrong with the patch I provided ?
Does it look more like a poor hack rather than carefully thought solution ?
How can I improve it ?

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hey shanxS,

The problem with your patch is that it does not let you scratch past the end of the loop -- it just stops the loop at the extents. Another issue is that it will only work for looping and not for other things that change the playposition (e.g. if you trigger a hotcue the player will also go ballistic).

I thought a lot about the right way to fix it and realized part of how the scratching works was wrong. The widget should not track positions -- it should instead give distances that should be traveled by the player. This way, it doesn't matter if a loop is taken because the total distance traveled by the player is the control variable.

The result is that scratching without a loop enabled works just as good as before (with no noticable drift). Scratching with a loop works as expected, but if you scratch it a lot sometimes there is a little bit of drift. I commited the fix to trunk.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
assignee: shanxS (shanx-shashank) → RJ Ryan (rryan)
status: Confirmed → Fix Committed
Revision history for this message
jus (jus) wrote :

Hmm, this bug s suddenly there again.
Tested with lp:mixxx r2923 on MacOSX 10.6.8 and Ubuntu Linux 11

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Whoops. It's like playing whack-a-mole. This was a bad interaction with my fix for Bug #790871

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

Fixed again.

Changed in mixxx:
status: In Progress → Fix Committed
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/5886

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.
Subscribing...

Other bug subscribers

Remote bug watches

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