design flaw in "hot cue loops" saved triggers?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mixxx |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Git version: 2.4-alpha-
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.
description: | updated |
description: | updated |
description: | updated |
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 |
summary: |
- Mixxx 2.4.0 Alpha-pre: design flaw in "hot cue loops" saved triggers(?) + design flaw in "hot cue loops" saved triggers? |
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#issuecomme nt-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 /github. com/mixxxdj/ mixxx/pull/ 2194
https:/