Skip to content

Removing Random jump into Loop when qantisation is enabeled.#7

Merged
Be-ing merged 1 commit intoBe-ing:beatloop_sizefrom
daschuer:beatloop_size
May 20, 2017
Merged

Removing Random jump into Loop when qantisation is enabeled.#7
Be-ing merged 1 commit intoBe-ing:beatloop_sizefrom
daschuer:beatloop_size

Conversation

@daschuer
Copy link
Copy Markdown

The main problem is fixed.
A small random jump is still there, when only one track is loaded.

Don't jump into loop  when plaing before an enabled catching loop.
Don't disable a loop wen wee seek before it.
@daschuer
Copy link
Copy Markdown
Author

I cannot reproduce this remaining small jump in an old master. Is this a regression?

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Tests are failing:

[ RUN      ] LoopingControlTest.BeatLoopSize_SetAndToggle
...
src/test/looping_control_test.cpp:599: Failure
Value of: m_pLoopEnabled->toBool()
  Actual: true
Expected: false
src/test/looping_control_test.cpp:600: Failure
Value of: m_pBeatLoop2Enabled->toBool()
  Actual: true
Expected: false
in ~EngineMaster() 
[  FAILED  ] LoopingControlTest.BeatLoopSize_SetAndToggle (52 ms)
[ RUN      ] LoopingControlTest.BeatLoopSize_IsSetByNumberedControl
...
src/test/looping_control_test.cpp:645: Failure
Value of: m_pBeatLoop2Enabled->toBool()
  Actual: true
Expected: false
src/test/looping_control_test.cpp:646: Failure
Value of: m_pLoopEnabled->toBool()
  Actual: true
Expected: false
in ~EngineMaster() 
[  FAILED  ] LoopingControlTest.BeatLoopSize_IsSetByNumberedControl (288 ms)
[ RUN      ] LoopingControlTest.BeatLoopSize_ValueChangeDoesNotActivateLoop
...
src/test/looping_control_test.cpp:682: Failure
Value of: m_pLoopEnabled->toBool()
  Actual: true
Expected: false
src/test/looping_control_test.cpp:684: Failure
Value of: m_pLoopEnabled->toBool()
  Actual: true
Expected: false
src/test/looping_control_test.cpp:685: Failure
Value of: m_pBeatLoop4Enabled->toBool()
  Actual: true
Expected: false
in ~EngineMaster() 
[  FAILED  ] LoopingControlTest.BeatLoopSize_ValueChangeDoesNotActivateLoop (56 ms)
[ RUN      ] LoopingControlTest.BeatLoopSize_ValueChangeResizesBeatLoop
...
src/test/looping_control_test.cpp:701: Failure
Value of: m_pLoopEnabled->toBool()
  Actual: true
Expected: false
in ~EngineMaster() 
[  FAILED  ] LoopingControlTest.BeatLoopSize_ValueChangeResizesBeatLoop (57 ms)

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Whoops I think those test failures are from my recent change.

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Yeah, the test failures are from my last commit. I'll take care of that.

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Pressing reloop_toggle when the play position is after the loop enables the loop but does not seek to it. Is this intended?

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

A small random jump is still there, when only one track is loaded.

I think this is a known bug with quantize that doesn't have to do with looping.

@Be-ing Be-ing merged commit 0dbdf38 into Be-ing:beatloop_size May 20, 2017
@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Thanks for fixing this!

if (dNewPlaypos < loopSamples.start || dNewPlaypos > loopSamples.end) {
// Disable loop when we jump after it, using hot cues or waveform overview
// If we jump before, the loop it is kept enabled as catching loop
if (dNewPlaypos > loopSamples.end) {
Copy link
Copy Markdown
Owner

@Be-ing Be-ing May 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand why LoopingControl::process() doesn't jump to the loop without setting m_bReloopCatchUpcomingLoop to true here, but it works somehow.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, m_bReloopCatchUpcomingLoop is already true because I pressed reloop_toggle.

@Be-ing
Copy link
Copy Markdown
Owner

Be-ing commented May 20, 2017

Pressing reloop_toggle when the play position is after the loop enables the loop but does not seek to it. Is this intended?

Nevermind, I can't reproduce this issue.

Be-ing pushed a commit that referenced this pull request Jan 7, 2019
use function pointers for Qt connections in ControllerEngine
Be-ing pushed a commit that referenced this pull request Apr 8, 2022
…h sync

When loading a track that is not yet present in the library (and thus
doesn't have any BPM because it hasn't been analyzed yet) while another
deck is playing and both decks have sync enabled, a debug assertion is
triggered:

    DEBUG ASSERT: "isValid()" in function double mixxx::Bpm::value() const at src/track/bpm.h:53
    Aborted (core dumped)

The backtrace looks as follows:

    #0  0x00007f175c87234c in __pthread_kill_implementation () at /usr/lib/libc.so.6
    #1  0x00007f175c8254b8 in raise () at /usr/lib/libc.so.6
    #2  0x00007f175c80f534 in abort () at /usr/lib/libc.so.6
    #3  0x00007f175cf05ee4 in qt_assert(char const*, char const*, int) () at /usr/lib/libQt5Core.so.5
    #4  0x000055deb2e67e1c in mixxx::(anonymous namespace)::handleMessage(QtMsgType, QMessageLogContext const&, QString const&) (type=<optimized out>, context=<optimized out>, input=<optimized out>) at src/util/logging.cpp:355
    #5  0x00007f175cf47128 in  () at /usr/lib/libQt5Core.so.5
    #6  0x00007f175cf3fd8a in  () at /usr/lib/libQt5Core.so.5
    #7  0x00007f175cf06526 in QMessageLogger::critical(char const*, ...) const () at /usr/lib/libQt5Core.so.5
    #8  0x000055deb2e5c720 in mixxx_debug_assert(char const*, char const*, int, char const*) (assertion=assertion@entry=0x55deb39bd0db "isValid()", file=file@entry=0x55deb39bbf30 "src/track/bpm.h", line=line@entry=53, function=function@entry=0x55deb39bbf08 "double mixxx::Bpm::value() const") at gsrc/util/assert.h:9
    #9  0x000055deb2ee7e7e in mixxx_debug_assert_return_true(char const*, char const*, int, char const*) (function=0x55deb39bbf08 "double mixxx::Bpm::value() const", line=53, file=0x55deb39bbf30 "src/track/bpm.h", assertion=0x55deb39bd0db "isValid()") at gsrc/util/assert.h:18
    #10 mixxx::Bpm::value() const (this=<synthetic pointer>) at src/track/bpm.h:53
    #11 mixxx::operator*(mixxx::Bpm, double) (multiple=1, bpm=...) at src/track/bpm.h:160
    #12 SyncControl::setLocalBpm(mixxx::Bpm) (this=<optimized out>, localBpm=...) at src/engine/sync/synccontrol.cpp:567
    #13 0x000055deb34c7ba3 in EngineBuffer::postProcess(int) (this=0x55deb56eb060, iBufferSize=2048) at src/engine/enginebuffer.cpp:1318
    #14 0x000055deb3139023 in EngineMaster::processChannels(int) (this=0x55deb5449440, iBufferSize=<optimized out>) at src/engine/enginemaster.cpp:383
    #15 0x000055deb31394f7 in EngineMaster::process(int) (this=0x55deb5449440, iBufferSize=iBufferSize@entry=2048) at src/engine/enginemaster.cpp:410
    #16 0x000055deb2f91d0b in SoundManager::onDeviceOutputCallback(long) (this=<optimized out>, iFramesPerBuffer=iFramesPerBuffer@entry=1024) at src/soundio/soundmanager.cpp:596
    #17 0x000055deb32dd794 in SoundDevicePortAudio::callbackProcessClkRef(long, float*, float const*, PaStreamCallbackTimeInfo const*, unsigned long) (this=0x55deb553e6b0, framesPerBuffer=1024, out=<optimized out>, in=<optimized out>, timeInfo=<optimized out>, statusFlags=<optimized out>) at src/soundio/sounddeviceportaudio.cpp:965

This happens because `newLocalBpm` is invalid when `localBpm` is
invalid. Trying to do sync decks while no tempo information is available
does not make sense, so we only synchronize decks if the local BPM is
available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants