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

don't stop track when loop_in/out is beyond track boundaries #9478

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

don't stop track when loop_in/out is beyond track boundaries #9478

mixxxbot opened this issue Aug 23, 2022 · 10 comments

Comments

@mixxxbot
Copy link
Collaborator

Reported by: ronso0
Date: 2018-10-23T20:47:06Z
Status: Confirmed
Importance: Medium
Launchpad Issue: lp1799574
Tags: looping


I create a 8-beat loop loop close to the track end and shift the loop to have loop_in at the beginning of a vocal phrase. I could move the loop let's say 1/8 beat beyond the track end (= loop_out after track end, but no indicator where that end point actually is Bug 1799576) and the loop would stop playing as soon as it reaches the track end.

I see there'a reason to not allow huge loops (unexpecedly) cross tracks' start/end, but there are use cases where this is actually very helpful:

  1. I somehow didn't notice the track end is getting closer, and as a quick hack I'd enable a 4-beat loop to gain some more seconds to load and align the next track. I might be very late and that loop would cross the track end. Let it continue playing..
  2. 3 beats before the track end there's a vocal I'd like to have in an 8-beat loop to match the next track, and I want that vocal only and cut off the preceeding beats. Same applies to loops crossing the first sample of a track.

2.3.0-alpha-pre

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2018-12-23T21:54:27Z


Ok, the current situation is odd.

I am not sure what the right solution is though.

1.) We may play past the end, which is unfortunately silence.
2.) We may not allow to move a beatloop past the track end, ignoring the beatjump.
3.) We may fix loop out at the track end, falling out of beat.
4.) We may short the loop at the last beat to not go beyond the track end but be in beat.

Unfortunately the engine can play past a track right-now. So 1. involves some refactoring. Is it worth the work, or is the silence part undesired anyway?
Does one of the other solutions suite?

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2018-12-23T22:37:32Z


  1. would be the winner :) because loop_end after track end would be a feature IMO

The playback should stop at the end only when there's no active loop with loop_end beyond the end.

For rewind it works quite well right now: you can scroll before the track start, when dragging waveforms or with controller wheel in scratch mode. OTOH the rewind stops at the track start when the wheel is in jog mode, which is also a nice feature.

@mixxxbot
Copy link
Collaborator Author

Commented by: mevsme
Date: 2019-12-17T11:37:23Z


Maybe also, as a variant, we can make recursive loop that starts at the end and finish at the start? D

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2019-12-17T13:08:20Z


that's just the play direction. use '[group],reverse' '1'

loop_in at end, loop_out at start would create a zero-length loop.
what would happen then? would mixxx create a black hole?

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2019-12-17T14:08:58Z


mevsme's idea is to build a loop that runs bejond the end of the track as if repeat was enabled, by jumping to the beginning and playing the missing samples from there.

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2019-12-17T15:22:29Z


ok, I misunderstood 'recursive'.

I think the chance samples from the start fit better than silence is quite low. If I stick to the vocal use case I mentioned above it would probably be fading out anyway, so silence wouldn't be a problem for me.

IMHO, to avoid refactoring or making the loop code more complicated it'd be best (easiest for now) to prevent the loop being shifted beyond the end?

@mixxxbot
Copy link
Collaborator Author

mixxxbot commented Aug 23, 2022

Commented by: ronso0
Date: 2019-12-18T16:09:16Z


Using samples from the start is problematic IMO as users probably don't expect it, and if the do the result is unprecitable because that range is not visible on the waveform.

Extending the loop-able range beyond the track and filling that space with silence would still be my preferred solution because you would get what you see: silence.
If the engine could do that the remaining question is just:
how far may the loop to span behind the end to avoid long silence?

What about limiting that part to at most the half of the desired loop?
Example:

  • X beats before end, X=track_end - play_pos
  • attempt to set a loop of N beats
if (X > N/2) {
  beatloop_activate
  return
} else {
  N=N/2
  // repeat
}

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2020-09-23T15:18:19Z


Since I ran into this bug repeatedly I'll work on a fix for 2.3

I'll go with
2.) don't allow to move a beatloop past the track end

#3117

@mixxxbot
Copy link
Collaborator Author

Commented by: JoergAtGithub
Date: 2021-04-18T20:31:39Z


I would like to add an additional use case, with a loop beyond the track end:
I've some tracks with just beats(drums). These tracks are all exactly 16 or 32 beats long. The analyzer detects the beat period precisely with 1/16th (or 1/32th) of the track length, but because the position of the first beat is not detected in the very first sample of the track, the loop does not fit.

To handle this use case I propse the following behavior:
If the loop has the same number of samples as the track itself, the playposition should jump after the last sample of the track, to the first sample of the track.

@mixxxbot
Copy link
Collaborator Author

Commented by: ronso0
Date: 2021-05-05T23:15:26Z


for reference, this is the place where 'play' is disabled when play_pos passes track_end:
https://github.com/mixxxdj/mixxx/blob/2.3/src/engine/enginebuffer.cpp#L1001-L1019

IMO the looping control should stay as is and shouldn't bother with track_end. Except that (when reverting #⁠3117) we need to set some limit for how far a loop can be set/moved beyond the track's end to avoid long useless silence, right?

when passing track_end EngineBuffer::processTrackLocked() would check if play_pos id within an active loop: if true it wouldn' touch 'play' and the track continues.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
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

1 participant