Preferences: show 'real' xfader configuration by ronso0 · Pull Request #14124 · mixxxdj/mixxx

ronso0 · 2025-01-06T13:10:57Z

This makes the Mixer preferences load the xfader configuration

from config on first load (if all xfader controls are still at their default values¹)
from controls each following update

This means touching the usual 3-state switch or curve knob on a controller will update the xfader graphic immedtiately.

¹Since mappings are loaded before DlgPreferences is instantiated this is supposed to detect if mappings have already set the xfader config in their init(), either explicitly or received updates via inputReport request.

Will do another test soon with the S4 Mk3 mapping which requests a status report on startup to sync all controls.

If someone wants to test it without controller, here's a mapping for Vir-MIDI or MIDI Through
https://gist.github.com/ronso0/ae7a6f3fc2b28e43f16bf50bfb84e62e

Swiftb0y · 2025-01-06T13:54:53Z

+const ConfigKey kXfaderModeKey = ConfigKey(EngineXfader::kXfaderGroup,
+        EngineXfader::kXfaderModeKey);
+const ConfigKey kXfaderCurveKey = ConfigKey(EngineXfader::kXfaderGroup,
+        EngineXfader::kXfaderCurveKey);
+const ConfigKey kXfaderCalibrationKey = ConfigKey(EngineXfader::kXfaderGroup,
+        EngineXfader::kXfaderCalibrationKey);
+const ConfigKey kXfaderReverseKey = ConfigKey(EngineXfader::kXfaderGroup,
+        EngineXfader::kXfaderReverseKey);


This is UB and will very likely cause crashes on startup. https://en.cppreference.com/w/cpp/language/siof

Hmm, so IIUC this is not specific to the diff here but also applies to the state before?
Like EngineXfader::kXfaderConfigKey being defined and initialized in the namespace here?
And making those members of DlgPrefMixer and move them to the initializer list would avoid it, right?

Or create a few getXYZCfgKey() helpers in dlgprefmixer.h?

Or simply define them in enginexfader.h like this:
static const QString kXfaderGroup = QStringLiteral("[Mixer Profile]");
?

meeh..

error: in-class initialization of static data member ‘const QString EngineXfader::kXfaderGroup’ of non-literal type

okay, I use

const ConfigKey xfaderModeKey() { return ConfigKey(EngineXfader::kXfaderGroup, EngineXfader::kXfaderModeKey); }

and alike in this namespace.
Should be fine since they're not called before DlgPrefMixer is constructed?
Please check my fixups.

(sorry I force-pushed earlier, some debug stuff slipped in which I had to remove)

The problem is not that its defined in the namespace (please do and keep that), the problem is that you expose the symbol via the header and then other translation units initialize their static data based on the static data of another translation unit. The solution in both cases is either some "construct on first use" idiom (there are multiple ways to achieve that in C++) or just don't depend on static data from other translation units. So duplicate the QString across both translation units. Its ugly but thats what we get for using QStrings for everything...

Swiftb0y · 2025-01-07T12:02:02Z

+    static const QString kXfaderGroup;
+    static const QString kXfaderModeKey;
+    static const QString kXfaderCurveKey;
+    static const QString kXfaderCalibrationKey;
+    static const QString kXfaderReverseKey;


These are the offenders. If you can come up with a solution that removes this static data declarations from the header, you should be good. Again, I recommend you simply duplicate the required QStrings/ConfigKeys across both files. The same technically applies to the other more trivial members (double and const char*) too, it just likely doesn't crash in the unitialized state because the code is able to handle the "unitialized" values. Its still UB though. Best would be to make them static constexpr and initialize right there in the header, but thats not an option for the QStrings.

Thanks for the explanation, though I'm at a loss: I read about Construct on first Use but explanations and tutorials only refer to obejcts/pointers and classes with a constructor, which is not the case for EngineXfader.
I'll revert the commit and stick with the duplicate QStrings.

Swiftb0y

couple thoughts

Swiftb0y · 2025-02-04T15:36:11Z

          m_xFaderMode(MIXXX_XFADER_ADDITIVE),
-          m_transform(EngineXfader::kTransformDefault),
-          m_cal(0.0),
-          m_mode(kXfaderModeKey),
-          m_curve(kXfaderCurveKey),
-          m_calibration(kXfaderCalibrationKey),
-          m_reverse(kXfaderReverseKey),
-          m_crossfader("[Master]", "crossfader"),
+          m_xFaderTransform(EngineXfader::kTransformDefault),
+          m_xFaderCal(0.0),


proposal: Create a struct CrossfaderParameter in the class to bundle the calibration, transform, reverse and mode together instead of prefixing all of those with xFader?

You mean just for holding the parameters in the preferences?
Sure, we can do that. But tbh I'd like to get the mechanics right first before we start optimizing it.

You mean just for holding the parameters in the preferences?

Yes, and for comparing whether the settings have changed and the display would need to be rerendered. Putting that into a struct and relying on the default operator== is easier/nicer than writing that comparision manually. But sure, we can postpone if you think thats raising complexity.

Yup, let's postpone it.
Wanna file a request for it?

nah, its no need to file an issue over code improvement. someone else will clean it up when they look at it again.

ronso0 · 2025-02-06T14:23:51Z

Sorry what? Why is CI failing on that one now?

Error: /home/runner/work/mixxx/mixxx/src/test/borrowabletest.cpp:4:10: error: Module QtConcurrent should not be included directly [-Wclazy-no-module-include]
4 | #include

Swiftb0y · 2025-02-06T14:27:01Z

not your fault. ignore clazy for now. #1713 (comment)

ronso0 · 2025-02-07T13:02:41Z

Alright, all works as desired now!

Swiftb0y · 2025-02-07T13:06:38Z

great. what next steps would you prefer? Remove the debugging statements, address my previous comments, etcc?

ronso0 · 2025-02-07T13:10:46Z

Testing! 😄
With real controllers, or a dummy mapping.
I've been using this: https://gist.github.com/ronso0/ae7a6f3fc2b28e43f16bf50bfb84e62e

ronso0 · 2025-02-07T13:11:00Z

then with 👍 remove the debug stuff

ronso0 · 2025-02-07T13:11:25Z

all comments addressed, except the struct.
I removed the timer, all good now with the no-op checks.

Fun fact: if I connect all CO changes to one slot and read all COs there, all (2-3) changes made by the mapping script are already applied, regardless: the slot is called 2-3 times.
So COs are update before preferences receive the first valueChanged signal..

ronso0 · 2025-02-07T13:31:09Z

Alright, all works as desired now!

whoops, not quite, widget update after controls change was missing.

ronso0 · 2025-02-17T08:05:43Z

This has proven to be very handy recently:
already late into a session when I wanted to cut, I noticed that the S4's xfader switch must have been flipped when I've put it into its case, and I could quickly adjust and very the desired curve.
(some sort of popup would have been super nice in this case, so i don't have to open the preferences and navigate to Mixer anymore 🤔 bit like the key wheel window with a auto-hide timer)

edit popup is here #14361

Swiftb0y · 2025-02-17T11:11:31Z

I agree. Do you intend to finish this then? There are still open review comments and the code is also still full of debug printing.

ronso0 · 2025-02-17T15:12:07Z

I think I addressed all comments.

I'll squash and remove the debug commit once this has received some testing.

Swiftb0y · 2025-02-17T17:16:14Z

+    m_xFaderMode = radioButtonConstantPower->isChecked()
+            ? MIXXX_XFADER_CONSTPWR
+            : MIXXX_XFADER_ADDITIVE;
+


does this need to be in the slider slot?

No, good catch 👍

Swiftb0y · 2025-02-17T17:18:18Z

+        // wiped on shutdown.
+        m_xFaderCal = EngineXfader::getPowerCalibration(m_xFaderCurve);
+        m_xFaderMode = m_pConfig->getValue<int>(kXfaderModeKey);
+        m_xFaderReverse = m_pConfig->getValue<int>(kXfaderReverseKey) == 1;


Suggested change

m_xFaderReverse = m_pConfig->getValue<int>(kXfaderReverseKey) == 1;

m_xFaderReverse = m_pConfig->getValue<bool>(kXfaderReverseKey);

or is there a reason otherwise?

daschuer · 2025-04-26T08:29:54Z

@Swiftb0y Are all review findings solved?

ronso0 · 2025-04-29T09:03:27Z

If added the testing mapping I was using for#14361

If someone wants to test it without controller, here's a mapping for Vir-MIDI or MIDI Through
https://gist.github.com/ronso0/ae7a6f3fc2b28e43f16bf50bfb84e62e

Swiftb0y

please remove the qWarnings. I will test ASAP.

Swiftb0y · 2025-04-29T09:39:14Z

+    SliderXFader->blockSignals(true);
+    buttonGroupCrossfaderModes->blockSignals(true);
+    checkBoxReverse->blockSignals(true);


lets use a QSignalBlocker instead. Otherwise an exception or an inconsiderate future early return could cause the widgets to stay blocked.

Swiftb0y · 2025-04-29T12:11:24Z

I will test ASAP.

Tested. Builds and works well afaict.

ronso0 · 2025-04-29T12:18:28Z

please remove the qWarnings. I will test ASAP.

Thanks!

I'll squash, remove the trace logging and force-push after LGTM.

Swiftb0y

LGTM. Thank you.

… members etc.

…ve changed Initially check if the xfader controls have been touched already (at least one is not at default value anymore). If not, load all from config. Else load from controls. Later on, update the widgets and xfader graphic when any control is touched, eg. by controller mappings.

ronso0 · 2025-04-29T13:32:56Z

Sorry for the noise, I messed up the intertwined fixups.
Final rebase diff is https://github.com/mixxxdj/mixxx/compare/7dc4de0..829718639b45516f271ff11ddebd5acb693a9fbe

Swiftb0y

LGTM. Thank you. Waiting for CI.

github-actions Bot added engine ui preferences labels Jan 6, 2025

Swiftb0y requested changes Jan 6, 2025

View reviewed changes

ronso0 force-pushed the pref-xfader-from-controls branch 3 times, most recently from 6025dbe to f00cfec Compare January 7, 2025 09:13

Swiftb0y reviewed Jan 7, 2025

View reviewed changes

ronso0 force-pushed the pref-xfader-from-controls branch from f00cfec to b8d477a Compare January 9, 2025 14:25

ronso0 mentioned this pull request Feb 4, 2025

Add Simpler control to change Crossfader Contour #13363

Open

Swiftb0y reviewed Feb 4, 2025

View reviewed changes

ronso0 force-pushed the pref-xfader-from-controls branch 2 times, most recently from 0057d9b to a7bd77b Compare February 6, 2025 13:21

ronso0 mentioned this pull request Feb 7, 2025

make [MixerProfile],xFaderCalibration read-only, auto-set in EngineXFader / EngineMixer #14304

Open

ronso0 force-pushed the pref-xfader-from-controls branch from a7bd77b to 72deec0 Compare February 7, 2025 13:02

ronso0 force-pushed the pref-xfader-from-controls branch from 72deec0 to 4c46a32 Compare February 7, 2025 13:33

ronso0 mentioned this pull request Feb 17, 2025

(feat) show popup with Xfader curve when curve parameters changed (eg. by script) #14361

Open

2 tasks

ronso0 force-pushed the pref-xfader-from-controls branch from 4c46a32 to e0dec0d Compare February 17, 2025 15:11

Swiftb0y reviewed Feb 17, 2025

View reviewed changes

ronso0 added this to the 2.6-beta milestone Feb 25, 2025

acolombier added this to Releases Mar 25, 2025

github-project-automation Bot moved this to In progress in Releases Mar 25, 2025

Swiftb0y reviewed Apr 29, 2025

View reviewed changes

Swiftb0y approved these changes Apr 29, 2025

View reviewed changes

Pref Mixer / xfader: use parented_ptr and PollingControlProxy, rename…

39614f2

… members etc.

ronso0 force-pushed the pref-xfader-from-controls branch from 7dc4de0 to b9b5854 Compare April 29, 2025 13:15

ronso0 marked this pull request as draft April 29, 2025 13:17

ronso0 force-pushed the pref-xfader-from-controls branch 3 times, most recently from 23f7207 to 8e5bce5 Compare April 29, 2025 13:27

ronso0 force-pushed the pref-xfader-from-controls branch from 8e5bce5 to 8297186 Compare April 29, 2025 13:31

ronso0 marked this pull request as ready for review April 29, 2025 13:32

Swiftb0y approved these changes Apr 29, 2025

View reviewed changes

Swiftb0y enabled auto-merge April 29, 2025 13:34

Swiftb0y merged commit 9c47653 into mixxxdj:main Apr 29, 2025
1 check passed

github-project-automation Bot moved this from In progress to Done in Releases Apr 29, 2025

ronso0 deleted the pref-xfader-from-controls branch April 29, 2025 13:55

ronso0 mentioned this pull request May 1, 2025

Herc dj control inpulse 500 #14722

Merged

ronso0 mentioned this pull request Mar 5, 2026

try to show the actual crossfader config in preferences set by controller scripts #13971

Closed

ronso0 mentioned this pull request Apr 21, 2026

Crossfader #16364

Closed

	m_xFaderReverse = m_pConfig->getValue<int>(kXfaderReverseKey) == 1;
	m_xFaderReverse = m_pConfig->getValue<bool>(kXfaderReverseKey);

Uh oh!

Conversation

ronso0 commented Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ronso0 Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ronso0 Jan 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Swiftb0y Jan 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Swiftb0y left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ronso0 commented Feb 6, 2025

Uh oh!

Swiftb0y commented Feb 6, 2025

Uh oh!

ronso0 commented Feb 7, 2025

Uh oh!

Swiftb0y commented Feb 7, 2025

Uh oh!

ronso0 commented Feb 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Feb 7, 2025

Uh oh!

ronso0 commented Feb 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Feb 7, 2025

Uh oh!

ronso0 commented Feb 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Swiftb0y commented Feb 17, 2025

Uh oh!

ronso0 commented Feb 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

daschuer commented Apr 26, 2025

Uh oh!

ronso0 commented Apr 29, 2025

Uh oh!

ronso0 commented Jan 6, 2025 •

edited

Loading

ronso0 Jan 6, 2025 •

edited

Loading

ronso0 Jan 6, 2025 •

edited

Loading

Swiftb0y Jan 7, 2025 •

edited

Loading

ronso0 commented Feb 7, 2025 •

edited

Loading

ronso0 commented Feb 7, 2025 •

edited

Loading

ronso0 commented Feb 17, 2025 •

edited

Loading