save, load, edit, import, and export custom effect chains

[Be]

It would be awesome if users could set up effect chains with specific orders of effects and custom metaknob linkings, then quickly save & restore them from a combobox in skins. From here it would not be difficult to export and import XML files with custom chains that could be shared on the forum. It would also be really cool if a custom effect chain could be setup in a standard effect unit then loaded into the QuickEffect units.

Related features:
Bug #1654491
Bug #1656189

Care must be taken when planning the implementation to make sure it works well with the above related features.

[ronso0 (ronso0)]

At least implementing this for the whole EffectRack should be easy now that effects are stored in an xml?
Save/Load mechanism of samplers could be re-used, no?

[Be (be.ing)]

Yes, it should be fairly easy to implement at this point. Implementing it for the whole EffectRack wouldn't be very useful though. I imagine making a new QComboBox subclass like WEffectSelector that would be at the top of each EffectUnit in the skins to select among saved chains. This would make it easy to quickly recall saved setups during a set.

[ronso0 (ronso0)]

I think it's useful for the rack, as well.
Just had someone screwing up my FX settings, wished I could have just reloaded th whole rack to reset to my defaults.
And if it's really that simple as it looks, this feature could make it into 2.1 beta, couldn't it?

Per-unit saving/loading would be nice but skin implementation would take much longer than adding buttons to skin menu or Options in the menu bar.

[Be (be.ing)]

While this feature would be relatively easy, I'm sure there will be quite a bit of work to refine the UI & UX and carefully think through the technical details. AFAIK no one has started it yet. I don't want to rush it for 2.1.

I think the use case you just encountered of restoring preferred state after someone else messes it up could be covered well enough by recalling saved chains in each EffectUnit. The effects system is already complex enough. I don't want to add another layer of complexity to the UX by adding the ability to save/restore the whole EffectRack. What do you think?

[ronso0 (ronso0)]

Yes, restoring a previously saved FX setup would be sufficient.
How can we implement this? Wouldn't it require UX changes anyway? Like a button in skin menu or in Effect Preferences?

[Be (be.ing)]

In implementing post fader effects, I realized this actually won't be very easy to implement because there are major architectural issues with the main thread side of the effects system that should be taken care of before implementing this. Here is a brief outline of my thoughts at the moment. I'm only putting these here so I don't forget them. I will not discuss these until after 2.1 beta is released:

1. Remove the confusing EffectRack layer. Current EffectRack subclasses will become EffectUnit subclasses.

2. Consolidate Effect*/Effect*Slot classes. XML saving and loading as well as initialization should be greatly simplified by this.

3. Remove confusing and highly error-prone capability of having an Effect* main thread class that is not connected to an EngineEffect* class loaded in the engine. Do this by removing addToEngine/removeFromEngine methods from Effect* classes and adding EngineEffect* classes to engine in constructors of Engine* main thread classes. EngineEffect* classes can be destroyed by EngineEffectsManager on shutdown. This may need to be done concurrently with 2.

4. Rename all mentions of EffectChains to EffectUnits.

5. Thoroughly think through UX design for saving and loading effect chain presets to clarify how naming, saving, switching, importing, and exporting chain presets should work.

6. Create a new QComboBox subclass for a skin widget like WEffectSelector for selecting effect chain presets. Introduce a new class for managing effect chain presets and have EffectUnit interface with it.

7. Add new effect chain preset selector widget to skins.

[Daniel Schürmann (daschuer)]

Here my comments, original from https://github.com/mixxxdj/mixxx/pull/1254#issuecomment-352209090

for 1.) That will introduce an other layer of confusion as I already have explained. The current situation is just fine and is extensible in all direction. This a well discussed design decision, and there is no strong reason to change it. I am really concerned about this topic, since it effects this PR as well.

for 2.) What are you planing to do here? We need a list what is responsible for what.

for 3.) Yes.

for 4.) Why that? IMHO this layer is nice, because it would allow to define kind of presets of an effect unit. An effect can be loaded to an effect slot. An effect chain is just a combination of more than one effect to load it at once to an effect unit.

for 5.) Yes. This should be done first before any major refactoring. A design document would be nice.

for 6.) An effect chain is already just a preset.

for 7.) We have this already in legacy LatNight

[Sébastien BLAISOT (sblaisot)]

it will also be nice to have a section on forums to allow users to share custom effect chains.

[Be (be.ing)]

My end goal is to be able to have intuitive control of complex effect chain setups like depicted in this video:
https://www.youtube.com/watch?v=m0_Ku9PChlw
but without coupling the effect chains to the controller mapping like Traktor requires. This will let all users benefit from chains shared on the forums, not just users with a particular controller.

[Be (be.ing)]

In the future, when we have controller mapping preferences (Bug #1470278), we may consider implementing an API that lets controller mappings load a particular effect chain preset and let the user select which of their chain presets the controller will load in the mapping preferences.

[Be (be.ing)]

I may get started on the preliminary refactoring for 2.2, but I don't think I'll have enough time to complete this for 2.2.

[Be (be.ing)]

I'm unassigning myself from this in case a GSOC student wants to make it their project this year.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8918