-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Reworked beat_active control: #3608
Conversation
Thanks. Please open a manual PR to document the new behavior. That will make review easier. |
1196d3f
to
b6e25ad
Compare
-Made CO beat_active read-only -Update from engine::updateIndicators instead of process, which isn't updated enough for a reliable beat indicator -Fixed accuracy issue in beatgrid.cpp (compare to 1/100 of a beat period can be severalsamples off) -Don't calculate if deck is not playing -Set beat_active at the beat not +-50ms before/after -More states -Period of beat_active on is no longer hard coded 200ms, it's no 20% of the peat period
b6e25ad
to
4719d5e
Compare
Documentation is in mixxxdj/manual#347 |
…ithout tolerance epsilon
565ddb2
to
143f255
Compare
ac6d3a7
to
1a8f2c2
Compare
I am unsure if this is now just right. What is your use case for -1 -0.5 and 0.5? The simple use case is just a beat LED. It can be controlled like This works perfectly if we play forward and backward. But IMHO not too nice when scratching, because it will not reset after changing direction. My expectation is that I can cue by eye just like I can do by ear. Therefore a change at the beat is required. if (beat_active >= 1 || beat_active <= -1) { will be a solution. |
src/engine/controls/clockcontrol.cpp
Outdated
|
||
m_blinkIntervalSamples = (m_NextBeatSamples - m_PrevBeatSamples) * kBlinkInterval; | ||
} | ||
//qDebug() << "dRate:" << dRate << " m_lastPlayDirection:" << m_lastPlayDirection << " m_pCOBeatActive->get(): " << m_pCOBeatActive->get() << " currentSample: " << currentSample << " m_lastEvaluatedSample: " << m_lastEvaluatedSample << " m_PrevBeatSamples: " << m_PrevBeatSamples << " m_NextBeatSamples: " << m_NextBeatSamples << " m_blinkIntervalSamples: " << m_blinkIntervalSamples; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please break these long lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will remove this line later - it's just for my own debugging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for taking care.
The code looks good. Just a minor code style comment.
do you the precommit hook?
https://github.com/mixxxdj/mixxx/wiki/Using-Git#set-up-automatic-code-checking
The intention was to give the mapping developer all possibilities: But maybe it's too much. If I remove the +- 0.5 states an use the value 0 instead, a simple |
No, I don't use it. But the pre-commit check in the GitHub actions passed. Isn't this the same check? |
Regarding the state of this code:
|
I won't use 3) do you? |
Yes, that should be the same. I have no Idea why it is not complaining about the long comments. |
Did you test using a controller LED or a GUI LED? I can imagine that there is a significant jitter due to the processing of the midi messages. Do you have similar issues with the VU meter? |
24c759b
to
eead474
Compare
The CO returns now 0 for the cases of play direction changes while beat indication is on
eead474
to
5cb6696
Compare
I changed this, the states +-0.5 are no longer send to the CO. |
In this case, can you rebate it to 2.3?
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works already good. I have left some commit. For the test, I have mapped the kill buttons, and it is really fun.
Can we switch of the indicator if the track is paused on a cue point? Currently is is sometimes on and sometimes off when at a cue point, which is placed on a beat.
Unfortunately the backward direction does not work instantly. Because in Mixxx we have the definition that ON = x > 0. A rocker switch would have the values 0 1 2 ..
Would it be OK to use 2 for backwards, than it is full compatible to a three state GUI button.
Especially with long audio buffers, the jitter is visible. This can be fixed by moving the ClockControl::updateIndicators into the waveform update loop which is synced with the display refresh rate. Via the visual play position you have access to the sample that is currently played, and not the one that have been processed as in the current solution.
Optimizing this for the GUI did not help much with the latency that happens until the signal is at the controller though. So the full blown solution has to consider both paths individual.
This is obviously no longer a bug fix and a mayor refactoring. Maybe you should just add a note about it in ClockControl::updateIndicators for the case we want to pick it up in future.
…olerance/snap behavior
m_pCOBeatActive->forceSet(0.0); | ||
} | ||
} | ||
m_lastPlayDirection = false; // Reverse | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer
} | |
} else { | |
m_pCOBeatActive->forceSet(0.0); | |
} |
Because I experience that the LED is sometimes on and sometimes off when paused at a cue point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look how to solve the cue point issue. The proposed else branch will not do this. It will never be reached, because this is captured before, to not switch the indicator off due the jitter of the DVS pitch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I applied a fix for this, which should not break the use case of searching the beat position using DVS or jog. Please test, if this solves the cue point issue for you too.
eacfdd6
to
02bc663
Compare
…is hold on a beat
02bc663
to
277ed26
Compare
@daschuer Did you tried the latest version of this PR? From my point of view, everything is working now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works perfectly now.
Thank you very much.
Merge? |
Ups, must have missed to hit merge. |
…ented in PR#3608 (#347) See mixxxdj/mixxx#3608 for details. - Updated to new 3 state implementation - Updated state values to match the outcome of the code review - Added note how to implement mappings for slow controllers
-Made CO beat_active read-only
-Set CO only if there's a state change
-Update from engine::updateIndicators instead of process, which isn't updated enough for a reliable beat indicator
-Added NoTolerance mode in beatgrid.cpp
-Don't calculate if deck is not playing or vinyl/jog is hold standstill (inside +-2.5ms tracktime at normal speed)
-Set beat_active at the beat not +-50ms before/after
-Reverse state
-Period of beat_active on is no longer hard coded 200ms, it's no 20% of the peat period
See also discussion at: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/beat_active