Preferences: show 'real' xfader configuration

[ronso0]

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.

[Swiftb0y]

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

[ronso0]

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?

[ronso0]

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

[ronso0]

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

[ronso0]

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)

[Swiftb0y]

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]

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.

[ronso0]

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.