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

unify [effect chain],loaded_chain_preset control (all 0-indexed now) #12561

Merged
merged 6 commits into from
Jan 23, 2024

Conversation

ronso0
Copy link
Member

@ronso0 ronso0 commented Jan 13, 2024

In #10859 I introduced an inconsistency, [QuickEffectRack1_[ChannelN]] loaded_chain_preset is offset by one compared to [EffectRack1_EffectUnitN] because of the prepended empty preset.

Fix1
The '---' preset is now also available for standard chains, e.g. via the effect chain preset button (⚙️ icon in effect units), which removes the offset. As before, selecting this preset clears the effect chain and loaded_chain_preset is set to 0 (works with all effect chains).
(and -1 for nameless items, the default state of standard effect units and the main output effect unit)
(fixes the issue discovered by @Swiftb0y in #11378 (comment))
I didn't do this before to avoid the UX issue I tried to describe here #11378 (comment)
which is now fixed by

Fix2
When an effect is about to be loaded while the '---' preset is loaded (and slots are empty)

  • an empty, nameless preset is loaded (loaded_chain_preset is set to -1)
  • the effect is loaded
  • '---' is again available for clearing the effect chain

Tests

Don't store/reload '---' preset

  • clear an effect unit by selecting the '---' preset in the chain preset menu
  • loaded_chain_preset is 0
  • restart Mixxx
  • check
    • no preset is selected in the chain preset menu
    • loaded_chain_preset is -1

Don't allow loading an effect into the '---' preset

  • clear an effect unit by selecting the '---' preset in the chain preset menu
  • trigger loading an effect (via effect selector or [(unit)_Effect1],next_/prev_effect/effect_selector
  • check
    • desired effect is loaded
    • no preset is selected in the chain preset menu
    • loaded_chain_preset is -1

@ronso0
Copy link
Member Author

ronso0 commented Jan 13, 2024

IMO this is definitely a 2.4.0 candidate since it restores the API consistency.

I'm sorry for not taking care of it sooner, #10859 got too big / took too long, I had no motivation to fix it right away.
Now, with a bit of distance, the fix was pretty easy. And low-risk IMO.

@Swiftb0y
Copy link
Member

Thank you. I'll try to take a look ASAP.

@ronso0 ronso0 force-pushed the effectchain-loaded_preset-offset branch from e710d6b to 0e7dfbb Compare January 13, 2024 21:58
Copy link
Member

@ywwg ywwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I understand correctly, the major issue is that we want effects to be 0-based, but we also want a nullable-style "no effect" option. Is that right? I don't love the hackiness of this solution but at this late date I don't have a better idea. Something to look at later, perhaps.

@@ -394,6 +394,20 @@ void EffectChainPresetManager::setPresetOrder(
m_effectChainPresets.value(chainPresetName));
}

// After having changed the presets order in DlgPrefEffects, we received the
// new lists. The '---' was not displayed there, so it's not in the list.
// Make sure the empty preset "---" is the first item in the list.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use consistent quote marks in the comments just for neatness

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -896,6 +931,10 @@ void EffectChainPresetManager::saveEffectsXml(QDomDocument* pDoc, const EffectsX
QDomElement chainsElement = pDoc->createElement(EffectXml::kChainsRoot);
rackElement.appendChild(chainsElement);
for (const auto& pPreset : std::as_const(data.standardEffectChainPresets)) {
// Don't store the name '---', see readEffectsXml() for explanation.
if (pPreset->name() == kNoEffectString) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we don't want to store the noeffect, shouldn't we skip it (continue) instead of setting the name empty and adding it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(as you did below)

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 added this only as safeguard to not dump loaded effects in the (unexpected) case that there are effects loaded despite the '---' preset name.
I can turn it into a VERIFY_OR_DEBUG_ASSERT.

Copy link
Member Author

@ronso0 ronso0 Jan 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed by d9b104b

@ronso0
Copy link
Member Author

ronso0 commented Jan 14, 2024

I don't love the hackiness of this solution but at this late date I don't have a better idea.

I understand. IMO the hackiness (filtering '---' during preset export/import, Read/SaveEffectsXml and in the preferences) stems from the fact that we don't want to expose the '---' in the GUI except in the chain selectors and the chain preset menu.

IMO this fix can be considered a hack only because the preset switch happens after the effect was loaded into the '---' preset.
Would be better to that when the effect change is requested.
Just now I realize EffectSlot knows its parent EffectChain and also has a pointer to the preset manager, so since only EffectSlot::loadEffectInner emits the effectChanged() signal we care about, the preset swap can very well be triggered from there.

I'll push fixups in response to your review, and another commit moving the preset swap to EffectSlot.

@ronso0 ronso0 force-pushed the effectchain-loaded_preset-offset branch 2 times, most recently from 74581ea to c42d5ab Compare January 14, 2024 23:05
@ronso0
Copy link
Member Author

ronso0 commented Jan 14, 2024

Okay, I'm happy with this now. Definitely less hacky. Works as desired.
I also added a Tests section to the PR description.

@daschuer daschuer added this to the 2.4.0 milestone Jan 15, 2024
@ronso0 ronso0 force-pushed the effectchain-loaded_preset-offset branch from c42d5ab to 79878d5 Compare January 15, 2024 11:30
@ronso0 ronso0 force-pushed the effectchain-loaded_preset-offset branch from 79878d5 to 6bd44b4 Compare January 15, 2024 11:57
@daschuer
Copy link
Member

@ywwg Is this ready for merge form your perspective?

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.

The code Looks good and it works without any issues. Than you.

@daschuer daschuer merged commit b3439e9 into mixxxdj:2.4 Jan 23, 2024
13 checks passed
@ronso0 ronso0 deleted the effectchain-loaded_preset-offset branch February 9, 2024 02:31
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.

4 participants