Discussion: enhancing loop and cue interactions

[betalars]

[Edit:] as the discussion moved forward from the original proposal, I updated the title to reflect that.

Feature Description

Jump to a loop hotcue by double tapping it.

This would make using Video Game music composed of multiple longer loops a lot easier in Pen as Paper Background music. When the fight progresses to a stage better fit for a later loop, I could just jump to later in the track and still enter a pre-defined loop.

Workaround

Just add a normal hotcue and a looped hotcue. However this is a bit more finicky and it takes up hotcue slots.

[betalars]

One tweak I would make: have it so the double tap still removes the loop mode so it is consistent.

hot loop before the current position:

1. tap jump
2. tap disable loop
3. tap re-enable loop

Hot loop after current position

1. tap: enable loop, no jump
2. tap: jump and disable loop
3. tap: re-enable loop

[betalars]

One thing I would test is: what time point to take for the jump.

I would argue it probably feels the most intuitive to skip forward by the delay between first and second tap so it still feels as if you jumped on the first tap.

[ywwg]

this seems dangerous, because it might be easy to accidentally hit the button twice, and the timing issues you mention. As much as I hate adding preferences, I wonder if we need one to choose whether the playhead should jump to loops when pressed or just enable the loop.

OR, use shift+press to do one or the other, and remove the ability to delete a saved loop with shift+press. (Deleting is a rare operation, maybe it's fine if it's only available in the GUI?)

[ronso0]

If I understand your proposal correctly I tried to address it with an add alternative Loop Cue activation mode in #4816 (but I got stuck at some point, might take another stab at it) This allows to select the primary mode and adds new control for the respective secondary mode.

1. Activate loop, jump to if loop is behind, or
2. Jump to and loop, toggle if inside loop range

I'm afraid the double-tap solution is a no-go due to the delay you mentioned. Either the button/control always waits for a second click (= delayed response for single click) or we get two actions (click -> action, 2nd click -> action2).

[betalars]

(Deleting is a rare operation, maybe it's fine if it's only available in the GUI?

cue+del?

[betalars]

I'm afraid the double-tap solution is a no-go due to the delay you mentioned. Either the button/control always waits for a second click (= delayed response for single click) or we get two actions (click -> action, 2nd click -> action2).

I would actually test that. I do not think it is as counter-intuitive in practice as you feel it is.

The only thing important to make it work is the skip.

So

1. Tap: loop is being enabled delay between taps
2. head jumps slightly behind loop start by the delay

The gui is never irresponsive. It just has this small delay hack to not feel like it is lagging. I think this works well enough for monkey brains to not notice.

Obviously there needs to be a max delay that no longer causes the jump.

[ronso0]

Deleting is a rare operation, maybe it's fine if it's only available in the GUI?

It's not : ) Are you proposing to replace hotcue_X_clear with a trigger the loop cue jump?

[betalars]

By the way ... I am not a huge fan of the alternative loop-enabling state, because it adds one more piece of state to keep in mind while mixing.

[ronso0]

head jumps slightly behind loop start by the delay

"slightly behind loop start" is another no-go during performance IMHO. I have carefully set hotcues on beat /just before the beat (admittedly only rarely use loopcues) to get the kick drum, or a raising synth chord or whatever the composer placed on beat, and such a slight delay would swallow that.

[ywwg]

maybe: press: activate shift+press: jump to shift+long press: delete

[betalars]

I have carefully set hotcues on beat /just before the beat

okay this is a total non issue for my use case but I see your point.

Maybe jumping on the second tap to the exact cue is the most friction less because then you kind of just have to enable the loop slightly off beat before the jump.

[ywwg]

if you have quantize on then it doesn't matter if the playhead is not exactly on the hotcue. we already adjust the play position to match the beat percentage of wherever you jumped from

[betalars]

... and we could even be smart about it so that it jumps slightly before the cue when you have quantize on and you start your double tap slightly before the cue.

[betalars]

Yeah and because I always have quantizise on it is a total non issue to jump on the second tap to the exact cue for @ronso0 while also not getting my second tap off beat when my first tap is on beat.

[ywwg]

that kind of magic is, as I say, very dangerous and hairy. There are many many edge cases to consider. Better to find a single-button or multiple-buttons-at-once solution.

[ronso0]

maybe: press: activate shift+press: jump to shift+long press: delete

Then shift+long press would jump, too, because we want shift+press to act on press, no on release.

Re double-tap: let's keep in mind that we also want to support finger druming. Assuming one wants to use loopcues for that (and not have hotcue and loopcue at the same position just for that purpose) I'm favoring the mode selector. To avoid confusion it could also be indicated somewhere in the hotcue region (so it's not forgotten, or has to be looked up in the prefs).

[betalars]

I feel like finger drumming and loop cues feel incompatible, but I am not the one to argue against very nice use cases.

But I will leave this in the back of my head and let it develop a bit.

My last thought for today: long press to jump?

[ronso0]

My last thought for today: long press to jump?

how long is a "long"? If I want to jump I want it immediately, not with some unknown delay. Maybe on long press release could work.

[ywwg]

that's why I'm proposing long press for delete, that's not an operation that requires perfect timing

[ywwg]

I feel like finger drumming and loop cues feel incompatible, but I am not the one to argue against very nice use cases.

I see hiphop / turntablist Serato DJs use cues for drumming quite often, so I think this is a legitimate usecase. (Y'all should watch DJs on Twitch, it's a great source of inspiration and exposure to different styles of DJing)

[ronso0]

that's why I'm proposing long press for delete, that's not an operation that requires perfect timing

Understood, but it wouldn't work if we also use Shift+press for jumping. My use case is deleting wrong/obsolete hotcues while playing.

In case I didn't miss anything, the current proposal is:

• press:
  • Hotcue: activate (jump to, previewing starts if deck is stopped
  • Loopcue: activate
• quick release:
  • Hotcue: stop preview
  • Loopcue: ---
• delayed release:
  • Hotcue: stop preview
  • Loopcue: jump to marker <-- NEW
• shift + press (default on controllers) / shift + right-click in GUI: delete

[betalars]

I have been leaving this thought in the back of my head for a little while now and would like to dump my current head state.

Meta: Requirements and Consistency

I think the biggest issue is the preexisting convention. Because the activate loop button has two different functions right now:

When the loop is in front, it just activates a loop. When the loop is behind, it becomes a hot cue and loop activation button. This has been a very sensible thing to do, but as we now also try to combine the hot cue and loop button into loop cues, it bites us into the butt.

Also: DJ software has really hard requirements. A solution should

• [ ] work instantaneously (so it can be used for finger drumming)
• [ ] not change existing conventions
• [ ] use as little keys as possible

Adding to the confusion are the many states loops can have.

• Cursor-position

  • before
  • inside
  • after

• loop engagement

  • active
  • inactive
    • cue button
  • empty
  • has hotcue
  • has loop cue

  So, the existing convention kind of boils down to:

• press

  • empty: assign new hotcue or loopcue
  • Hotcue: jump
  • Loopcue: activate and jump if behind
  • Loop: toggle loop active and jump on activation if behind

• hold (when stopped)

  • Hotcue: preview
  • Loopcue: preview
  • Loop: set loop behind cursor and toggle loop active

[betalars]

Suggesion 1: Rework Loopcues to have an optional jump-in point

I think the option that has the least amount of rework is to expand the capabilities of Loop Cues.

I was thinking of an optional jump-in point: When the hot cue does have it, it causes head to jump, when it does not have it, the music does not jump.

The suggested UX for this:

• on empty hot cue:
  • tap to create a new hot cue
  • tap while loop is active to create a new loop cue
  • hold while activating loop (using beatloop or reloop) to create hot loop with jump in point (new)

If a cue has a jump in point, it will also skip ahead when pressed. It also allows the creation of loops that have a jump in point before or within the loop.

[betalars]

Suggesion 2a: make loops only jump when long-pressed with CUE

This idea eliminates loops behaving differently depending on cursor position.

Pressing Reloop or a LoopCue will only toggle loop activation. To also make the loop jump, you have to press CUE while holding the Reloop or LoopCue.

It feels like this is the lowest hanging fruit, but I suspect it could add too much complexity to finger drumming with cues.

[betalars]

Maybe on long press release could work.

Yes, that was what I had in mind.

[betalars]

Suggesion 2b: make jumps also jump forward when long-pressed with CUE

I think the slightly more conservative option would be to not remove, but provide a workaround for the position-inconsistency.

So loops will still always jump backward, but you can make them also jump forward by pressing CUE while holding the loop toggle (so either Reloop or Loopcue).

[betalars]

For me personally, Suggestion 1 would be the best.

I think for everyone else, offering users to switch between behavior 2a and 2b via user settings is the cleanest solution.

[ronso0]

Thanks for your thoughts and suggestions! Some notes:

use as little keys as possible

... and should work with mouse/touchscreen, keyboard only and with controllers only.

1: Rework Loopcues to have an optional jump-in point That requires to either know how you'll be using a loop cue when you create it, or add/remove the jump-in point later on / before/while performing. I don't really like that. It should work either always or the jump mode should be selectable with some easy to reach control (GUI button).

2a/b: make loops only / also jump only when long-pressed with CUE Might work, is similar to jumping on long-press release. Need to test it to be sure.