-
-
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
Support updating of effect presets #4686
Conversation
Adds a menu item to the effectunit cog menu below "Save as new preset".
return; | ||
} | ||
|
||
auto existing = m_effectChainPresets.find(name); |
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 do not understand why you look up the EffectChainPresetPointer by name, when we already have the pointer.
Please add a source code comment that explains the code.
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 payload of the pointer is different because it is newly created. But I found a simpler way of doing this
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.
ah, I thought I could call reset() on the shared pointer and have it update both lists, but that does not work.
Co-authored-by: Daniel Schürmann <daschuer@mixxx.org>
The code looks good now, however there is a usability issue with the default state. I also think that the menu can make use of an improvement. We have now:
The word "preset" = "Voreinstellung" sounds wrong in my ears because a preset is something that is "adjusted or applied in advance" but we have no advance in this case. How about treating it all like a loaded file with a change tracking asterisk
Or show hide/gray out "Save" if nothing has changes. In a first version I think we even can omit the idea of changes tracking. |
in english this word choice is not confusing. "Create new preset" is fine. |
The "preset" = "Voreinstellung" thing is now less of an issue, because of the check mark. The "Unnamed Preset" is now no longer visible. But the underlying issue still persists I have just tested with an empty preferences folder and hit a debug assertion:
When I continue anyway, I see no check mark, but I am able to select "Save preset" |
I see the loadEffectInner issue on main, not just my branch, are you sure that's caused by my changes?
|
the current effects code uses the word "preset" extensively. This is not the right place to re-raise the question of word choice. I am still not able to reproduce the circumstance where a preset is not loaded but the "Save Preset" menu item is still visible. Can you post a screenshot? |
That's odd, now I cannot even start with a fresh profile anymore. There is something bad going on with the sound drivers.
|
I have copied over the soundconfig.xml and now it is working. I cannot longer produce the debug assertion and the save entry is hidden as desired. I think this is related to the LV2 plug-Ins. My guess is that a preset with a missing LV2 Plug-In is removed from the list, but the required remove of the save menu entry is missing: |
ahh ok. There are two lists of presets, one QHash and one sorted QList. It is not surprising that they can get out of sync. And it could be that the m_pChain tries to load itself but runs into an error and gets into a degraded state. I'll see if I can find another way to test whether a preset is actually loaded or not |
… the list. Checking for an empty name in m_pChain was not reliable enough. Instead, only show the save option if we found a preset that matches our name.
OK I only show the save option if we added the check mark. I believe that should be sufficient. We should also file a bug for the issue you found with bad lv2 plugins causing issues. |
The hiding of the menu entry works now. Thank you. "Create New Preset..." does not work well for me, because it implies that I create a new precondition for something from the scratch, which is not the case here. "Save Preset" is understandable but sounds wrong, because we have not yet preset to save. It becomes a preset during the process. I would prefer to avoid that abstract word "preset" entirely in the menu, but its OK if it used in the correct relation. The full sentence is "Save the current Effect Chain state as Effect Chain Preset" From this I see the following alternatives:
Or
Or back to the original
|
Your screenshots shows that the term Preset is never used alone. In these contexts the preset term makes sense, because they are uses a precondition for the effect chain. We have a list of selectable presets. See the definition:
Loaded into a chain the Preset becomes the current setting of the chain, that can be freely adjusted. When I now read "Save Chain Preset As..." it sounds like I just give the original Preset a new name. Actually we want to Update the original preset from the chain and store it as a preset with a new name.
If you like to keep "Preset", "Update Preset" and "Save As New Preset..." works much better for me and translates well. |
I do agree with this. I'll go with "Update Preset" and "Save As New Preset..." to stop the argument, although I don't like using two different verbs |
Thank you, for this nice addition. LGTM |
Adds a menu item to the effectunit cog menu below "Save as new preset".