design flaw in "hot cue loops" saved triggers?

Bug #1966160 reported by nPrevail
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Medium
Unassigned

Bug Description

Git version: 2.4-alpha-1131-g02150fa2b6 (HEAD)
OS: Linux 5.16.16-200

Perhaps this is a design issue, or perhaps this was an intentional feature. Perhaps someone can explain how "hotcue + loops" are supposed to work for Mixxx.

After making a "hotcue loops" (looping a track and saving the loop in a hotcue slot), pressing the hotcue loop point will only do one of two things:

1. If a hotcue loop is in the middle of the song, enabling the loop will only loop when the "Play Marker Position" meets the hotcue loop.
2. If the Play Marker Position has passed the hotcue loop, triggering it will "hotcue" back to the previous cue point of the track + "enable loop."

I don't know if this was a design choice . I think it'd be best if the hotcue point acted as a "hotcue" + "loop" at any instance when a hotcue loop is triggered. Just like regular hotcue points, when you push them, the hotcue will instantly bring you to wherever the hotcue is saved, regardless of where you are in the track that's playing. (Traktor and Serato have great examples of "hotcue + loop" being trigger-able wherever your Play Marker Position is on a track).

If a song has four hotcue loops saved (like if hotcues 1,2,3 & 4 are filled with loops), and the Play Marker Position has gone past "1 & 2", you can only trigger a "hotcue + loop" to "1 & 2" hotcue points. You won't be able to trigger to hotcue + loop "3 & 4" because it's ahead of the Play Marker Position, and you can only enable the loop for when the Marker gets there.

If this is confusing, let me know, and I'll make a video on it.

nPrevail (nprevail)
description: updated
nPrevail (nprevail)
description: updated
description: updated
nPrevail (nprevail)
summary: - Mixxx 2.4.0 Alpha-pre: Inconsitent "hot cue loops" saved triggers
+ Mixxx 2.4.0 Alpha-pre: design flaw in "hot cue loops" saved triggers(?)
description: updated
ronso0 (ronso0)
summary: - Mixxx 2.4.0 Alpha-pre: design flaw in "hot cue loops" saved triggers(?)
+ design flaw in "hot cue loops" saved triggers?
Revision history for this message
ronso0 (ronso0) wrote :

I agree that this is unexpected. IIRC it was implemented to match the behaviour of Serato controllers?

An alternative was proposed in the original PR (for example https://github.com/mixxxdj/mixxx/pull/2194#issuecomment-520975024):
1 press hotcue inside loop: save loop
2 press (loop) hotcue: jump to loop and enable it
3 press Shift + hotcue: enable loop, don't jump
4 press Shift, longpress hotcue: remove loop cue

4 is possible because 3 is not time-sensitive, thus 3 and 4 are triggered on hotcue release.

I think it makes sense to continue the discussion in the original PR
https://github.com/mixxxdj/mixxx/pull/2194

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 2.4.0
Revision history for this message
ronso0 (ronso0) wrote :

I just openened https://github.com/mixxxdj/mixxx/pull/4816 where we can discuss the feature

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/10688

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.