-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
unify [effect chain],loaded_chain_preset
control (all 0-indexed now)
#12561
Conversation
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. |
Thank you. I'll try to take a look ASAP. |
e710d6b
to
0e7dfbb
Compare
There was a problem hiding this 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(as you did below)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed by d9b104b
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. I'll push fixups in response to your review, and another commit moving the preset swap to |
74581ea
to
c42d5ab
Compare
Okay, I'm happy with this now. Definitely less hacky. Works as desired. |
c42d5ab
to
79878d5
Compare
…into the '---' preset
79878d5
to
6bd44b4
Compare
@ywwg Is this ready for merge form your perspective? |
There was a problem hiding this 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.
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 to0
(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)
loaded_chain_preset
is set to-1
)Tests
Don't store/reload '---' preset
loaded_chain_preset
is0
loaded_chain_preset
is-1
Don't allow loading an effect into the '---' preset
[(unit)_Effect1],next_/prev_effect
/effect_selector
loaded_chain_preset
is-1