Implement Stem VU Meter Control Objects by xARSENICx · Pull Request #15887 · mixxxdj/mixxx

xARSENICx · 2026-01-20T22:13:12Z

Description

This PR implements individual VU Meter Control Objects (COs) for Stems.

Key Changes

EngineDeck: Added m_stemVuMeter vector to storeEngineVuMeter instances for each stem.
Initialization: Configured stem VU meters in EngineDeckconstructor with group names like [ChannelX_StemY].
Processing: Wired m_stemVuMeter[i]->process() into EngineDeck::processStem to analyze the post-fader stem audio.
Tests: Added regression tests in stemcontrolobjecttest.cpp(to verify COs are created and emit values during playback.)

Related Issues

Fixes #13699

Verification

Added temporary widget to Tango skin and verified VU meter responds to audio. (Reverted to original state in the PR)

Screen.Recording.2026-01-20.at.5.05.53.PM-2.mp4

Verified Mute button stops the VU meter visual (functionally working).
Unit tests pass (m_pStem1VuMeter->get() > 0.0 when active).

Adds m_stemVuMeter to EngineDeck to calculate and emit VU meter values for each stem. Adds unit tests in StemControlFixture (VuMeter) to verify connectivity. Manual verification confirmed visual VU meter response in Tango skin (skin changes reverted). Fixes mixxxdj#13699

Eve00000 · 2026-01-21T07:55:34Z

Those vu-meters are really nice, I never thought about them.
How accurate are they?

xARSENICx · 2026-01-21T21:17:23Z

Those vu-meters are really nice, I never thought about them.

Thanks @Eve00000 . :)

How accurate are they?

You can refer to my reply to @JoergAtGithub above. The Stem COs just inherit the behaviour of a vu-meter. So, all the math involved in attack/decay of a vu-meter govern the Stem COs too. If you want I can give you a quick heads-up as to how they behave as I went through the implementation thoroughly for creation of Stem COs

daschuer · 2026-01-21T22:06:49Z

The current Mixxx VU meter is somewhere between a paek meter and a VU meter,
The are currently designed to look good. Not to be extra precise.
They suites for DJ-ing, but do not compare to pro broadcasting gear.
See:
#7888

xARSENICx · 2026-01-21T22:36:03Z

The current Mixxx VU meter is somewhere between a paek meter and a VU meter,

The are currently designed to look good. Not to be extra precise.

That is true. Thanks for the referencing issue, I wasn't aware of it's existence although I did come across this behaviour while going through the implementation. Correct me if I am wrong, but with an actual VU meter, the attack/decay time is in ~300 ms which would create an apparent lag in the LED indicator while the mixxx VU just sits right around ~10ms.

So for our stem COs, shipping with mixxx VU seems good enough to me. Wdyt?

JoergAtGithub · 2026-01-21T23:01:08Z

So for our stem COs, shipping with mixxx VU seems good enough to me. Wdyt?

Yes, as all VU-Meters should behave the same. There are several different scaling standards for such meters. But implementing these is out of scope here.

xARSENICx · 2026-01-23T02:20:53Z

Bumping for someone to test with a controller to ensure this works correctly.

acolombier · 2026-01-23T13:06:56Z

I can try to have a look over the weekend. Thanks for your contribution!

acolombier

Tested and works as expected!

Tried QML as well with the following patch

diff --git a/res/qml/Deck/HotcueAndStem.qml b/res/qml/Deck/HotcueAndStem.qml
index 881c42af54..ee8b949c0d 100644
--- a/res/qml/Deck/HotcueAndStem.qml
+++ b/res/qml/Deck/HotcueAndStem.qml
@@ -401,23 +401,23 @@ Item {
                                 top: parent.top
                             }
 
-                            // Skin.VuMeter {
-                            //     x: 15
-                            //     y: (parent.height - height) / 2
-                            //     width: 4
-                            //     height: parent.height - 40
-                            //     group: root.group
-                            //     key: "vu_meter_left"
-                            // }
+                            Skin.VuMeter {
+                                x: 11
+                                y: (parent.height - height) / 2
+                                width: 3
+                                height: parent.height - 10
+                                group: stem.group
+                                key: "vu_meter_left"
+                            }
 
-                            // Skin.VuMeter {
-                            //     x: parent.width - width - 15
-                            //     y: (parent.height - height) / 2
-                            //     width: 4
-                            //     height: parent.height - 40
-                            //     group: root.group
-                            //     key: "vu_meter_right"
-                            // }
+                            Skin.VuMeter {
+                                x: parent.width - width - 11
+                                y: (parent.height - height) / 2
+                                width: 3
+                                height: parent.height - 10
+                                group: stem.group
+                                key: "vu_meter_right"
+                            }
 
                             Skin.ControlFader {
                                 id: volumeSlider

Screencast.From.2026-01-25.19-30-52.mp4

acolombier · 2026-01-25T19:34:21Z

+    // FIXME: This assertion fails in unit test (value stays 1.0) but passed manual verification.
+    // Likely due to test harness buffer handling or settling time.
+    // EXPECT_NEAR(m_pStem1VuMeter->get(), 0.0, 0.001);
+
+    // Stem 2 should still be playing
+    // EXPECT_GT(m_pStem2VuMeter->get(), 0.0);


Is this FIXME still relevant?

Yeah, the unit test that I tried to write to test the mute button was not working. (so, by manual testing here I meant the decay fall of vu-meter when a stem is muted in the temporary GUI I made locally- it was working flawlessly.)
Although since then, I did fix this. I will commit the changes.

xARSENICx · 2026-01-25T21:21:59Z

Tried QML as well with the following patch

Thanks! I haven't been working with QML yet as I am not that familiar with QML specifically (I am learning on the side).

…d stems

acolombier

LGTM! Could you please prepare a manual PR with the newly introduce COs?

Here is an example on how to do so: mixxxdj/manual#644

JoergAtGithub

The existing vu_meter COs have deprecated names like VuMeter. This PR adds not only the new naming for the stem vu_meter COs, but also the deprecated names.

xARSENICx · 2026-01-27T21:25:32Z

The existing vu_meter COs have deprecated names like VuMeter. This PR adds not only the new naming for the stem vu_meter COs, but also the deprecated names.

Will refractoring EngineVuMeter.h and EngineVuMeter.cpp to optionally skip creating the legacy aliases (e.g., VuMeter, VuMeterL/R) via a new constructor argument work? Basically, initializing the Stem VU meters with this flag set to false, so they only expose the new vu_meter controls as requested. Does this approach align with your expectations?

EngineVuMeter(const QString& group, const QString& legacyGroup = QString(), bool createAliases = true);

allowing

EngineVuMeter::EngineVuMeter(const QString& group, const QString& legacyGroup, bool createAliases)
        : m_vuMeter(ConfigKey(group, QStringLiteral("vu_meter"))),
          m_vuMeterLeft(ConfigKey(group, QStringLiteral("vu_meter_left"))),
          m_vuMeterRight(ConfigKey(group, QStringLiteral("vu_meter_right"))),
          m_peakIndicator(ConfigKey(group, QStringLiteral("peak_indicator"))),
          m_peakIndicatorLeft(ConfigKey(group, QStringLiteral("peak_indicator_left"))),
          m_peakIndicatorRight(ConfigKey(group, QStringLiteral("peak_indicator_right"))),
          m_sampleRate(QStringLiteral("[App]"), QStringLiteral("samplerate")) {
    if (createAliases) {
        const QString& aliasGroup = legacyGroup.isEmpty() ? group : legacyGroup;
        m_vuMeter.addAlias(ConfigKey(aliasGroup, QStringLiteral("VuMeter")));
        m_vuMeterLeft.addAlias(ConfigKey(aliasGroup, QStringLiteral("VuMeterL")));
        m_vuMeterRight.addAlias(ConfigKey(aliasGroup, QStringLiteral("VuMeterR")));
        m_peakIndicator.addAlias(ConfigKey(aliasGroup, QStringLiteral("PeakIndicator")));
        m_peakIndicatorLeft.addAlias(ConfigKey(aliasGroup, QStringLiteral("PeakIndicatorL")));
        m_peakIndicatorRight.addAlias(ConfigKey(aliasGroup, QStringLiteral("PeakIndicatorR")));
    }

So, for stems we do

m_stemVuMeter.emplace_back(std::make_unique<EngineVuMeter>(
                getGroupForStem(getGroup(), stemIdx), QString(), false));

This way other stuff relying on EngineVuMeter wouldn't require a re-write either. LMK if this sounds good or am I complicating it.

JoergAtGithub · 2026-01-27T21:38:07Z

Will refractoring EngineVuMeter.h and EngineVuMeter.cpp to optionally skip creating the legacy aliases (e.g., VuMeter, VuMeterL/R) via a new constructor argument work?

Yes, it will! I would name the argument createLegacyAliases

Avoid creating legacy ControlObject aliases (e.g. VuMeter, VuMeterL) for Stem VU meters, as requested during review. - Added createLegacyAliases flag to EngineVuMeter constructor (default true). - Disabled this flag for Stem VU meters in EngineDeck.

acolombier · 2026-01-27T23:08:26Z

Thank you!

github-actions Bot added engine code quality labels Jan 20, 2026

JoergAtGithub reviewed Jan 21, 2026

View reviewed changes

Comment thread src/engine/channels/enginedeck.cpp

acolombier reviewed Jan 25, 2026

View reviewed changes

test(stem): Fix VU Meter unit test assertions and robustness for mute…

423e8b1

…d stems

acolombier approved these changes Jan 25, 2026

View reviewed changes

xARSENICx mentioned this pull request Jan 27, 2026

docs: Add Stem VU Meter controls to appendix mixxxdj/manual#841

Merged

JoergAtGithub mentioned this pull request Jan 27, 2026

Epic: STEM mixing #13116

Closed

8 tasks

JoergAtGithub requested changes Jan 27, 2026

View reviewed changes

xARSENICx requested a review from JoergAtGithub January 27, 2026 21:48

JoergAtGithub approved these changes Jan 27, 2026

View reviewed changes

acolombier merged commit 4452cd2 into mixxxdj:main Jan 27, 2026
15 checks passed

acolombier modified the milestones: 2.6.0, 2.7-beta Jan 27, 2026

xARSENICx deleted the vu-meter-cos branch January 27, 2026 23:15

Uh oh!

Conversation

xARSENICx commented Jan 20, 2026

Description

Key Changes

Related Issues

Verification

Uh oh!

Eve00000 commented Jan 21, 2026

Uh oh!

Uh oh!

xARSENICx commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

daschuer commented Jan 21, 2026

Uh oh!

xARSENICx commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoergAtGithub commented Jan 21, 2026

Uh oh!

xARSENICx commented Jan 23, 2026

Uh oh!

acolombier commented Jan 23, 2026

Uh oh!

acolombier left a comment

Choose a reason for hiding this comment

Uh oh!

acolombier Jan 25, 2026

Choose a reason for hiding this comment

Uh oh!

xARSENICx Jan 25, 2026

Choose a reason for hiding this comment

Uh oh!

xARSENICx commented Jan 25, 2026

Uh oh!

acolombier left a comment

Choose a reason for hiding this comment

Uh oh!

JoergAtGithub left a comment

Choose a reason for hiding this comment

Uh oh!

xARSENICx commented Jan 27, 2026

Uh oh!

JoergAtGithub commented Jan 27, 2026

Uh oh!

Uh oh!

acolombier commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

xARSENICx commented Jan 21, 2026 •

edited

Loading

xARSENICx commented Jan 21, 2026 •

edited

Loading