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

Reworked beat_active control: #3608

Merged
merged 18 commits into from
Mar 20, 2021

Conversation

JoergAtGithub
Copy link
Member

@JoergAtGithub JoergAtGithub commented Jan 31, 2021

-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

grafik

See also discussion at: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/beat_active

@JoergAtGithub JoergAtGithub marked this pull request as draft January 31, 2021 17:06
@Holzhaus
Copy link
Member

Thanks. Please open a manual PR to document the new behavior. That will make review easier.

-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
@JoergAtGithub
Copy link
Member Author

Thanks. Please open a manual PR to document the new behavior. That will make review easier.

Documentation is in mixxxdj/manual#347

@daschuer
Copy link
Member

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
if (beat_active) {
set_led()
} else {
reset_led()
}

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) {
set_led()
} else {
reset_led()
}

will be a solution.


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;
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@daschuer daschuer left a 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

@JoergAtGithub
Copy link
Member Author

I am unsure if this is now just right. What is your use case for -1 -0.5 and 0.5?

The intention was to give the mapping developer all possibilities:
1)Search the beat by LED (therfore the LED must go of if direction changes)
2)Only show LED in normal playing direction.
3)LED On if position is close to the beat independent of direction

But maybe it's too much. If I remove the +- 0.5 states an use the value 0 instead, a simple
if (beat_active !== 0)
set_led()
} else {
reset_led()
}
would work for case 1.
Only case 3) would be impossible. The reason for case 3 is taht it's similar to the current behavior

@JoergAtGithub
Copy link
Member Author

JoergAtGithub commented Feb 21, 2021

do you the precommit hook?

No, I don't use it. But the pre-commit check in the GitHub actions passed. Isn't this the same check?

@JoergAtGithub
Copy link
Member Author

Regarding the state of this code:

  • Slow searching of a position with vinyl and LED works very well now!
  • But while playing, the indication is not always at the expected moment. At least no beat seems to be missing anymore.
    My laptop is not very powerfull, maybe this is the reason

@daschuer
Copy link
Member

I won't use 3) do you?
If not, let's remove it to simplify the other two.

@daschuer
Copy link
Member

do you the precommit hook?

No, I don't use it. But the pre-commit check in the GitHub actions passed. Isn't this the same check?

Yes, that should be the same. I have no Idea why it is not complaining about the long comments.
My point is just to remove the annoyance of vertical scrolling during code reviews.

@daschuer
Copy link
Member

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?

The CO returns now 0 for the cases of play direction changes while beat indication is on
@JoergAtGithub
Copy link
Member Author

I won't use 3) do you?
If not, let's remove it to simplify the other two.

I changed this, the states +-0.5 are no longer send to the CO.

@daschuer daschuer changed the base branch from main to 2.3 March 1, 2021 16:11
@daschuer daschuer changed the base branch from 2.3 to main March 1, 2021 16:11
@daschuer
Copy link
Member

daschuer commented Mar 1, 2021

In this case, can you rebate it to 2.3?

git rebase --onto upstream/2.3 4719d5e9529e39b64e46e3cf46fe06a6106e0e66~1

Copy link
Member

@daschuer daschuer left a 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.

src/track/beatgrid.h Outdated Show resolved Hide resolved
src/engine/controls/bpmcontrol.cpp Show resolved Hide resolved
src/engine/controls/clockcontrol.cpp Outdated Show resolved Hide resolved
src/engine/controls/clockcontrol.cpp Show resolved Hide resolved
m_pCOBeatActive->forceSet(0.0);
}
}
m_lastPlayDirection = false; // Reverse
}
Copy link
Member

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

Suggested change
}
} else {
m_pCOBeatActive->forceSet(0.0);
}

Because I experience that the LED is sometimes on and sometimes off when paused at a cue point.

Copy link
Member Author

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.

Copy link
Member Author

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.

@JoergAtGithub JoergAtGithub marked this pull request as draft March 3, 2021 19:22
@JoergAtGithub JoergAtGithub marked this pull request as ready for review March 5, 2021 20:23
@JoergAtGithub JoergAtGithub force-pushed the improve_beat_indicator branch 2 times, most recently from eacfdd6 to 02bc663 Compare March 6, 2021 11:48
@JoergAtGithub
Copy link
Member Author

@daschuer Did you tried the latest version of this PR? From my point of view, everything is working now.

Copy link
Member

@daschuer daschuer left a 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.

@JoergAtGithub
Copy link
Member Author

Merge?

@daschuer
Copy link
Member

Ups, must have missed to hit merge.

@daschuer daschuer merged commit 4ffba2a into mixxxdj:main Mar 20, 2021
Holzhaus pushed a commit to mixxxdj/manual that referenced this pull request Apr 27, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants