Don't allow to set loop in/out at the silence padding after the track.

[daschuer]

This fixes #11557

[ronso0]

.

[daschuer]

Done.

[ronso0]

Thanks, but unfortunately it's still not clamping to track end.
I tried with the same track many times, and often it failed when dragging the loop_out, but it definitely fails when I let the track play to the end then hit Loop_out.

Finally I figured the issue is that QuantizeControl::lookupBeatPositions uses the current position (which may already be / likely IS after the end), so --with a bit of luck-- even m_pPreviousBeat is after the end, too :
With that in mind, maybe it makes sense to go back to square one here, instead of incremental fixes, idk.

Btw, if you decide to keep the current commits, could you please reword the last commit?
"Make sure the loop in and loop out is not placed on an extended beat behind the track"

[daschuer]

I have fixed the issue along with some corner cases with holding the loop in or out button. Instead of stopping the track or take an inconsistent state it now loops to loop in instead and keeps the track running.
I consider this much better than the silence of a stopped track.

[ronso0]

While that last change isn't expected behaviour IMO it may still be a welcome helper.
And it seems to work around a new (yet unknown) issue in the engine buffer (or ReadAheadManager or LoopingControl::nextTrigger, idk):

• I reverted that last commit
• set the loop_out to the latest possible position
• set something like an 8-beat loop, play
• click and hold loop_in
• when it comes very close to loop_out, the smallest loop size possible is used
• that small loop plays a few times but suddenly the deck stops (seems the play pos crossed the track end)

Maybe that is fixed with #11532 or #11152 (with my proposed changes included)

So, this LGTM, I'll do some more testing soonish.

[ronso0]

LGTM, this is much beter than before!

However, there still seems to be a chance to stop the deck unexpectedly.
I set loop_out at track end, let the loop run, and click loop_in repeatedly.
At some pont this should produce the shortest possible loop. Though I managed to stop the deck with that (once, didn't try more often, and I don't see how that could happen 🤷‍♂️ ).

Another issue I spotted (unrelated to this PR) is that the waveform play pos definitely goes beyond the track end with that very short loop.