Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve loop_in/_out adjust workflow #10658

Open
mixxxbot opened this issue Aug 23, 2022 · 8 comments
Open

improve loop_in/_out adjust workflow #10658

mixxxbot opened this issue Aug 23, 2022 · 8 comments

Comments

@mixxxbot
Copy link
Collaborator

Reported by: holopansel
Date: 2022-02-09T18:53:21Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1960439
Tags: looping


According to the user manual it should be possible after manual loop set to push loop-in or loop-out again to adjust the in or out point.

When the loop-in is clicked again, the in position moves directly forward in time. And it is possible to set a new position after the old position. The same applies for the loop-out.

Expected behavior would be that when the loop is already set and either button clicked that the loop stays in position until moved by the user and then with a third click confirms the new point.
This is also the behavior of common cd players.

A common scenario or maybe the most common scenario is that loop-in or loop-out is clicked some milliseconds to late and needs to be adjusted to the beginning, so backward in time. This is simply not possible with the current implementation.

I do not think that it matters here, but anyway I'm using Debian 11, Intel evo I7 4 core on a Dell 7420 Laptop. Driver is Alsa,

Hope, I explained the problem well enough, I am available for clarifications if necessary.
Best regards,
John Last

@mixxxbot
Copy link
Collaborator Author

mixxxbot commented Aug 23, 2022

Commented by: ronso0
Date: 2022-05-11T10:44:48Z


As far as I understand your request, that requires decoupling the position bar from the actual play head, i.e.

  • lock loop_in/_out button
    = freeze the waveform
    = make the play head move
  • make deckN,jog controls NOT move the track but move the loop_in/_out marker
    This requires massive changes to the waveform renderer.
    This also creates some difficult situations, for example if the loop is too long to fit into the current waveform window the play head is not visible.

Maybe you noticed that the beatjump controls switch to moving loops as soon as one is activated?
With that in mind, an alternative solution could be:

  • lock loop_in/_out button with Shift+click (click, click+hold and
    right-click are already used)
  • set the beatjump_size to some reasonable small amount, e.g. 1/8 beat
  • make beatjump controls move the loop marker
  • move loop_in
  • unlock loop_in, restore beatjump size

@mixxxbot
Copy link
Collaborator Author

Commented by: holopansel
Date: 2022-05-13T07:18:05Z


Yes, exactly, you understood correctly.

What you explained would be the preferred solution. If technically not feasible, also your alternative solution seems to be much better than the way it is currently.

Thank you for your support.

@mixxxbot
Copy link
Collaborator Author

mixxxbot commented Aug 23, 2022

Commented by: ronso0
Date: 2022-05-13T10:36:12Z


Alright.
Tbh, I also gave up trying to adjust loop_in when the track is playing, so I'd be interested in a solution, too.

Unfortunately I don't see a way to integrate the alternative model into existing mappings. Shift+loop markers is already mapped to loop_in/out_gotoandstop (I think).
When the track is stopped, the current behaviour is perfect though.

However, what I described can curently be implemented at the mapping script level, if I'm not mistaking:

  • map loop_in to some function, e.g. YourController::loopInButton
  • if (pressed && deckIsPlaying) { loopInAdjust = true; }
    elseif (released) { loopInAdjust = false; }
  • map the jog signal to some function (or alter an existing wheelTurn
    function):
    if (deckIsPlaying && loopInAdjust === true) {
    • register the jog ticks
    • read loop_in_position (in samples)
    • read track_samplerate (/2 == samples/second per channel)
    • multiply with the desired [loop_in step in seconds] and [jog ticks],
      verify it doesn't exceed total track_samples
    • add/substract result to current loop_in position
    • set new loop_in position
      }

This would also allow to move loop_in backwards which is currently not possible (while playing the loop).
Drawback is that --depending on the loop length-- the loop_in marker may move out of sight.

I doubt someone would simultaneously drag the loop_in marker AND nudge the track with the wheel, so I hope this behaviour doesn't conflict with established use cases.

I guess this can also be implemented in the c++ code, though it's probably cumbersome to integrate into the current looping code.
Nevertheless, I'm interested, too, so I'll try the script approach myself, and take a look at the looping code.


Good news is: with Mixxx 2.4 you can prepare and save multiple loops per track. Save and recall works with the hotcue buttons, as well as labeling (and colors IIRC).

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2022-05-13T21:25:26Z


This is also the behavior of common cd players.

Is there a video online demonstrating that desired behavior?

@mixxxbot
Copy link
Collaborator Author

Commented by: holopansel
Date: 2022-05-21T06:51:33Z


You can see James Hype using this feature here:
https://www.youtube.com/watch?v=sDsKeBofEBw&t=1018s
loop set up starting roughly at 25:10 min,
loop adjust (in and out) starting from 25:20 min.

I also found this:
https://www.youtube.com/watch?v=3mQJALlES_Y

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2022-05-21T20:22:33Z


launchpad is still no fun for discussion (@mention, code snippets) so I started https://mixxx.zulipchat.com/#narrow/stream/247619-UI-.26-UX-design/topic/improve.20loop_in.2F_out.20adjustment.20workflow

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@mixxxdj mixxxdj deleted a comment from mixxxbot Sep 22, 2022
@ronso0
Copy link
Member

ronso0 commented Mar 13, 2024

Update

I implemented this in my Reloop TerminalMix mapping, here's the xml and js snippets:
https://gist.github.com/ronso0/6556254fcee7bb54cf468806d0b65828

@gqzomer did it in a similiar way for the Reloop Mixage #12296 in this commit 9f76150

For controllers this can be integrated into midi-components-js's JogWheelBasic.prototype:

  • both the inputWheel: and inputTouch: would need to consider the loop_in state
  • inputWheel: would do engine.setValue(group, "loop_start_position", newPos);

For the GUI / keyboard this is a bit more tricky:
(ignoring the CDJ approach for now, i.e. the waveform freezes and mouse scratch could move the in/out marker)

@tobiasBora
Copy link

Just to jump on this issue, see also this nice video with a great interface to change it dynamically (4mn58, link should point there): https://youtu.be/ziZa7aRwYqA?t=298

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants